Alertas
Triagem de alertas de monitoramento em tempo real para o NOC, com agrupamento, escalonamento e análise por IA
A tela Alertas (/alerts) é o painel de triagem para o time de NOC (Network Operations Center). Alertas de sistemas externos de monitoramento (por exemplo, Alertmanager, Zabbix ou Grafana) chegam via webhook de uma política de alerta e viram episódios nesta tela — cada episódio agrupa as ocorrências repetidas do mesmo alerta em um único registro, com contadores e histórico.
A tela é restrita a usuários que não têm o cargo de cliente e faz parte do plano Pro (e superior). Sem a feature de integrações, o item some do menu lateral.
O que é um episódio
Cada alerta recebido abre (ou atualiza, se já existir) um episódio, identificado por um fingerprint. Reocorrências do mesmo alerta somam ao episódio existente em vez de criar um novo — a tela mostra quantas vezes ele ocorreu na janela de agregação e em quantos episódios distintos ele apareceu nos últimos 30 dias.
Todo episódio carrega:
- Severidade (crítico, alto, atenção, informativo) e status (ativo/
firingou resolvido). - Estado NOC:
Novo→Reconhecido→Em análise→Escalado→Resolvido. As transiçõesReconhecido⇄Em análisepodem ser feitas manualmente pelo dono do alerta; escalonamento e resolução têm fluxos próprios. - Empresa, origem (a política de alerta que o gerou) e o chamado vinculado, aberto automaticamente pela mesma política.
- Payload bruto do evento, labels e a timeline completa do episódio (recebido, ocorrências, reconhecimento, escalonamento, silenciamento, resolução).
Contadores e filtros
No topo da tela, cartões de contagem funcionam como atalhos de filtro rápido: alertas ativos, sem tratamento (novos), escalados sem dono, críticos ativos e altos ativos. Clicar em um cartão filtra a lista; clicar de novo remove o filtro.
Além dos contadores, a barra de filtros permite combinar:
| Filtro | Comportamento |
|---|---|
| Busca | Texto livre sobre os alertas carregados. |
| Severidade | Seleção múltipla (crítico, alto, atenção, informativo). |
| Estado | Seleção múltipla pelos estados NOC. |
| Status | Ativos, resolvidos ou todos (padrão: ativos). |
| Empresa | Lista pesquisável, derivada dos alertas carregados. |
| Origem | Política de alerta que gerou o episódio. |
| Dono | Agente que reconheceu o alerta, ou "Sem dono". |
| Período | Última atividade: 24h, 7 dias, 30 dias ou todo o período. |
Os filtros ficam salvos entre visitas (no navegador).
Agrupamento
A lista pode ser agrupada por Regra (nome do alerta), Empresa, Cluster ou Origem. Cada grupo mostra a pior severidade entre os membros, quantos estão ativos, as empresas envolvidas e a última atividade — clicar em um grupo abre a lista (drill-down) só com os alertas daquele grupo. O agrupamento também fica salvo entre visitas.
Ações no episódio
Ao abrir um alerta, o painel de detalhe oferece:
- Analisar: assume o chamado vinculado (você vira o dono do episódio), move o chamado para Em andamento e marca o episódio como Em análise — sinaliza para o restante do time que alguém já está investigando.
- Ir para o chamado: abre o chamado vinculado ao episódio, onde fica todo o histórico de atendimento.
- Escalar: aciona a política de escalonamento da empresa. Com uma única política ativa, o alerta escala direto; com mais de uma, é preciso escolher qual usar. O mesmo escalonamento também acontece automaticamente quando ninguém reconhece o alerta dentro do prazo definido na política.
- Silenciar: cria uma silence (supressão temporária de novos chamados) vinculada à política de origem, sem impedir que o auto-resolve continue funcionando. A condição de silenciamento pode ser gerada por IA a partir de uma instrução em linguagem natural (ex.: "silenciar apenas o pod
payments-api-xk2lp") ou escrita manualmente como um Go template — em ambos os casos, o OpsScript valida a condição contra o payload real do alerta antes de permitir salvar. A duração vai de 5 minutos a 90 dias.
Análise por IA do episódio
No painel de detalhe, o bloco Análise com IA (plano Pro e superior) gera, a partir do payload bruto do alerta:
- Resumo do que está acontecendo e onde.
- Causa provável, com base apenas nas informações do payload.
- Evidências que sustentam a hipótese.
- Ações recomendadas, da mais para a menos prioritária.
A análise usa como ferramentas todos os MCP Servers habilitados na organização (logs, métricas, contexto de cluster), quando houver algum cadastrado. O resultado fica em cache no episódio — reabrir o alerta não gera uma análise nova; use Reanalisar quando o cenário mudar.
Sem MCP Servers cadastrados, a análise se baseia só no payload do alerta. Cadastre servidores de logs/métricas em Integrações → MCP Servers para enriquecer a análise com contexto real da sua infraestrutura.
Relação com Políticas de alerta e chamados
- Cada episódio nasce de uma política de alerta (Integrações → Alertas): é ela quem recebe o webhook, aplica o template e abre o chamado. A tela de Alertas é a camada de triagem desse fluxo — o atendimento em si acontece no chamado vinculado.
- Assumir o alerta (botão Analisar) e assumir o chamado são a mesma ação: o dono do chamado vira o dono do alerta.
- Resolver o episódio acontece pela origem (quando o alerta se normaliza, se a política tiver condição de resolução automática) ou pelo encerramento do chamado vinculado.