Severidades e estados
Todo incidente do Sentrya tem uma severidade (a escala do Zabbix, de 0 a 5), um estado (Problema ou Resolvido) e, opcionalmente, o selo Reconhecido. Esta página explica de onde vem cada um e como um incidente resolve.
As seis severidades
O Sentrya usa exatamente a escala do Zabbix. Cores e nomes são os mesmos em toda a interface: cards, faixa de severidades, detalhe e Resumo.
| Nível | Nome no app | No Zabbix | Na API do Sentrya |
|---|---|---|---|
| 5 | Desastre | Disaster | disaster |
| 4 | Alta | High | high |
| 3 | Média | Average | average |
| 2 | Atenção | Warning | warning |
| 1 | Informação | Information | info |
| 0 | Não classificado | Not classified | not_classified |
Para incidentes do Zabbix, a severidade é a do problema coletado. Para webhooks, é o campo severity (0 a 5) do payload; veja Referência do payload. Nas duas origens ela pode ser alterada depois com Mudar severidade no ACK.
Estados: Problema e Resolvido
Um incidente nasce em Problema (estado active) e termina em Resolvido (resolved). Resolver nunca apaga: a linha continua no banco com a data de resolução, e você a encontra com o filtro Situação: Resolvidos. É isso que permite contar recorrências e manter histórico.
Como um incidente do Zabbix resolve
O coletor consulta cada servidor Zabbix periodicamente. Quando um problema que estava ativo no Sentrya não vem mais na resposta de uma coleta bem-sucedida e completa, ele vira Resolvido. Três garantias:
- Falha de API nunca resolve nada — sem resposta não há verdade para comparar.
- Uma coleta truncada (servidor gigantesco que atingiu o teto absoluto) não reconcilia; o ciclo seguinte tenta de novo.
- Triggers e hosts desabilitados no Zabbix são filtrados como no painel do próprio Zabbix; um host desabilitado some da coleta e seus incidentes resolvem.
Fechar um problema pelo ACK (Fechar problema) fecha o evento no Zabbix; na coleta seguinte ele deixa de vir e o incidente resolve no app.
Como um incidente de webhook resolve
De duas formas: a fonte envia um evento com status: "resolved" e a mesma key do problema, ou alguém usa Descartar alerta / Resolver no app. Veja Ciclo de vida do alerta e a key e Descartar alertas de webhook.
Reconhecido
Reconhecido é um selo, não um estado: o incidente continua em Problema, mas alguém já assumiu. No Zabbix, o selo espelha o campo acknowledged do problema a cada coleta — ACK dado no painel do Zabbix aparece no app, e ACK removido lá some daqui. Quando o incidente resolve, o selo é limpo. Em webhooks, o selo é local ao Sentrya. Detalhes em Reconhecer, fechar e comentar (ACK).
Início, Duração atual e Última ocorrência
| Campo | O que mede |
|---|---|
| Início | Quando o episódio atual começou. Se o problema resolve e volta, o Início reinicia no retorno (é um episódio novo). |
| Duração atual | Agora menos o Início. Formato: 45s, 3m 20s, 12m, 3h 05m, 2d 4h. No detalhe aparece no quadro Duração; no texto de compartilhamento, como Duração atual. |
| Última ocorrência | A última vez que a fonte confirmou o problema: a cada coleta em que ele ainda aparece (Zabbix) ou a cada POST com a mesma key (webhook). No detalhe, a linha só aparece quando há mais de uma recorrência. |
O que identifica um incidente
- Zabbix: o par host + trigger daquele servidor. Cada ocorrência tem o seu event id do Zabbix, mas o problema é o mesmo enquanto host e trigger forem os mesmos — por isso a recorrência conta ×N em vez de criar cards repetidos.
- Webhook: a
keyque a fonte envia. Repetir a mesma key enquanto o problema está ativo atualiza o mesmo card; mandarresolvede depois a mesma key reabre o card contando recorrência. Sem key, cada POST é um alerta solto, sem agrupamento.
