Iryon OpsO decider está em modo memória (sem persistência nem HA). Configure a conexão do Postgres para ele gravar estado, decisões e configurações. Faça isto antes de mexer em canais/IA/etc. — eles se perderiam no reinício.
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.
Padrão global
Valor de referência. Cada fonte tem a sua janela — use “Aplicar a todas” para uniformizar.
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.
- 1Cliente
- 2Conectar cluster
- 3Host do cluster
- 4Auto-correção
- 5Servidor VM (opcional)
- 6Verificação (opcional)
- 7Avisos (opcional)
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.
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.
Único requisito de rede no cliente: egress até —. Sem porta de entrada, sem internet aberta.
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.
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: —.
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 da porta do agente (coleta pelo proxy; padrão 10050 — a que você escolher no formulário) e SSH (padrão 22) 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.
carregando…
Política de avisos (padrão)
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.
Modelo por situação. Placeholders:
Consumo da IA
Modo de operação
Como funciona o Iryon
Do alerta à recuperação — o fluxo do NOC autônomo.
Fluxo principal
Monitoração
O Zabbix detecta o problema (trigger) e envia o evento ao NOC.
Decisão com IA
O decisor coleta o diagnóstico remoto e a IA define a melhor ação.
Muros de segurança
Três barreiras antes de agir: Proibições, RBAC e regras de escalonamento.
Atuação
O comando é enfileirado e executado dentro do cluster do cliente, por túnel seguro.
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.
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).
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.
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.
Autonomia segura: executa apenas ações da allow-list fechada, com o gate por classe/estado. Fora da lista → escala. Recomendado.
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.
Recursos
CPU e memória dos workloads, ou uso dos volumes (PVC).
request protege você — garante fatia quando há disputa. O limit protege os outros de você: estrangula, e o estrangulamento pode estourar a liveness probe e reiniciar o container. Vale para carga não confiável ou runaway conhecido; na dúvida, defina o request.Versões de imagem
Imagens em execução nas namespaces dos clientes, comparadas com a versão matriz.
A matriz é por imagem, não por cliente: define a versão que todos deveriam rodar. Remover uma matriz não muda nada nos clusters — as instâncias daquela imagem voltam a aparecer como sem matriz, que é o estado honesto para “ninguém definiu a referência”.
Rotas e Ingress
Toda URL publicada pelos clientes — Ingress e Route na mesma lista — se está respondendo (checada a cada minuto, quando ligada) e o certificado que apresenta.
Ligada, a URL é checada a cada 1 minuto pelo proxy do Zabbix do cliente (de dentro da rede dele): GET com limite de 10 s, no ar com resposta 2xx ou 3xx, lenta acima de 2 s. Desligar mantém o histórico.
| Cliente↕ | Namespace↕ | URL↕ | Certificado↕ | Expira em↕ |
|---|
O certificado e a data vêm do handshake TLS na URL (o que o
navegador vê), não do Secret dentro do cluster. Sem certificado é URL só em
http. Não serve a URL é certificado apresentado que não cobre o
hostname. Inacessível é a 443 que não respondeu daqui. Vencido já passou
da data. Route com edge entra nessa leitura — é o certificado do
roteador, não um campo vazio.
Chamados
Todos os chamados abertos pelo NOC, o que os motivou e como terminaram — com a análise por cliente, causa e desfecho.
| Chamado↕ | Cliente↕ | Alerta↕ | Alvo↕ | Sev.↕ | Estado↕ | Ação↕ | Reinc.↕ | Aberto em↕ | Fechado em↕ | Duração↕ |
|---|
Clientes mais afetados
Chamados abertos no período, por cliente.
Desfecho
Quantos seguem abertos e quantos foram encerrados.
Com e sem análise de IA
A IA participou do diagnóstico do chamado.
Severidade
Gravidade do alerta que originou o chamado.
Alertas que mais geram chamado
Os dez com maior contagem — é onde vale atacar a causa.
Aberturas por dia
Volume diário no período filtrado.
Insights
Causas-raiz rastreadas — o que reduz incidente e se a correção pegou.
—
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.
Proibições absolutas
recusa na horaPadrõ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 fixoO 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.
get · patchdeployments e statefulsetsget · list · deleteapenas em pods — o controller recriaget · listsecrets e configmaps (descobrir o datasource p/ o lock)deletenamespace · PVC · PV · secret · CRD · nodeDROP · DDLem banco — só a linha de lock do LiquibaseO 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.
Como o passo 4 (gate de risco) classifica
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.
Console de execução
valida nas travas de SegurançaExecuta 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.
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.
Ou usuário/senha (se não tiver token de API)
/v1/decide. Vazio = Zabbix in-cluster (recomendado).<nó>:31051) ou um LoadBalancer :10051. Aceita lista separada por ;.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.
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
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
- 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 arquivosbin/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.
Verificação de situação dos chamados
Abrir e fechar chamado funciona com a configuração acima. Ler a situação (se o chamado foi encerrado, cancelado ou segue em andamento) depende de duas operações que precisam ser liberadas dentro do Citsmart — sem elas, a dashboard de Chamados não consegue saber o desfecho e mostra “sem confirmação”.
- No Citsmart, vá em Workflow & ESM → Operação de Web Service.
- Na aba Pesquisa de Operações, procure
request_getById. Se não existir, cadastre na aba Cadastro com Situação Ativa, Tipo de Classe Java e Nome da Classebr.com.centralit.citsmart.rest.v3.operation.RESTOperation. - Em Permissões, clique em Adicionar grupo e inclua o grupo do solicitante cadastrado para abrir os chamados — o mesmo grupo em que está o usuário de serviço configurado acima.
- Repita para
request_getByUser. - Grave e clique em Testar leitura de situação aqui embaixo.
Parâmetros pode ficar vazio. O que libera a operação é o grupo em Permissões.
Conexão
Este Keycloak é o do Citsmart — não é o SSO do Iryon. Realm, client, usuário e senha são os do ITSM: o ticket-api pede um token nesse realm (grant password) e abre o chamado com ele.
Abertura do chamado
Identificadores do Citsmart usados em cada chamado aberto pelo NOC. Vêm do cadastro do ITSM, não do Iryon.
Credenciais
Write-only: digite para trocar, deixe em branco para manter. Nunca são exibidas de volta — a tela indica apenas presença.
O Bearer da API não é editável aqui: é gerido por CLI no Secret citsmart-secret.
Política de abertura — do NOC, não do Citsmart
Quanto o NOC espera antes de registrar um chamado. Se o alerta normalizar dentro da carência, o chamado não chega a existir. Reuso de chamado já aberto nunca espera.
Política de encerramento — do NOC, não do Citsmart
Chamado escalado fica aberto quando o alerta normaliza, para uma pessoa confirmar. Ligando esta política, o NOC encerra sozinho o que está recuperado há pelo menos o tempo escolhido — contado a partir da normalização, não da abertura. Nunca encerra chamado proativo (Insights), ainda alertando ou sem contexto. Cada cliente pode ter prazo próprio ou ficar de fora em Clientes integrados.
Placeholders (clique para inserir): — {alerta} e {recuperou_em} são obrigatórios: todo encerramento diz o que normalizou e quando.
Salvar grava no store; o ticket-api aplica em ~15s. "Testar" pede um token no Keycloak do Citsmart e valida a ponta a ponta. Requer admin.
Campo não-secreto deixado em branco volta ao padrão do manifesto (env) — não fica vazio.
Disponibilidade K8S
Workloads de Kubernetes: situação agora, o período em barrinhas e o que aconteceu em cada queda.
Visão geral
Saúde da infraestrutura do cliente — disponibilidade, serviços no ar e incidentes.