Relatório de Alertas Recorrentes¶
Identifica os alertas que mais dispararam no período, ordenados por contagem. É o relatório certo para atacar problemas crônicos: em vez de responder o mesmo alerta toda hora, você vê quais são os reincidentes e ataca a causa raiz.
A lógica é simples: se a mesma definição de alerta entrou em estado de problema 200 vezes nos últimos 30 dias, ou tem algo errado no ambiente que precisa ser resolvido de uma vez, ou o limiar do alerta está sensível demais e está gerando ruído. Em ambos os casos, vale agir.
Quem usa¶
- Operadores de plantão verificam de manhã os alertas mais frequentes da noite, para priorizar o que atacar primeiro.
- Times de melhoria contínua rodam o relatório todo fim de mês e usam o Top 10 como pauta da reunião.
- Gestores de infra identificam hosts problemáticos olhando a coluna Hosts Afetados: se o mesmo host aparece em vários alertas do topo, ele está pedindo atenção.
- Donos de perfis de monitoramento detectam regras barulhentas (contagem altíssima com severidade baixa) para ajustar limiares ou silenciar.
Como abrir¶
Pelo menu Observar & Explorar → Relatórios → Relatório de Alertas Recorrentes.
Estrutura da página¶

A página é montada em três camadas, de cima para baixo:
Seletor de período¶
Toggle no topo com duas opções fixas:
- Últimos 7 Dias: visão tática, boa para acompanhar a semana ou identificar uma piora recente.
- Últimos 30 Dias: visão estratégica, boa para reuniões de melhoria contínua e tendências.
Quando você muda o toggle, todos os KPIs e a tabela recarregam. Não há intervalo personalizado nesta tela: a ideia é manter o relatório direto. Para janelas customizadas, use o Histórico de Alertas e filtre manualmente.
KPIs no topo¶
Logo abaixo do toggle aparecem cinco cards:
| Card | O que mostra |
|---|---|
| Total de Ocorrências | Soma de todos os disparos de alerta no período (KPI maior, destaque). |
| Crítico | Quantos disparos foram de severidade Crítico. |
| Alto | Quantos foram de severidade Alto. |
| Médio | Quantos foram de severidade Médio. |
| Informação | Quantos foram de severidade Informação. |
Cada KPI de severidade tem cor própria (vermelho para Crítico, laranja para Alto, amarelo para Médio, azul para Informação), seguindo a paleta padrão da plataforma.
A leitura é rápida: se Crítico representa 5% do total mas a contagem absoluta passa de 50, você tem um problema sério recorrente. Se Informação é 80% do total, tem ruído demais e vale revisar regras.
Bloco Top Alertas Recorrentes¶
Abaixo dos KPIs, a tabela com o ranking. Esse é o coração do relatório.
A tabela¶
| Coluna | Conteúdo |
|---|---|
| # | Posição no ranking (1, 2, 3...). O alerta com mais disparos fica no topo. |
| Contagem | Quantas vezes o alerta disparou no período. Inclui repetições mesmo que ainda esteja aberto. |
| Alerta | Descrição do alerta (o mesmo texto que aparece em Descrição do Problema no Histórico de Alertas). |
| Severidade | Badge colorido com a severidade do alerta (Crítico, Alto, Médio, Informação). |
| Hosts Afetados | Lista de hosts onde o alerta disparou no período. Se o mesmo alerta afetou 12 hosts, todos aparecem aqui. |
Drill-down¶
Clique em qualquer linha da tabela para abrir o Histórico de Alertas já filtrado pelo alerta selecionado. A partir daí você vê cada disparo individual: quando começou, quando terminou, em qual host, qual o tempo aberto.
Esse caminho é o normal para investigar: você identifica o alerta no top, clica e navega no histórico detalhado.
Controles auxiliares¶
No header da página ficam:
- Atualizar: força recarregar os dados (útil se você mexeu em alertas ou perfis e quer ver o efeito imediato).
- Exportar: dropdown com CSV, Excel e PDF. Útil para anexar em apresentações ou compartilhar o ranking com gente que não tem acesso à plataforma.
Não há filtro por host, por severidade ou por tag nesta tela: a ideia é olhar o todo. Para recortes finos, exporte e filtre na ferramenta de destino, ou vá para Histórico de Alertas.
Como interpretar¶
A leitura padrão segue três regras simples:
Top 10 do mês merece investigação¶
Os dez primeiros do ranking de Últimos 30 Dias são, por definição, o que mais consome atenção do time. Mesmo que cada um pareça pequeno, somados eles dominam a fila de operação. Levar essa lista para a reunião de melhoria contínua já é metade do trabalho.
Severidade alta + contagem alta: prioridade máxima¶
Quando um alerta Crítico ou Alto aparece no top com contagem grande, é onde você ataca primeiro. Algo importante está dando errado de forma repetida, e não há justificativa para deixar rolando.
Severidade baixa + contagem altíssima: alerta barulhento¶
O caso oposto é o mais comum. Um alerta Informação ou Médio com 500 disparos no mês não é uma emergência, é ruído. Duas saídas:
- Ajustar o limiar para que ele só dispare quando realmente importa.
- Silenciar via manutenção ou desabilitar no perfil de monitoramento, se a métrica perdeu utilidade.
Antes de silenciar, entenda por que dispara
Reduzir ruído sem entender o motivo cria pontos cegos. Olhe alguns disparos individuais no Histórico de Alertas antes de silenciar: a frequência pode estar revelando um problema real que ninguém ainda formalizou.
Cenários de uso¶
Reunião de melhoria contínua¶
Pega o Top 10 do mês passado (toggle em Últimos 30 Dias), exporta para PDF e leva como pauta da reunião. Para cada item:
- Discutir a causa raiz.
- Atribuir um responsável por atacar o #1.
- Definir uma meta: "no mês que vem, esse alerta cai pelo menos 50%".
No mês seguinte, abra o mesmo relatório e compare. A queda dos primeiros itens é o medidor direto do impacto da iniciativa.
Identificar host problemático¶
Olhe a coluna Hosts Afetados ao longo das primeiras 20 linhas. Se o mesmo host (srv-app-03, por exemplo) aparece em 6 alertas distintos do topo, esse host é o gargalo: pode estar com hardware degradado, sobrecarregado, mal configurado ou em fim de vida.
A ação típica é abrir o detalhe do host em Hosts e revisar tudo: uso de CPU, memória, disco, processos, logs e configuração.
Tunar limiares barulhentos¶
Um alerta dispara 200 vezes em 30 dias com severidade Informação. Isso não é monitoramento, é spam. Abre o alerta no perfil de monitoramento que o originou e:
- Aumenta o limite (por exemplo, CPU > 80% por 5 minutos, em vez de > 70% por 1 minuto).
- Adiciona dependência de outro alerta para suprimir avisos redundantes.
- Reduz a severidade ainda mais, se faz sentido.
A próxima rodada do relatório mostra se o ajuste pegou.
Investigar uma piora recente¶
Compare Últimos 7 Dias com Últimos 30 Dias. Se um alerta apareceu no top dos 7 dias mas estava bem mais baixo no de 30 dias, alguma coisa mudou esta semana: deploy, mudança de configuração, falha de capacidade, ataque externo. Investigue o que aconteceu na transição.
Próximos passos¶
-
Histórico de Alertas
Detalhe disparo por disparo. É para onde o drill-down da tabela leva.
-
Relatório de SLA
Disponibilidade e downtime dos sistemas monitorados, com export por sistema/tecnologia.
-
Relatório de Capacidade
Hosts subutilizados, saudáveis, com aviso e superutilizados de CPU, memória e disco.