Estado: carregando…

Configurar conexão

Crie antes um banco dedicado (ex.: CREATE DATABASE iryon; — não use o do Zabbix). Ao salvar, o decider valida a conexão, grava o Secret noc-decider-db e reinicia conectado (cria o schema decider). Trocou o banco? reinicie depois o actuator e o ticket.

A retenção define a janela máxima dos filtros de período de cada dashboard — não há dado para filtrar além dela.

Padrão global

Valor de referência. Cada fonte tem a sua janela — use “Aplicar a todas” para uniformizar.

—dias

Referência de corte: dados anteriores a —.

—

Por fonte de dado

Sempre preservado

Itens do Insights em aberto / em tratamento sempre

Preservados até serem resolvidos ou aceitos — nunca apagados por tempo enquanto ativos.

Execuções ativas (não terminadas) sempre

Uma execução em andamento nunca é removida no meio do fluxo.

A limpeza é irreversível: o que passar da janela é removido na próxima volta (horária).

Saúde dos módulos

………

Fluxo do Iryon autônomo — verde = disponível, vermelho = indisponível, cinza = não monitorado / sem probe. Passe o mouse para latência e detalhe.

carregando…

1Cliente
2Conectar cluster
3Host do cluster
4Auto-correção
5Servidor VM (opcional)
6Verificação (opcional)
7Avisos (opcional)

Cliente *identificador único — minúsculas, sem espaços/acentos. Vira tag, grupo, prefixo de host e tenant da mensageria.

Cluster (rótulo, opcional)

Modo de operação * (auto-correção) Como o Iryon atua nos alertas deste cliente. Em cluster remoto, "Autônomo" opera como Supervisionado (o executor só faz ações declarativas).

O cluster do cliente é privado, sem internet — só libera egress na 443 para a URL do Iryon. Um chisel client abre o túnel de saída; o Zabbix proxy monitora e (quando o modo age) o executor corrige — tudo pelo mesmo túnel. Nada entra no cluster.

Namespaces do cluster * (vírgula · definem monitoração, hosts e atuação)Um host de monitoração por namespace; e (nos modos que agem) o executor recebe permissão de atuação nelas.

Proxy

Túnel (egress do cliente → Iryon)

Credencial do túnel (gerada automaticamente)

PSK do Zabbix (gerado automaticamente)

1 · No cluster Iryon (automático): credencial do túnel autorizada

Feito automaticamente ao chegar neste passo. Usa a mesma credencial já embutida no YAML do bloco 2 — apenas autoriza o cluster Iryon a aceitá-la; não altera o YAML.

2 · No cluster do cliente: o manifesto — um só apply (proxy + auto-correção). Use Copiar/Baixar, aplique o YAML INTEIRO

3 · No cluster do cliente: aplicar e pegar o token read-only (p/ a macro {$KUBE.TOKEN} do passo 3 · Host do cluster)

Único requisito de rede no cliente: egress até —. Sem porta de entrada, sem internet aberta.

4 · Confirmar que o proxy conectou (depois de aplicar no cluster)

Fecha o loop do copy-paste: confirma que o cluster do cliente aplicou o manifesto e o proxy fez contato — antes de criar o host.

Obrigatório — cria no Zabbix um host por namespace (definidas no passo 2), monitorado pelo proxy. Cole o token read-only e crie.

Template

API do cluster (padrão interno · raramente muda)

Token read-only * (do SA do proxy — comando do passo 2, bloco 3)

O host é monitorado pelo proxy, então a API interna https://kubernetes.default.svc basta. Sem o token o host é criado mas não coleta — cole-o antes de criar.

Motor de atuação — o executor já vai no bundle único do passo 2 (instalado junto com o proxy, pelo mesmo túnel). É ele que deixa o Iryon agir em Kubernetes e em servidores VM (por SSH). Aqui você confirma que está atuando. Modo: —.

Namespaces de atuação (definidas no passo 2)

Opcional — integre um servidor Linux do cliente. O executor (passo 2) instala o agente Zabbix por SSH a partir do binário registrado (modo passivo, sem repositório/internet no servidor), cria o host e o proxy passa a coletar. A mesma credencial habilita a atuação (reiniciar serviço, limpar disco). Pule se o cliente só tem Kubernetes.

Rede no servidor: liberar entrada 10050 (coleta pelo proxy) e 22 (SSH do executor) da sub-rede dos nós. A chave/senha vai cifrada ao executor — nunca fica no Iryon.

