·

Zabbix: 10 triggers que toda infra deveria ter no dia 1

Zabbix instalado não é infra monitorada. Em 12 anos e mais de 100 projetos, a i9aTech encontra o mesmo padrão nas operações que avalia: o servidor está de pé, o agente reporta, o dashboard está verde — e a queda continua chegando pelo telefone do usuário. O motivo é quase sempre o mesmo: ninguém saiu do template padrão e criou trigger nenhuma.

Monitoramento sem trigger é coleta de gráfico bonito. O valor aparece quando alguém é avisado antes do impacto. Abaixo estão as 10 triggers que colocamos no dia 1 de qualquer implantação — com a expressão pronta e o erro que mais vemos em cada uma.

Antes: a sintaxe nova (e o erro que trava todo mundo)

Desde o Zabbix 5.4 a sintaxe de trigger mudou. O formato antigo {host:key.last()} foi aposentado; hoje se escreve last(/host/chave). Todas as expressões deste artigo estão no formato atual e funcionam nas linhas 6.0 LTS e 7.0 LTS.

Cadastre cada uma em Data collection > Hosts > Triggers > Create trigger (ou direto no template, que é o certo — trigger criada host a host não escala). Troque host pelo nome técnico do host ou template.

Disponibilidade: as 3 que ninguém pode não ter

  1. Host mudo. nodata(/host/agent.ping,5m)=1 — severidade High. Dispara quando o agente para de reportar por 5 minutos. Erro comum: usar last(/host/agent.ping)=0, que nunca dispara — se o agente caiu, não existe valor novo pra ficar zero.
  2. Perda de pacote. min(/host/icmppingloss,5m)>20 — pega o link degradado, o caso que o ping simples não vê porque ainda responde. Erro comum: monitorar ICMP a partir do próprio datacenter e concluir que “o link está ótimo” — meça do lado de quem consome.
  3. Serviço fora do ar. last(/host/net.tcp.service[https,,443])=0 — porta é o que importa, não o processo. Erro comum: monitorar só o processo com proc.num: o serviço sobe, trava e continua “rodando” enquanto ninguém consegue conectar.

Capacidade: as 4 que evitam a parada anunciada

  1. Disco vai encher. timeleft(/host/vfs.fs.size[/,pfree],1h,0)<7d — em vez de alertar com 90% ocupado, alerta quando faltam 7 dias no ritmo atual. Erro comum: limiar fixo de percentual em disco de 4 TB, onde 10% livres ainda são 400 GB e o alerta vira ruído.
  2. Inode esgotado. min(/host/vfs.fs.inode[/,pfree],5m)<15 — disco com espaço e sistema gravando erro de “no space left”. Erro comum: ignorar inode em servidor de fila, cache ou sessão PHP, exatamente onde ele acaba primeiro.
  3. Memória e swap. min(/host/system.swap.size[,pfree],5m)<50 — swap em uso constante é o aviso silencioso antes do OOM killer. Erro comum: alertar por memória livre em Linux, que é sempre baixa por causa do cache. Use swap e vm.memory.utilization.
  4. Disco travando a CPU. avg(/host/system.cpu.util[,iowait],5m)>20 — iowait alto explica a lentidão que “não aparece em lugar nenhum”. Erro comum: olhar só load average e trocar servidor sem descobrir que o gargalo era storage.

Sinais silenciosos: as 3 que ninguém lembra

  1. Reinício inesperado. last(/host/system.uptime)<600 — severidade Warning. Servidor que reiniciou sozinho às 3h e ninguém soube é incidente, não sorte. Erro comum: deixar a trigger sem manual close, gerando alarme repetido a cada coleta durante 10 minutos.
  2. Relógio fora de sincronia. fuzzytime(/host/system.localtime,60s)=0 — drift de horário quebra autenticação, log e correlação de incidente. Erro comum: descobrir isso só na auditoria, quando o timestamp do log não bate com o do firewall.
  3. O próprio Zabbix. min(/host/zabbix[queue,10m],10m)>100 — fila crescendo significa que o servidor não dá conta e o “verde” do dashboard é mentira. Erro comum: não monitorar o monitoramento e operar às cegas achando que está tudo certo.

O passo que multiplica as 10

Cadastrada a trigger, faça mais três coisas: crie dependências (host mudo suprime as triggers de serviço daquele host e evita a tempestade de alertas), defina ação de notificação por severidade em Alerts > ActionsHigh acorda alguém, Warning espera o horário comercial — e mande alerta virar chamado automaticamente, em vez de morrer num grupo de WhatsApp.

Esse último ponto é o que separa NOC de mural de alarme. Detalhamos o caminho em detectar a queda antes do usuário com Zabbix e IA, e a estrutura de suporte que recebe o alerta você mede em 4 minutos no Quiz de Maturidade ITIL. Nossa página do Zabbix como parceiro mostra o escopo de implantação, e a Calculadora de TCO compara o custo dessa stack com a ferramenta proprietária que você usa hoje. Templates e materiais de apoio estão em recursos gratuitos.

Próximo passo

Tem Zabbix rodando mas ainda descobre incidente pelo usuário? Traga o cenário pro diagnóstico gratuito de 30 minutos: revisamos suas triggers atuais, apontamos os pontos cegos e você sai com a lista priorizada do que cadastrar primeiro.

Escrito pela equipe técnica i9aTech

Consultores ITIL certificados com 12 anos de estrada e 100+ projetos de Service Desk e ITSM implantados no Brasil. Todo dado citado vem de projeto real auditado. LinkedIn ↗


Vamos conversar sobre seu Service Desk?

Agende um diagnóstico gratuito de 30 minutos com um consultor sênior certificado ITIL.

Resposta em até 4 horas úteis · Sem compromisso

CONTINUE LENDO

Mais artigos pra sua operação

Ver todos os artigos →

DIAGNÓSTICO GRATUITO

Falar com consultor especialista

  1. 1 Seus dados
  2. 2 Confirmação

Receba em até 24h úteis um diagnóstico personalizado da sua TI: pontos críticos, quick wins e roadmap de 90 dias. Sem custo, sem compromisso.

  • Consultor sênior ITIL
  • 30 minutos online
  • Resposta em 24h úteis

Sem spam — dados ficam só na i9aTech. Prefere a página completa? Abrir formulário completo.

Tudo certo? Revise seus dados antes de enviar. Você pode e editar se precisar.

🔒 Dados protegidos (LGPD) · Sem spam · Política de Privacidade