Como monitorar OLT com Zabbix: guia prático para provedores

Se você opera um provedor de internet (ISP), monitorar OLT não é opcional — é a diferença entre descobrir um problema antes do cliente ligar e passar a manhã apagando incêndio. Aqui vai o jeito que eu monto isso com Zabbix.

Por que Zabbix e não outra coisa

• Grátis e open source. Sem licença por host, sem surpresa no fim do ano.
• SNMP nativo. OLT fala SNMP, Zabbix entende SNMP. Combinação direta.
• Discovery automática. Você não precisa cadastrar uma a uma as 5.000 ONUs ativas — o Zabbix descobre.
• Templates compartilháveis. Comunidade brasileira muito ativa.

O que monitorar em uma OLT

Quatro grandes grupos:

1. Saúde do equipamento: CPU, RAM, temperatura, status das fontes, status dos uplinks.
2. Portas PON: quantas ONUs ativas, potência óptica RX/TX, alarmes.
3. ONUs individuais: sinal óptico de cada uma (essencial para SLA).
4. Tráfego: ifInOctets / ifOutOctets em uplinks e PONs.

A regra de ouro: tudo em template

Eu vejo direto NOC iniciante criando item solto no host. Não faça isso. Templates resolvem três problemas:

Template OLT Genérica
├── Aplicação: Sistema
│   ├── CPU, RAM, Temp, Uptime
├── Aplicação: PON
│   ├── Discovery: portas PON ativas
│   │   ├── ONUs por porta
│   │   ├── RX power
│   │   └── TX power
└── Aplicação: ONUs
    └── Discovery: ONUs ativas (com filtros)

Quando o fabricante muda uma OID, você ajusta no template e 150 OLTs corrigidas de uma vez.

SNMP discovery: o coração da escala

Configure uma regra de descoberta apontando para a OID raiz das ONUs. O Zabbix vai a cada N minutos descobrir novas ONUs e criar itens automaticamente. Defina:

• Intervalo: 30 min para discovery (não exagere — pesa).
• Keep lost resources period: 7 dias (ONU pode estar offline temporariamente).
• Filtros LLD: ignorar interfaces que terminam em .0 ou .1 (gerenciamento).

Triggers que realmente importam

Em vez de criar 200 triggers iguais para 200 OLTs, três triggers de template resolvem 90% dos casos:

{Template OLT:olt.cpu.last()}>85   → Disaster: CPU alta em {HOST.NAME}
{Template OLT:olt.temp.last()}>65  → High: temperatura crítica
{Template OLT:onu.rx.avg(5m)}<-27  → High: ONU {ONU.SERIAL} com sinal degradado

Note o avg(5m) no sinal óptico — evita gerar 50 alertas por flap de fibra durante uma chuva.

Integração com WhatsApp / Telegram

Não adianta monitorar e ninguém ver. Configure mediatype custom apontando para a API do Telegram ou um gateway de WhatsApp Business com webhook. No NOC, fluxo:

1. Disaster → grupo WhatsApp do plantão (24/7).
2. High → grupo de OPS (turno comercial).
3. Average → ticket no Helpdesk.
4. Warning/Info → apenas no dashboard.

Erros que vi (e cometi)

• Polling a cada 30s: seu Zabbix vai morrer. SNMP de OLT pesa. 60s ou 120s para itens não-críticos.
• Sem cache no SNMP: ative SNMPBulkWalk.
• Discovery sem filtro: você vai descobrir 50.000 ONUs e o banco implode.
• Trigger sem hysteresis: valor oscila no limiar e gera alert/ok/alert/ok 200×/h.

Resultado real

Em uma operação que monitorei, a combinação Zabbix + Python + alertas inteligentes derrubou o tempo médio de detecção de falha de 18 minutos para 2 minutos. Cliente liga reclamando? Já estamos consertando.

Próximos passos

Quer mergulhar mais fundo? Veja também:

• BGP para iniciantes — BCOP na prática
• IA no NOC: o que faz sentido e o que é hype
• Monitorando 147 mil itens com Zabbix

Tem dúvida específica de uma OLT? Manda no WhatsApp.