Confirmação lida de volta do Zabbix — o host existe e está com grupo, template e tags corretos.

Avisos por canal (opcional)

Defina por quais canais — e para quem — os alertas deste cliente serão avisados. Cada canal vira uma conexão dedicada do cliente na Mensageria.

Se pular, este cliente usará os canais padrão da plataforma — os avisos não somem, mas vão para o destino padrão, não para os contatos do cliente.

carregando…

Política de avisos (padrão)

Avisar também quando auto-resolver (correção bem-sucedida)

Padrão herdado pelos clientes (cada um pode sobrepor no seu card Avisos). Liga/desliga os avisos do caminho feliz ("corrigindo…" / "resolvido/restabelecido"). Ticket de problema/escalonamento e o fechamento de ticket escalado são sempre avisados.

Mensagens dos avisos (padrão)

Como o Decisor redige os textos (padrão herdado; cada cliente pode escolher Template ou IA no seu card Avisos). No modo IA, usa o provedor de Decisor → IA / Agente.

Usar template padrão
Textos determinísticos pelos modelos abaixo (com placeholders). IA elabora as mensagens
O Decisor redige o texto com IA a partir do contexto. Os modelos abaixo viram fallback.

Modelo por situação. Placeholders:

IA consultiva

desligada = decisão 100% determinística (só a matriz)

redigir egress (mascara IP/FQDN)

Tentativas de correção antes de escalar

No modo Autônomo: quantas abordagens diferentes a IA pode aplicar num incidente antes de escalar para o humano. Maior = mais autônomo (mais custo/escrita no cluster); menor = escala mais cedo. Diferente do Loop-guard (que barra a mesma ação repetida).

Consumo da IA

Requisições à IA —

Tokens —

Modo de operação

Define como o decider atua diante de um incidente.

O que cada modo faz

ObservaçãoDecide e mostra o que faria — não age, não abre ticket, não avisa. Para observar com segurança.

Só escalaNão age, mas abre ticket + avisa e reconhece no Zabbix. Toda correção fica com humanos.

SupervisionadoAutonomia segura: só ações da allow-list fechada, com o gate por classe/estado. Recomendado.

AutônomoA IA propõe e executa comandos livres (bypass da allow-list). Gate só por Proibições absolutas + Block-list + namespace. Máxima autonomia — a blacklist é a única trava; use com consciência do risco.

Como funciona o Iryon

Do alerta à recuperação — o fluxo do NOC autônomo.

Fluxo IA Segurança Desfecho A camada de Observabilidade (Dashboards e Atividade) acompanha todo o fluxo em tempo real.

Fluxo principal

1

Monitoração

O Zabbix detecta o problema (trigger) e envia o evento ao NOC.

2

Decisão com IA

O decisor coleta o diagnóstico remoto e a IA define a melhor ação.

3

Muros de segurança

Três barreiras antes de agir: Proibições, RBAC e regras de escalonamento.

4

Atuação

O comando é enfileirado e executado dentro do cluster do cliente, por túnel seguro.

5

Desfecho

O reconciliador confirma a recuperação pelo Zabbix; se não resolver, escala para um humano.

Saídas e observabilidade

Tickets

Abertura e gestão de chamados no CITSmart, com nº do ticket e histórico.

Mensageria

Notificação por WhatsApp, SMS, Telegram e e-mail para as equipes.

Observabilidade

Dashboards (Visão geral e Grafana) e a Atividade em tempo real.

Reconciliador: trata o Zabbix como fonte da verdade — reverifica incidentes, confirma recuperações e reescala os que travaram, sem nunca apagar o histórico.

Modos do Decisor — o reflexo de cada um no fluxo

O comportamento diante de um incidente depende do modo de operação (ajustável em Operação → Modo de operação).

Observaçãopara na decisão

MonitoraDecideMurosAtuaDesfecho

Decide e mostra o que faria — não age, não abre ticket, não avisa. Ideal para validar com segurança. Fica registrado só na Atividade.

Só escalanão age · escala

MonitoraDecideMurosAtuaDesfecho→ Ticket + Aviso

Não corrige, mas abre ticket, avisa as equipes e reconhece no Zabbix. Toda a ação fica com humanos — pula Muros e Atuação.

Supervisionadofluxo completo · allow-list

MonitoraDecideMurosAtuaDesfecho

Autonomia segura: executa apenas ações da allow-list fechada, com o gate por classe/estado. Fora da lista → escala. Recomendado.

