Engenharia de sinal · Zabbix 7.0 LTS

Triggers no Zabbix 7.0: a que não valida e a que dispara demais

São dois problemas diferentes que aparecem na mesma semana. Primeiro a expressão não salva. Depois ela salva — e começa a acordar o plantão com pico de três segundos. Os dois têm a mesma raiz: o que a expressão de trigger realmente é.

30 de setembro de 2026 Por Cleber Félix 22 anos em infraestrutura Validado contra a documentação do Zabbix 7.0 LTS

Problema 1: a expressão não valida

É comum encontrar, em tutorial e em resposta de fórum, algo com esta forma:

{/Host/system.cpu.util}>90

Ela não valida, e o motivo é estrutural, não de digitação. Uma expressão de trigger no Zabbix não compara um item — ela compara o resultado de uma função aplicada a um item. A sintaxe canônica, conforme a documentação, é:

function(/host/key,parâmetro)<operador><constante>

Sem função, não há o que avaliar. A correção mínima é escolher uma:

last(/Host/system.cpu.util)>90

Sobre omitir o nome do host

A forma //chave, sem host, só é aceita em contextos específicos: fórmulas de itens calculados e macros de expressão — como o campo de nome do evento, nome de gráfico e rótulos de elementos de mapa. Em expressão de trigger comum, omitir o host é erro.

Problema 2: agora ela valida e dispara demais

A trigger acima funciona, e é exatamente aí que começa a fadiga de alerta. last() devolve o valor mais recente coletado. Um pico isolado de CPU, dos que toda máquina tem durante um backup ou um garbage collector, já é suficiente para gerar problema.

A ferramenta certa é uma função de janela temporal. A própria documentação usa este exemplo:

min(/Zabbix server/net.if.in[eth0,bytes],5m)>100K

Com min sobre cinco minutos, a condição só é verdadeira se o valor esteve sempre acima do limite durante a janela inteira. Um pico não dispara, porque o mínimo da janela continua baixo.

O mesmo dado, duas leituras. last() enxerga o instante; min() sobre a janela exige que a condição tenha valido do começo ao fim dela.

Qual função para qual sintoma

Você quer alertar quando…	Função	Leitura
O valor ficou alto a janela inteira	`min()`	Saturação sustentada. A mais conservadora
O valor encostou no teto ao menos uma vez	`max()`	Detecção de pico, quando o pico importa
O comportamento médio piorou	`avg()`	Tendência. Tolera oscilação
Nada chegou no período	`nodata()`	Avaliada mesmo para item sem suporte

Tempo ou quantidade de valores

O parâmetro aceita as duas leituras, e elas não são equivalentes. sum(/host/key,10m) soma os valores dos últimos dez minutos; sum(/host/key,#10) soma os últimos dez valores, independentemente de quando chegaram. Em item com coleta irregular, a diferença é grande.

Com last, a cerquilha muda de significado: last(/host/key,#2) é o penúltimo valor, não “os dois últimos”.

Problema 3: a trigger que abre e fecha sozinha

Resolvido o ruído por pico, sobra o flapping: a métrica oscila em torno do limite e a trigger abre e fecha várias vezes por hora. Cada ciclo gera notificação.

A solução no Zabbix é a recovery expression — um segundo campo, separado, na configuração da trigger. Com ele, o limiar de abrir deixa de ser o mesmo de fechar. Exemplo da documentação, para espaço em disco:

// Problema: menos de 10 GB livres nos últimos 5 minutos
max(/server/vfs.fs.size[/,free],5m)<10G

// Recuperação: mais de 40 GB livres nos últimos 10 minutos
min(/server/vfs.fs.size[/,free],10m)>40G

Entre 10 GB e 40 GB o problema permanece aberto sem reabrir a cada oscilação. É o que se chama de hysteresis.

O limiar de abertura e o de recuperação são diferentes de propósito. A faixa entre eles absorve a oscilação que geraria notificação repetida.

A regra que inverte a intuição

A recovery expression sozinha não resolve o problema. A resolução acontece em duas etapas: primeiro a expressão de problema precisa ficar falsa; só então a de recuperação é avaliada, e precisa ser verdadeira.

Por isso também não faz sentido usar a macro {TRIGGER.VALUE} na recovery expression — ela só é avaliada quando a trigger já está em estado de problema, então o valor será sempre “1”.

Um detalhe que engana em teste

Os valores usados na avaliação de trigger ficam em cache no servidor, e esse cache não é limpo quando o histórico do item é removido, seja pelo housekeeper ou manualmente. O servidor continua usando os valores em cache até que fiquem mais antigos que o período definido na função, ou até reiniciar.

Na prática: apagar histórico para “zerar” um teste de trigger não produz o efeito esperado. E se não houver dado recente em cache nem período definido na função, o Zabbix consulta o banco retroagindo até uma semana.

O checklist que fecha o assunto

Antes de dar uma trigger crítica como pronta, três perguntas. Ela usa função com janela temporal, ou está comparando o último valor coletado? O limiar de recuperação é diferente do de abertura, ou ela vai oscilar junto com a métrica? E existe um mecanismo de fechamento declarado — expressão de recuperação, fechamento manual ou correlação por tag — ou o problema vai ficar aberto até alguém lembrar?

As três juntas eliminam a maior parte do ruído que faz uma equipe parar de ler alerta.

Fonte

Sintaxe, funções, parâmetros, hysteresis e cache de valores conforme a documentação oficial de expressões de trigger do Zabbix 7.0.

Quantas das suas triggers passariam nesse checklist?

Engenharia de sinal é uma das cinco áreas de um diagnóstico gratuito que montei, com 25 verificações objetivas sobre a operação. Ele devolve uma nota de 0 a 100 e aponta qual área está puxando seu resultado para baixo. Sete minutos, sem cadastro.

Fazer o diagnóstico