Monitorando 147 mil itens com Zabbix sem virar plantão eterno

Quando você passa de uma dúzia para centenas de equipamentos monitorados, o problema deixa de ser “como coletar dados” e vira “como não enlouquecer com alertas falsos”. Esse é o relato resumido de como organizei um Zabbix que hoje observa 147.900 itens em tempo real sem virar uma máquina de spam no plantão.

A regra que mudou tudo: nenhum item solto

Toda métrica vive dentro de um template. Quando algo precisa ser ajustado, é uma alteração só — não 150. Parece óbvio, mas vi muita instalação com itens “soltinhos” por host que ninguém ousa mexer porque “ninguém lembra mais o que faz”.

Template OLT Vendor X
├── Discovery: Interfaces
│   ├── Item: ifInOctets[{#SNMPVALUE}]
│   ├── Item: ifOperStatus[{#SNMPVALUE}]
│   └── Trigger: Link down em {#IFNAME}
└── Discovery: ONUs ativas
    └── Item: total_onus

Severidades têm que doer

Severity inflation é o maior assassino de NOC. Se tudo é “high”, nada é high. Minha régua:

• Disaster: acordou alguém no domingo de madrugada. Cliente impactado.
• High: vai impactar em 1h se ninguém olhar.
• Average: olhe no próximo turno.
• Warning: dado para investigar depois.
• Information: auditoria, não alerta.

IA entra depois do alerta, não antes

Aqui está a parte controversa. Eu não uso LLM para decidir se algo é alerta — isso é regra determinística. Mas uso LLM depois do alerta para:

1. Resumir contexto: “OLT-X caiu, últimos 3 eventos relacionados foram Y/Z/W”.
2. Sugerir runbook: “isso parece um problema de DDoS no upstream, verifique BGP”.
3. Classificar reincidência: “esse host alertou 14× nas últimas 24h — investigar root cause”.

A IA nunca silencia um alerta sozinha. Apenas enriquece o contexto.

Resultado prático

• -73% em falsos positivos no primeiro mês.
• MTTR caiu pela metade porque o contexto chega junto do alerta.
• Plantão fica para problemas que merecem plantão.

Próximo post: como rodar isso com Python + API do Zabbix sem virar uma macarroneira.