Autônomofluxo completo · comando livre

MonitoraDecideMurosAtuaDesfecho

A IA propõe e executa comandos livres (bypass da allow-list). Só as Proibições, a block-list e o namespace barram. Máxima autonomia — use com consciência do risco.

Carregando Mensageria…

Recursos

CPU e memória por deployment / statefulset — uso ao vivo do cluster.

Ordenar:

Uso por workload CPUMemória

Selecione um cliente.

Insights

Causas-raiz rastreadas — o que reduz incidente e se a correção pegou.

Incidentes por dia

resolvidoescalado

Carregando Dashboards…

—

Alertas cujo texto contenha algum destes termos não são auto-corrigidos: o Iryon abre ticket e chama um humano. Ideal para alvos críticos (identidade, bancos, control-plane). Casa por trecho (ignora maiúsculas) em ação · host · namespace · nome do alerta.

Bloquear quando o alerta contiver:

Bloqueios ativos 0

Proibições absolutas

recusa na hora

Padrões destrutivos recusados na hora, em qualquer campo/comando: remover namespace, excluir PVC/secret, DROP/TRUNCATE, rm -rf, scale=0, patch/exec etc. As padrão são fixas (nem a IA, nem o cadastro, nem o modo Autônomo liberam); você pode adicionar as suas.

—

Permissões do cluster (RBAC mínimo)

teto fixo

O teto final: mesmo um comando liberado só faz o que o ServiceAccount permite. É a última barreira — independe do decider e não se altera pela GUI.

Pode

get · patchdeployments e statefulsets

get · list · deleteapenas em pods — o controller recria

get · listsecrets e configmaps (descobrir o datasource p/ o lock)

Não pode — nem no limite

deletenamespace · PVC · PV · secret · CRD · node

DROP · DDLem banco — só a linha de lock do Liquibase

Como cada ação é decidida

avaliada nesta ordem — a primeira trava que casa vence

O veredito depende de duas coisas: as travas abaixo (nesta ordem) e o modo de operação — em Observação o Iryon só mostra o que faria; em Só escala nunca age; em Supervisionado/Autônomo o passo 4 (gate) libera a execução. Varie os dois no simulador abaixo.

1 · PROIBIÇÕESBlacklistpadrão destrutivorecusa na hora

→

2 · BLOCK-LISTEscalonamentoalvo sensívelescala

→

4 · GATERisco + estadoclasse R/D/Iroda ou escala

→

5 · RBACTeto do clusterúltima barreirasó limita

Desfecho: roda sozinho escala p/ humano recusado

Como o passo 4 (gate de risco) classifica

R · reversível baixo impacto, dá p/ desfazer (ex.: resync de relógio) e D · disruptiva incomoda por instantes mas se auto-recupera (ex.: reiniciar pod) → rodam sozinhas. I · irreversível não dá p/ desfazer → sempre humano.
Exceções: recriar um pod já quebrado roda mesmo em statefulset (o dado persiste no PVC); mexer num pod saudável de statefulset pede aprovação; causa fatal (crashloop/imagem) escala.

Simular um alerta — o que o Iryon faria?

roda a lógica real do decider · não executa nada

Modo de operação

simula só aqui — não muda o modo real

Ação candidata

Namespace

Alvo / host

Nome do alerta

Comando a testar (opcional — checa a blacklist)

pod quebrado (não-pronto) causa fatal (crashloop/imagem)

carregando…

Console de execução

valida nas travas de Segurança

Executa no ativo do cliente escolhido. Kubernetes = kubectl (limitado pelo RBAC do executor — o teto real). Servidor = comando via SSH. Todo comando passa pelas travas de Decisor → Segurança: se infringir, não executa e mostra o motivo. Tudo auditado.

Cliente

Alvo

Executores por cliente

Cada cliente roda seu executor dentro do próprio cluster (HA por Lease) e puxa só as intenções do seu cliente. Habilite/edite a atuação em Clientes integrados. Problemas primeiro.

cliente	executor	namespaces de atuação	fila	consistência
carregando…

Catálogo das ações da allow-list (com classe de risco, busca e filtros) em Decisor → Segurança.

Credenciais da API do Zabbix — a base p/ tudo. Salvas mascaradas e reusadas em todas as ações.

URL da API

Token de API (super-admin) Gere no Zabbix (Usuários → Tokens de API). Recomendado (em vez de usuário/senha).

Ou usuário/senha (se não tiver token de API)

Usuário

Senha

