Zabbix na prática: como monitoramos 1.500 dispositivos sem enlouquecer

Todo ambiente que herdamos tem a mesma doença, com um de dois sintomas: ou não monitora nada, ou monitora tudo. O segundo caso é mais perigoso, porque parece resolvido. Um Zabbix que dispara 400 alertas por dia funciona igual a um Zabbix desligado. Ninguém lê nenhum dos dois.

Teatro de monitoramento

O padrão se repete. Dashboard bonito na TV da sala de TI, verde na maior parte do tempo. Um e-mail de alertas indo para uma pasta que ninguém abre há anos. Quando algo cai de verdade, quem avisa é o usuário.

Nesse cenário, o monitoramento vira um gravador de incidentes. Serve para descobrir depois o que aconteceu. Não evita nada.

A causa raiz quase nunca é a ferramenta. O Zabbix aguenta dezenas de milhares de dispositivos com folga. A causa é conceitual: o monitoramento foi tratado como projeto de instalação, não como disciplina de operação. Os cinco princípios abaixo separam uma coisa da outra. Aprendemos cada um deles errando.

Princípio 1: alerta é para ação

Antes de criar qualquer trigger, fazemos uma pergunta. Quando isso disparar, alguém vai fazer o quê?

Se a resposta é "nada, é bom saber", então não é alerta. É métrica. Fica no gráfico, disponível para consulta, fora do canal de notificação.

Na prática, cada severidade carrega um contrato de resposta:

Se um Disaster dispara e ninguém age, o problema não é o incidente. É a classificação. Reclassifique na revisão seguinte, sem dó. Depois de alguns ciclos, o canal de alertas volta a significar alguma coisa. E o time volta a olhar.

Princípio 2: descoberta automática, ou o inventário mente

Inventário mantido à mão morre em 90 dias. Alguém troca um disco, cria uma VM, ativa uma interface. O monitoramento segue vigiando a topologia de três meses atrás.

O perigo não está no que ele mostra. Está no que ele nem sabe que existe.

No Zabbix, a solução tem nome: LLD, o Low-Level Discovery. Discos, sistemas de arquivos, interfaces e serviços são descobertos e monitorados automaticamente, via protótipos de item e trigger. Somando network discovery e auto-registro de agentes, chega-se ao efeito que importa: máquina nova entra no monitoramento sem depender de alguém lembrar.

Num parque de 1.500 dispositivos, depender de memória é garantia de falha.

Princípio 3: templates em camadas, thresholds em macros

O erro clássico é editar item e trigger direto no host. Funciona no host 1. No host 40, cada ajuste vira uma tarde de trabalho e ninguém mais sabe o que está configurado onde.

A estrutura que usamos:

# Camadas de template, do genérico ao específico
Base OS (Linux / Windows)        → CPU, memória, disco, uptime, agente vivo
  └─ Papel (DC, DB, hipervisor,  → serviços e métricas do papel
     firewall, switch, nobreak)
       └─ Contexto do cliente    → só macros: thresholds e janelas

O ajuste fino mora em macros de usuário, como {$CPU.UTIL.CRIT} e {$DISK.FREE.MIN}. Elas são sobrescritas por template ou por host quando o contexto exige.

Um exemplo prático. O servidor de banco pode rodar a 90% de CPU no fechamento do mês, e está tudo bem. O controlador de domínio a 90% é incidente. Mesma métrica, contratos diferentes. A estrutura registra essa diferença de forma auditável, em vez de deixar na memória de quem configurou.

Princípio 4: dependência de trigger evita a tempestade

O switch de borda de uma filial cai. Sem dependências configuradas, o Zabbix faz o trabalho dele: notifica a queda do switch e dos 40 dispositivos atrás dele. São 41 alertas para um problema.

Três tempestades dessas e o time silencia o canal. No mês seguinte, o alerta importante morre no mudo.

Dependência de trigger resolve por desenho. Os hosts atrás do switch dependem do trigger do switch. Quando ele dispara, os dependentes são suprimidos. Uma queda, um alerta, apontando para a causa.

O mesmo raciocínio vale para a VPN da filial, para o hipervisor com suas VMs e para o próprio proxy do site remoto.

Princípio 5: monitore o que quebra o negócio

CPU e memória todo mundo monitora, porque vem de graça no template. Mas numa clínica, num escritório de advocacia ou numa contabilidade, o que derruba a operação raramente é CPU.

A lista que consideramos inegociável:

• Backup: executou e está restaurável. Status do job, idade do último backup bom e teste periódico de restauração. Backup que nunca restaurou é hipótese. Este é o alerta mais importante do ambiente.
• Disco com previsão, não com susto. As funções forecast() e timeleft() existem para isso. "Esse volume enche em 5 dias" é ticket de terça-feira. "Disco 95% cheio" às 3h da manhã é derrota.
• Certificados e vencimentos. TLS do site, do e-mail e da VPN. Certificado vencido é parada autoinfligida com data marcada. Mesmo assim, segue sendo causa comum de indisponibilidade.
• Serviço de negócio pela porta, não pelo processo. O processo do ERP estar vivo não significa que o ERP responde. Cheque a porta e a resposta. É isso que o usuário sente.
• Latência e perda até o gateway e a operadora. ICMP simples e barato. Resolve metade das discussões sobre internet lenta com um gráfico.
• Nobreak e ambiente físico via SNMP. Carga de bateria, status de energia, temperatura do rack. Bateria vencida é descoberta no pior momento possível, por definição.
• Sinais de segurança. Rajada de bloqueios de conta no AD, serviço de EDR parado, reinicialização pendente há semanas em servidor exposto.

Escala: o que muda com 1.500 dispositivos

Até algumas centenas de hosts, um Zabbix server bem dimensionado resolve sozinho. A partir daí, três coisas passam a importar:

1. Proxies por site. Cada filial ou cliente com seu Zabbix proxy. Coleta local, compressão e tolerância a queda de link: o proxy guarda os dados e sincroniza quando o link volta. Também é o desenho certo de segurança. Um único canal do proxy ao server, em vez de 1.500 conexões atravessando firewalls.
2. Retenção com intenção. Histórico bruto curto, de semanas. Trends longos, de anos. O housekeeper, ou o particionamento do banco em volumes maiores, decide se o seu banco tem 40 GB ou 400. Coletar a cada 30 segundos uma métrica que muda uma vez por dia é só custo de disco.
3. Janelas de manutenção declaradas. Backup e atualização geram picos esperados. Cadastre os períodos de manutenção e o ruído esperado some. A regra continua valendo: alerta que chega é alerta real.

O que o Zabbix não resolve

A parte que nenhuma ferramenta entrega: alguém de plantão que olha, entende e age. Um Zabbix impecável sem operação é um gravador de incidentes caro.

Por isso, nosso serviço de monitoramento 24/7 não vende instalação de Zabbix. Vende a operação: triagem, resposta e revisão mensal dos alertas que dispararam. E dos que deviam existir e ainda não existiam.

Os templates que usamos na nossa operação estão públicos em github.com/9LEVEL/zabbix-templates. Use à vontade. E se preferir que a gente monte e opere, é o que fazemos o dia inteiro.