Navegar na documentação

Recorrências

O contador ×N de Recorrências diz quantas vezes o mesmo problema já apareceu. Ele separa o alerta que disparou uma vez do que vive indo e voltando — que costuma ser o que mais merece atenção.

O que conta como recorrência

Recorrência é a transição Resolvido → Problema do mesmo problema. Enquanto um incidente continua em Problema, cada coleta que o confirma só avança a Última ocorrência; o contador não muda. Quando ele resolve e depois volta, o contador soma 1, o Início reinicia (é um episódio novo) e o card é o mesmo — não nasce um segundo card para o mesmo problema.

Identidade estável

Para saber que "voltou o mesmo problema", o Sentrya mantém um livro-razão de identidades por empresa, com a chave origem + host + trigger:

  • Zabbix: o servidor Zabbix, o host e a trigger. O event id de cada ocorrência é diferente, mas a identidade é a mesma.
  • Webhook: a fonte de dados, o host e a key. Sem key não há identidade — cada POST vira um alerta solto com Recorrências 1×, e nada é agrupado. Veja Ciclo de vida do alerta e a key.
Por que não pelo id do evento. Contar pelo evento faria cada re-disparo do Zabbix parecer um problema novo. Ancorar em host + trigger é o que permite dizer "esta interface caiu 14 vezes este mês" com um único card.

A base vinda do Zabbix

Se a contagem começasse do zero na primeira coleta, um problema com histórico longo no Zabbix apareceria como 1×. Por isso, na primeira vez que o Sentrya vê uma trigger de um servidor, ele pergunta ao Zabbix (event.get) quantas vezes ela disparou nos últimos 30 dias e grava esse número como base. Depois disso a identidade fica marcada como semeada e o contador só avança pelas transições que o próprio Sentrya observa.

  1. Coleta O coletor grava os problemas ativos e cria as identidades que ainda não existiam.
  2. Quem ainda não foi semeado? Só as triggers inéditas entram na pergunta ao Zabbix — em regime normal, nenhuma.
  3. Base + marca A contagem dos 30 dias vira o ×N inicial e a identidade recebe a marca de semeada.

A semeadura é de melhor esforço: se o event.get falhar, o contador começa a contar dali em diante e o próximo ciclo tenta de novo. Ela acontece uma única vez por trigger e vale também para a Primeira coleta.

Onde o contador aparece

LugarComo
Card na aba IncidentesO selo ×N.
Detalhe do incidenteO quadro Recorrências ("14×") e, com mais de uma recorrência, a linha Última ocorrência.
OrdenarA opção Recorrências (mais) traz primeiro os problemas que mais voltam; empate pela severidade.
CompartilharO texto gerado inclui Recorrências e Última ocorrência.
APICampo recurrence_count em GET /api/v1/incidents. Veja Consultar incidentes pela API.

Ser avisado a cada volta

Por padrão um ouvinte avisa no primeiro disparo. Ao editar um ouvinte, ligue Avisar em recorrências ("Toca de novo a cada vez que o alerta reaparecer, não só no primeiro disparo") para receber a cada transição Resolvido → Problema. Veja Criar um ouvinte do Zabbix e Editar, pausar e excluir ouvintes.

Encontre o que oscila. Combine Ordenar → Recorrências (mais) com Filtros → Idade → < 24h: o que voltou hoje e já tem contador alto é o candidato natural para investigar a causa raiz, não só reconhecer.
Remover o servidor zera a história. Resolver nunca apaga a contagem, mas Remover um servidor Zabbix apaga os incidentes e as identidades dele; reconectar o mesmo servidor recomeça com a base dos últimos 30 dias. Veja Remover um servidor Zabbix.

Veja também