URL do decider p/ o Zabbix (webhook) Só p/ Zabbix EXTERNO: URL pública do /v1/decide. Vazio = Zabbix in-cluster (recomendado).

Servidor p/ agentes — ServerActive / trapper Endereço que os agentes usam p/ checks ativos + autoregistro — é o trapper (10051), NÃO a URL da web. Zabbix in-cluster: use o NodePort (<nó>:31051) ou um LoadBalancer :10051. Aceita lista separada por ;.

HostMetadata (casa a Action de autoregistro) Marca gravada no agente; a Action de autoregistro casa por “contém”. Vazio = linux-noc.

Modelo harmonizado: 1 webhook (noc-decider) + 1 Action. O Zabbix só encaminha o evento; o decider decide, remedia, abre/fecha ticket e avisa. Cada item é idempotente; a Action nasce desabilitada.

Host groups — opcional (escopo extra da Action)

A Action já é escopada pelos templates do Iryon. Só preencha p/ incluir também triggers de hosts fora desses templates (o grupo deve existir).

carregando…

Canais se configuram em Clientes integrados (por cliente em Avisos; o padrão da plataforma no topo). Requer admin.

Biblioteca de templates

Origem dos templates importados na Integração. Upload p/ atualizar sem rebuild ou baixe p/ backup. Cada gravação guarda a versão anterior (rollback).

template	no Zabbix	origem	tam.	atualizado

Upload

Nome (ex.: kubernetes/k8s-namespace.yaml)

Binário do agente (servidores Linux)

Binário instalado nos servidores Linux ao integrar (modo passivo, sem repositório/internet no servidor). O padrão por arquitetura é usado automaticamente; você pode enviar novas versões e escolher qual será instalada. O padrão embarcado é o zabbix_agentd estático (roda em qualquer distro/versão).

versão / rótulo	arch	agente	tam.	sha256	padrão

Enviar novo binário

Rótulo/versão

Arch

Agente

Onde encontrar o binário

Página oficial: zabbix.com/download_agents — escolha Zabbix agent (não o agent2), OS Linux, Encryption: No, e ligue Static. Baixe o .tar.gz.
Ou direto pelo CDN (troque a versão e a arch):
https://cdn.zabbix.com/zabbix/binaries/stable/7.4/7.4.12/zabbix_agent-7.4.12-linux-3.0-amd64-static.tar.gz
Extraia (tar xzf …tar.gz) e envie aqui o arquivo sbin/zabbix_agentd (arch agent (agentd)).

Estático de Linux existe só para amd64 (x86_64) e i386. Não há build estático de agent2 para Linux nem de arm64 — para esses, use o modo repositório (apt/dnf) na integração.

Citsmart / Keycloak

URL Citsmart

URL Keycloak

Realm

Client

Usuário de serviço

Activity ID

Contract ID

Requester ID

Telefone de contato

Senha do svc-noc

Client secret

Segredos são write-only: digite p/ trocar, deixe em branco p/ manter, e nunca são exibidos de volta (mascarados). Salvar grava no store; o ticket-api aplica em ~15s. "Testar" pede um token no Keycloak do Citsmart (valida tudo E2E). Requer admin.

Segredos & estado

A GUI só indica presença, nunca o valor. Senha e client secret são editáveis ao lado; o Bearer é definido só via CLI no Secret.

Visão geral

Saúde da infraestrutura do cliente — disponibilidade, serviços no ar e incidentes.

Ações do NOC · 24 h

Incidentes

Saúde dos serviços

No arDegradadoForaOcioso

Disponibilidade · 24 h

Uptime (24 h)

—

Banco de dados (decider)

Configurar conexão

Retenção de dados

Padrão global

Visão geral

Saúde dos módulos

Integrar cliente

Clientes integrados

Aprovações

Avisos

Política de avisos (padrão)

Mensagens dos avisos (padrão)

IA / Agente

Consumo da IA

Operação

Modo de operação

Atividade

Como funciona o Iryon

Monitoração

Decisão com IA

Muros de segurança

Atuação

Desfecho

Tickets

Mensageria

Observabilidade

Recursos

Insights

Segurança

Proibições absolutas

Permissões do cluster (RBAC mínimo)

Executor & fila

Console de execução

Executores por cliente

Configurar Zabbix

Biblioteca de templates

Upload

Binário do agente (servidores Linux)

Enviar novo binário

Ticket / ITSM (Citsmart)

Citsmart / Keycloak

Segredos & estado

Visão geral