Triggers

Trigger é lógica sobre dados, não um alarme isolado

O item coleta o valor. A trigger interpreta o valor no contexto de uma regra. Quando a expressão de problema avalia como verdadeira, o Zabbix pode gerar um evento de PROBLEM. A resolução depende da expressão voltar a falsa ou de uma recovery expression adicional, conforme a configuração.

Quando a trigger é recalculada?

Em Zabbix 7.4, triggers baseadas em history normalmente são recalculadas quando chega um novo valor para um item presente na expressão. Funções de data/hora e nodata() também exigem avaliações periódicas. Expressões baseadas somente em trend functions seguem a granularidade das tendências usadas.

Uma expressão deve representar a condição de problema

A sintaxe moderna referencia o item como /host/key.

# último valor maior que 90
last(/RTR-01/system.cpu.util)>90

# média dos últimos 5 minutos
avg(/RTR-01/system.cpu.util,5m)>85

# no mínimo 3 dos últimos 5 valores acima de 80
count(/RTR-01/system.cpu.util,#5,"gt",80)>=3

# alteração de estado de uma interface
last(/SW-01/net.if.status[ifOperStatus.10])=2

Escolha a função pela pergunta operacional

Tempo e quantidade de amostras respondem perguntas diferentes

# últimos 10 minutos
avg(/host/key,10m)

# últimas 10 amostras
avg(/host/key,#10)

# segundo valor mais recente
last(/host/key,#2)

Uma janela por tempo mantém significado mesmo se o intervalo de coleta mudar. Uma janela por número de valores mantém quantidade de amostras, mas muda sua duração real se o polling mudar.

Severidade deve representar impacto e urgência

Quando PROBLEM e OK precisam de condições diferentes

Por padrão, a trigger resolve quando a expressão de problema deixa de ser verdadeira. Em situações com histerese ou lógica distinta de recuperação, use recovery expression.

# PROBLEM
avg(/SW-CORE/net.if.util[1],5m)>85

# RECOVERY
avg(/SW-CORE/net.if.util[1],5m)<70

A diferença entre 85% e 70% cria uma zona neutra que reduz alternância PROBLEM/OK quando a utilização oscila próxima do limite.

Não deixe o threshold virar um interruptor nervoso

Histerese é especialmente útil em CPU, banda, temperatura, potência, latência, memória, filas e qualquer grandeza com oscilações naturais.

Ausência de dado não é automaticamente indisponibilidade do serviço

nodata(/Servidor/app.heartbeat,5m)=1

Antes de usar nodata(), defina o que a ausência representa: agent parado, proxy offline, host desligado, item unsupported, aplicação sem heartbeat ou atraso esperado.

Modele causas upstream conhecidas

Dependências entre triggers reduzem cascatas quando um componente depende de outro. Se o problema de uma trigger upstream estiver ativo, a trigger dependente pode ter sua mudança/notificação suprimida conforme a avaliação de dependência.

Router-1 DOWN
   ↓
Router-2 DOWN
   ↓
OLT DOWN
   ↓
ONUs / clientes DOWN

O Zabbix avalia dependências recursivamente e não permite dependências circulares. Use isso para relações estruturais conhecidas, não para tentar inferir qualquer correlação possível.

Tags transformam problema em contexto operacional

service=internet
carrier=operadora-a
site=pop-centro
role=uplink
scope=wan
criticality=high

Tags de trigger/evento podem ser usadas em Problems, Actions, correlação e Services. Crie uma taxonomia pequena, previsível e documentada.

Threshold não deve ser hardcoded em centenas de triggers

{$CPU.WARN}=80
{$CPU.HIGH}=90
{$IF.UTIL.WARN}=80
{$IF.UTIL.HIGH}=90
{$LATENCY.MAX}=100

Macros em template permitem valores padrão e override em host ou contexto. Isso evita clonar templates para cada cliente, site ou modelo.

Use trends para perguntas de longo prazo

History é apropriado para investigação recente e trigger rápida. Trends armazenam agregações horárias e são mais adequadas para análises de longo prazo e capacidade.

# exemplo conceitual: média do dia
trendavg(/Servidor/system.cpu.util,1d:now/d)>70

Problema que abre e fecha repetidamente destrói confiança no monitoramento

Causas comuns:

• threshold exatamente no ponto de operação normal;
• uso de last() em sinal ruidoso;
• polling muito curto para a dinâmica do serviço;
• recovery sem histerese;
• interface física instável;
• dependência não modelada;
• sensor com precisão/ruído inadequado.

Corrija a condição. Não resolva flapping apenas aumentando tempo de escalation ou silenciando notificações.

Combine sinais somente quando a combinação possui significado

# exemplo conceitual:
# latência alta E perda relevante
avg(/WAN/icmppingsec,5m)>0.100
and
avg(/WAN/icmppingloss,5m)>5

Combinar sinais pode reduzir falsos positivos, mas também pode esconder falhas reais se a lógica exigir condições demais. Defina o evento que você quer detectar antes da expressão.

Interface DOWN não significa sempre incidente

Em switches e roteadores, LLD pode descobrir centenas de interfaces: uplinks, clientes, portas livres, loopbacks, VLANs e interfaces administrativas. A trigger deve considerar a finalidade.

O problema certo é “Operadora A degradada”, não 29 links sem contexto

Tags, dependências, correlação e Services devem transformar falhas individuais em impacto agregado. Uma trigger em cada circuito continua necessária como evidência, mas a tela do NOC deve destacar o domínio comum.

Continue em Operadoras, dependências e correlação.

Trigger em template deve ser reutilizável e parametrizável

Use macros para thresholds, tags para contexto e nomes de evento que tragam host/objeto/valor úteis. Evite trigger cuja lógica depende de um host específico.

# ideia de nome
Interface {#IFNAME}: high utilization

# tags de protótipo
service=network
scope=interface
role={#IFALIAS}

LLD escala a trigger — inclusive os erros

Trigger prototypes devem acompanhar filtros e overrides do discovery. Se a regra descobre 2.000 interfaces, um protótipo ruim pode gerar 2.000 problemas inúteis.

• filtre interfaces irrelevantes;
• use macros LLD nos nomes;
• use overrides por tipo/alias;
• defina lifetime de objetos perdidos;
• teste template em poucos hosts antes de expansão.

Expressões também possuem custo

Funções sobre janelas muito longas de history, grande cardinalidade de itens, trigger prototypes em excesso e cálculos desnecessários aumentam carga. Use trends para longos períodos quando a pergunta permitir, dependent items para reduzir coleta e monitore busy processes/cache/banco.

Triggers que parecem úteis e viram dívida operacional

Trigger não abre, não fecha ou abre demais

1. Confirme em Latest data que o item possui valor novo.
2. Veja o tipo do dado e o valor bruto após preprocessing.
3. Calcule manualmente a condição usando a mesma janela.
4. Confirme macros expandidas e context macros.
5. Revise Recovery expression.
6. Revise dependências ativas.
7. Revise tags/correlação que podem fechar ou suprimir eventos.
8. Confirme manutenção ativa.
9. Cheque Event generation / OK generation.
10. Se houver LLD, confira protótipo e macros descobertas.

Aprenda criando e quebrando

Antes de publicar uma trigger em produção

• Existe finalidade operacional clara?
• O item é confiável e possui unidade/tipo corretos?
• A janela corresponde à dinâmica do serviço?
• Um spike isolado deveria abrir problema?
• Recovery precisa de histerese?
• A severidade representa impacto?
• As tags permitem roteamento/correlação?
• Há dependência upstream conhecida?
• O trigger prototype foi testado em pequena escala?
• Existe owner para agir?
• O texto do evento informa o necessário?
• A trigger foi testada com falha e recuperação reais?

Base factual

Conteúdo estruturado para Zabbix 7.4 com base na documentação oficial sobre Triggers, trigger expressions, supported functions, recovery expressions, tags e trigger dependencies. Exemplos de redes, ISP e NOC são síntese editorial aplicada ao contexto operacional.

Linha Zabbix 7.4

Priorize expressões que representem impacto real, recovery explícito quando necessário e dependências para causas upstream conhecidas; tags devem alimentar correlação, Services e roteamento.