O que o Sentrya coleta do Zabbix

O Sentrya lê os problemas abertos do seu Zabbix e os transforma em incidentes. A meta é mostrar exatamente o que o painel Monitoramento → Problemas do Zabbix mostra — nem mais, nem menos.

Paridade com o painel do Zabbix

A cada ciclo, o coletor chama problem.get pedindo só problemas de trigger (source=0, object=0) e aplica os mesmos recortes do painel:

Suprimidos ficam fora (suppressed=false): problemas de hosts em janela de manutenção não viram incidente enquanto a manutenção durar.
Só causas, não sintomas (symptom=false, Zabbix 6.4+): em versões anteriores o parâmetro não existe e é omitido.
Só triggers monitoradas: o resultado é cruzado com trigger.get monitored=true. Problemas de triggers desabilitadas, de hosts desabilitados ou de itens desativados — os "fósseis" que a API devolve mas o painel esconde — são descartados.

A leitura é paginada em blocos de 5 000 problemas, então ambientes com dezenas de milhares de problemas abertos são lidos por inteiro.

Frequência e falhas

A coleta roda a cada poucos segundos — tipicamente entre 10 e 30 s, conforme a configuração do ambiente — com um pequeno espalhamento para não bater em todos os servidores ao mesmo tempo. Cada chamada ao Zabbix tem um teto de tempo próprio.

Se a API falhar, a coleta daquele ciclo é descartada e o card do servidor passa a Erro com a mensagem. Falhas isoladas não mudam o ritmo; a partir de 3 falhas seguidas o coletor recua exponencialmente (o intervalo dobra a cada falha, até no máximo 10 minutos entre tentativas). Na primeira coleta bem-sucedida o servidor volta a Conectado, o ritmo normal é retomado e "sincronizado há …" é atualizado. Em servidores autenticados por usuário e senha, uma sessão expirada é renovada automaticamente com um novo login.

Falha de API nunca resolve nada. Um incidente só vira Resolvido quando uma coleta bem-sucedida e completa não o traz mais. Sem resposta íntegra do Zabbix, não há verdade para comparar — e nada é fechado às cegas.

Do problema ao incidente

Zabbix mostra	Sentrya mostra
Nome do problema (nome da trigger, macros expandidas)	Nome do incidente
Host (nome visível; se vazio, o nome técnico)	Host / Equipamento
Grupos de hosts do host	Grupos — também controlam quem vê o incidente (Grupos visíveis)
Severidade 5 → 0	Desastre, Alta, Média, Atenção, Informação, Não classificado
Hora do evento (clock)	Início do incidente e Duração atual
Dados operacionais (opdata)	Mensagem do incidente
Problema reconhecido (acknowledged)	Marca de ACK no incidente
Servidor de onde veio	Origem ("Zabbix \| nome do servidor")
Problema sumiu da lista	Estado Resolvido (o incidente é mantido no histórico, nunca apagado)

Identidade, recorrência e ACK

Identidade. Cada ocorrência é identificada pelo id do evento do Zabbix, e o problema em si pela dupla host + trigger dentro daquele servidor. É essa dupla que liga ocorrências repetidas do mesmo problema.
Recorrências. Quando uma trigger é vista pela primeira vez, o Sentrya consulta event.get e conta quantas vezes ela abriu problema nos últimos 30 dias; esse número vira a base do contador ×N. Depois, cada transição Resolvido → Problema soma 1. Veja Recorrências.
ACK espelhado. O campo acknowledged vem em cada coleta: um ACK dado direto no painel do Zabbix aparece no app no ciclo seguinte, e um ACK feito pelo app é gravado no Zabbix via event.acknowledge e marcado no incidente na mesma hora. O Histórico de ACKs junta o que foi feito no app com a trilha lida do Zabbix. Veja Reconhecer, fechar e comentar (ACK).
Versão. Depois de cada coleta bem-sucedida, a versão do Zabbix (apiinfo.version) é registrada no servidor.

Teto de segurança: 200 000 problemas

Existe um limite absoluto de 200 000 problemas por servidor em uma coleta. Um ambiente saudável, mesmo com dezenas de milhares de problemas abertos, fica longe disso; o teto existe para um Zabbix com defeito não fazer a coleta paginar sem fim. Se ele for atingido:

os problemas lidos até ali são gravados normalmente;
a resolução automática é pulada naquele ciclo — como a lista pode estar incompleta, nada é marcado como Resolvido;
o que ficou além do teto não aparece no app.

Antes da primeira confirmação, nada disso roda. A coleta contínua só começa depois que você confirma a Primeira coleta. O ciclo automático ignora servidores que ainda não foram confirmados.

O que não é coletado

Itens, valores coletados, gráficos e histórico de métricas — o Sentrya trabalha só com problemas.
Eventos que não são de trigger: descoberta de rede, auto-registro de agentes e eventos internos do Zabbix.
Problemas suprimidos por manutenção e eventos-sintoma (a causa é coletada).
Problemas de triggers, hosts ou itens desabilitados.
Problemas já resolvidos antes de o servidor ser conectado — só entram na contagem de Recorrências via event.get, não como incidentes.