Monitoramento proativo com Zabbix para ISPs: o que seu NOC precisa ver antes que o assinante ligue
Na operação diária de um ISP, existem dois tipos de problemas: os que sua equipe detecta primeiro, e os que o assinante detecta primeiro. A diferença entre esses dois cenários é a diferença entre um incidente gerenciado e uma crise. Entre um cliente que renova e um que cancela.
O monitoramento reativo (esperar o ticket, atender a reclamação, então investigar) era aceitável quando os assinantes tinham poucas alternativas. Hoje não é mais. E a boa notícia é que as ferramentas para fazer monitoramento proativo são acessíveis, maduras e completamente viáveis para ISPs de qualquer porte na América Latina.
O Zabbix é a plataforma central dessa stack. Este guia cobre o que monitorar, como estruturar e como integrar com o Grafana para que seu NOC tenha visibilidade real antes que o telefone toque.
Por que o monitoramento reativo destrói a experiência do assinante
O monitoramento reativo tem um problema estrutural: o assinante é sempre o primeiro detector. Quando uma OLT perde uma placa, quando um uplink satura a 98%, quando uma sessão BGP cai às 3 da madrugada, o primeiro sinal visível para o ISP é o volume de chamadas ao suporte.
Esse modelo tem consequências em cascata. O tempo entre a falha e a detecção (MTTD) pode ser de 15, 30, 60 minutos. O tempo de resolução (MTTR) só começa a correr quando o NOC recebe o alerta humano. Enquanto isso, o assinante já formou sua opinião sobre a qualidade do serviço.
Além da experiência: em ambientes com SLAs corporativos, cada minuto de falha não detectada é minuto acumulado contra o uptime comprometido em contrato. A detecção tardia não é apenas um problema de imagem: pode ter custo econômico direto.
O monitoramento proativo inverte esse ciclo. O sistema detecta a degradação (não a falha total, mas a degradação) e alerta a equipe antes que o assinante perceba como problema.
O que um ISP deve monitorar: a lista que não pode faltar
O erro mais comum ao começar com Zabbix é monitorar apenas o que é fácil de adicionar (ping à gestão dos equipamentos) e assumir que isso é suficiente. Não é. Existem categorias de monitoramento que devem estar ativas para ter visibilidade real:
Interfaces de rede (estado e utilização)
O estado operacional de cada interface crítica (uplinks ao trânsito, enlaces entre POPs, interfaces para OLTs) deve ser monitorado com alertas diferenciados: um alerta quando a interface cai (ifOperStatus) e outro quando a utilização supera limiares (por exemplo, alerta a 80% da capacidade, crítico a 95%). A saturação de enlace que chega a 100% durante horas degrada a experiência sem gerar uma queda visível: é exatamente o tipo de problema que o assinante sente e o NOC não vê sem monitoramento de utilização.
Sessões BGP
Cada sessão eBGP e iBGP deve ter um item no Zabbix com alerta imediato ante mudança de estado. Uma sessão BGP caída pode significar perda de trânsito, de peers ou de redundância de roteamento. O tempo de detecção aceitável para uma sessão BGP é de segundos, não minutos. (Sobre os erros de configuração BGP que amplificam esses problemas, veja nosso artigo sobre BGP para ISPs.)
Adjacências OSPF e IS-IS
Em redes com IGP rodando no core ou na distribuição, a perda de uma adjacência OSPF ou IS-IS pode causar convergência não ótima ou buracos de roteamento que não são evidentes até que o tráfego comece a cair. Monitorar o número de adjacências ativas por roteador e alertar ante qualquer redução.
CPU e memória em equipamentos de rede
Um roteador com CPU a 95% está prestes a começar a perder pacotes de controle, degradar BGP, ou simplesmente travar. Monitorar CPU e memória em todos os equipamentos de core e distribuição, com limiares que disparem alertas preventivos antes de chegar ao limite.
OLTs e estado de portas PON
Em redes GPON/EPON, o estado das placas de linha e das portas PON deve ser monitorado em tempo real. A perda de uma placa OLT pode afetar dezenas ou centenas de assinantes simultaneamente. Os contadores de erros (FEC corrections, BIP errors) são indicadores precoces de problemas ópticos antes que o ONT perca sinal completamente.
RADIUS e autenticação
Se o servidor RADIUS não responde, os assinantes não conseguem se autenticar quando reiniciam sua conexão. Em redes com muitos cortes e reconexões simultâneas (um corte de luz em um bairro, por exemplo), a saturação ou queda do RADIUS pode transformar um incidente menor em um problema massivo. Monitorar disponibilidade do RADIUS, tempo de resposta de autenticações e taxa de erros de autenticação.
Latência de loop (round-trip time interno)
A latência interna entre POPs próprios é um indicador de saúde da rede que raramente falha de repente mas se degrada gradualmente. Monitorar RTT entre pontos-chave da rede com limiares históricos permite detectar aumentos de latência que ainda não se expressam como falha mas que antecipam um problema de capacidade ou de rota.
Uplinks de trânsito e utilização total
A saturação dos uplinks de trânsito impacta diretamente na experiência do assinante com destinos na internet. Monitorar utilização total e por direção (in/out), com projeções de crescimento se possível.
Zabbix como plataforma: por onde começar
O Zabbix é uma plataforma de monitoramento open source com mais de 20 anos de desenvolvimento ativo. Para ISPs é especialmente adequada por três razões: suporte nativo de SNMP, capacidade de escalar a dezenas de milhares de itens e uma coleção crescente de templates oficiais para os vendors mais comuns.
Templates oficiais para vendors ISP
O Zabbix mantém uma biblioteca de templates que cobre os principais vendors:
- Huawei: templates para VRP (router/switch), Huawei CE series (switches de datacenter), SmartAX (OLTs MA5600/MA5800). O template oficial de Huawei VRP cobre interfaces, BGP, OSPF, CPU e memória via SNMP.
- MikroTik: template oficial que cobre RouterOS via SNMP e via API. Inclui interfaces, sessões BGP (se RouterOS >= 7.x), CPU, memória e tabelas de roteamento.
- Cisco IOS/IOS-XE/IOS-XR: templates que cobrem interfaces, BGP, OSPF, ISIS, CPU e memória. Cisco IOS-XR tem suporte adicional via gRPC/gNMI para telemetria streaming.
Esses templates são um ponto de partida, não uma configuração final. Em produção sempre é preciso ajustar limiares, desabilitar itens irrelevantes e adicionar itens custom para métricas específicas de cada rede.
SNMP polling: a base do monitoramento de rede
A maioria das métricas de rede é obtida via SNMP v2c ou v3. A configuração básica no Zabbix para um equipamento Huawei:
# No equipamento Huawei (VRP)
snmp-agent
snmp-agent community read COMUNIDAD-LECTURA
snmp-agent sys-info version v2c v3
snmp-agent target-host trap address udp-domain 10.0.0.100 params securityname COMUNIDAD-LECTURA
# No Zabbix (host configuration)
SNMP community: {$SNMP_COMMUNITY}
SNMP version: SNMPv2
Port: 161
Para redes com requisitos de segurança mais rigorosos, SNMPv3 com autenticação SHA e privacidade AES é a opção correta:
snmp-agent usm-user v3 ZABBIX-USER
authentication-mode sha PASSPHRASE-AUTH
privacy-mode aes128 PASSPHRASE-PRIV
ICMP para disponibilidade básica
Além do SNMP polling, o Zabbix deve fazer checks ICMP periódicos ao IP de gestão de cada equipamento. Isso detecta a perda total de acesso quando o SNMP já não responde. O intervalo recomendado para equipamentos críticos é de 30 a 60 segundos.
Zabbix Agent para servidores de infraestrutura
Para os servidores que fazem parte da infraestrutura ISP (RADIUS, DNS autoritativo, portais cativos, servidores de gestão), o agente Zabbix permite monitoramento mais granular: disco, processos específicos, logs, serviços. Instalar o agente nesses servidores e usar os templates de Linux correspondentes.
Traps SNMP vs polling ativo: quando usar cada um
Esta é uma das perguntas que mais frequentemente gera confusão em equipes de NOC que estão estruturando seu monitoramento.
SNMP Traps são mensagens que o equipamento de rede envia ativamente ao servidor de monitoramento quando ocorre um evento específico: uma interface cai, um limiar de CPU é ultrapassado, uma adjacência OSPF cai. São imediatos: o tempo entre o evento e a notificação pode ser de milissegundos. Sua desvantagem é que dependem de que o equipamento esteja ativo e configurado para enviar o trap. Se o equipamento falha de forma catastrófica, pode não conseguir enviar o trap.
Polling ativo é o ciclo inverso: o Zabbix consulta periodicamente o equipamento (a cada 1, 5 ou 10 minutos dependendo do item) e registra o valor. Detecta tanto falhas quanto degradações graduais. Sua desvantagem é a latência de detecção: se um enlace cai e o próximo poll é em 3 minutos, a detecção se atrasa até esse momento.
A resposta correta para um ISP é usar ambos de forma complementar:
- Traps SNMP para eventos discretos de alta criticidade: mudança de estado de interface, mudança de estado BGP, mudança de papel em protocolos de alta disponibilidade (VRRP, MC-LAG). Esses eventos merecem notificação imediata.
- Polling ativo para métricas contínuas: utilização de CPU, utilização de interface, latência, memória. O polling constrói o histórico de tendências que permite detectar degradações graduais.
No Zabbix, a recepção de traps se configura habilitando o processo zabbix_trap_receiver e configurando o snmptrapd como receptor:
# /etc/snmp/snmptrapd.conf
authCommunity log,execute,net COMUNIDAD-TRAP
traphandle default /usr/lib/zabbix/externalscripts/zabbix_trap_handler.pl
Integração com Grafana para dashboards operacionais no NOC
O Zabbix tem suas próprias visualizações, mas para dashboards de NOC pensados para serem vistos em telas grandes durante turnos de 8 horas, o Grafana oferece uma experiência significativamente melhor.
A integração é feita via o plugin oficial de Zabbix para Grafana (desenvolvido por Alexander Alexandrov, atualmente mantido como plugin comunitário):
grafana-cli plugins install alexanderzobnin-zabbix-app
Uma vez configurado o datasource apontando para a API do Zabbix, é possível construir dashboards que combinem:
- Mapa de rede em tempo real: estado de cada enlace crítico com cor por estado (verde/amarelo/vermelho segundo utilização ou disponibilidade).
- Tabela de alertas ativos: ordenada por severidade e tempo de início, com informação de qual equipamento e qual métrica disparou o alerta.
- Gráficos de utilização de uplinks: em tempo real e com janela histórica de 24 horas para identificar padrões.
- Painel de sessões BGP: estado de cada sessão, tempo ativo, prefixos recebidos/anunciados.
- Disponibilidade por zona geográfica: se os equipamentos estão etiquetados por zona no Zabbix, um mapa por região mostra rapidamente onde está o problema.
O objetivo do dashboard de NOC não é mostrar toda a informação disponível: é permitir que o operador de turno identifique em segundos se há algo que requer ação, e o que é esse algo.
Alertas escalonados: NOC, engenharia e plantão noturno
Ter visibilidade é condição necessária mas não suficiente. A visibilidade precisa se traduzir em ação, e para isso o esquema de alertas deve estar pensado para o contexto operacional real.
Um modelo de escalonamento efetivo para ISPs tem três níveis:
Nível 1 — NOC (alerta no dashboard e notificação imediata)
Todos os eventos críticos chegam ao dashboard do NOC e geram uma notificação via canal de mensagens (Telegram, Slack, e-mail). O operador de NOC tem o primeiro nível de resposta: verificar, tentar resolver com procedimentos documentados, ou escalar.
Nível 2 — Engenharia (se o NOC não resolve em N minutos)
Se o alerta não é reconhecido ou não é resolvido no tempo definido (por exemplo, 15 minutos para um uplink caído), o Zabbix escala automaticamente a notificação para a equipe de engenharia de redes. O Zabbix suporta escalonamento nativo via “escalation steps” na configuração de ações.
# Exemplo de ação com escalonamento no Zabbix
Action: UPLINK-DOWN
Step 1 (0 min): Notificar NOC-Team via Telegram
Step 2 (15 min, se não resolvido): Notificar Engenharia-Rede via Telegram + chamada
Step 3 (30 min, se não resolvido): Notificar Gerência-Técnica
Nível 3 — Plantão noturno (horário fora de expediente)
Para incidentes de alta severidade fora do horário do NOC, o escalonamento deve incluir contato telefônico ou via PagerDuty. Integrar o Zabbix com serviços de on-call management (PagerDuty, OpsGenie, ou um esquema custom via webhook) garante que um incidente às 3 da madrugada não espera até as 9 para ser atendido.
O critério de severidade deve ser acordado com a equipe antes de configurá-lo: nem todo problema justifica acordar alguém. Uma interface de gestão caída às 2 da manhã provavelmente pode esperar. Um uplink de trânsito principal caído, não.
Métricas-chave: os números que importam
Um sistema de monitoramento bem configurado produz métricas que permitem tanto a detecção em tempo real quanto a análise de tendências. As métricas que todo ISP deve poder responder com dados:
Disponibilidade de serviço
Porcentagem de tempo que os enlaces e serviços críticos estiveram operacionais no período. O Zabbix calcula isso automaticamente para cada item quando o relatório de SLA é configurado. O objetivo deve ser definido em função dos compromissos contratuais com clientes.
Latência média e percentil 95
A latência média pode ocultar picos. O percentil 95 de latência (o valor que 95% das medições não superam) é um indicador mais honesto da experiência do assinante. Monitorar ambos.
Perda de pacotes
O Zabbix mede perda de pacotes nos checks ICMP. Uma perda de 1-2% em um enlace é um indicador precoce de congestionamento ou de um problema físico incipiente. Definir limiares: alerta a 1%, crítico a 5%.
Saturação de enlace (pico e média)
A utilização de pico (máximo em 5 minutos) e a média nos períodos de maior tráfego (busy hour) são os dois números que determinam se é preciso ampliar capacidade. Um enlace que tem média de 40% mas picos de 95% durante 2 horas por dia tem um problema de capacidade mesmo que a média “pareça boa”.
MTTD e MTTR operacionais
Com os dados do Zabbix é possível calcular o tempo médio de detecção (tempo entre início do evento e primeiro reconhecimento no sistema) e o tempo médio de resolução. Esses dois KPIs devem estar no relatório operacional mensal do NOC.
Notas sobre vendors: Huawei, MikroTik e Cisco
Cada vendor tem particularidades que afetam como o monitoramento é implementado:
Huawei VRP: o suporte SNMP é completo e estável. As MIBs da Huawei para BGP (hwBgp), OSPF e IS-IS são bem documentadas. O template oficial do Zabbix para Huawei VRP cobre a maioria dos casos de uso. Para OLTs Huawei SmartAX, o monitoramento via SNMP de portas PON (estado, potência óptica rx, erros FEC) requer as MIBs específicas da série, disponíveis no portal de suporte da Huawei.
MikroTik RouterOS: para versões anteriores à 7.x, o monitoramento BGP via SNMP tem limitações (a MIB padrão BGP4-MIB nem sempre está completamente implementada). A alternativa é usar a API do RouterOS a partir do Zabbix via scripts externos, ou atualizar para RouterOS 7.x onde o suporte SNMP para BGP é mais completo. Para monitoramento de interfaces e recursos do sistema, o template oficial funciona bem a partir do RouterOS 6.x.
Cisco IOS-XE / IOS-XR: o suporte SNMP na Cisco é maduro. O IOS-XR adiciona a possibilidade de usar gRPC/gNMI para telemetria streaming, que é mais eficiente que o polling para redes com milhares de métricas. Integrar telemetria gNMI com Zabbix requer um collector intermediário (como Telegraf + InfluxDB, ou um script custom), mas é a direção correta para redes Cisco de escala média/grande.
Nossa experiência em campo
Na Ayuda.LA trabalhamos com equipes de NOC de ISPs de diferentes portes na América Latina. O padrão que vemos com mais frequência não é falta de ferramentas: é Zabbix (ou outro sistema) instalado mas configurado apenas para disponibilidade básica (ping), sem cobertura dos itens que realmente antecipam problemas.
O salto de “monitoramento de disponibilidade” para “monitoramento proativo operacional” não requer substituir nada. Requer adicionar itens, definir limiares com critério operacional, construir dashboards orientados ao operador de NOC e acordar um processo de escalonamento que funcione às 3 da madrugada.
Na maioria dos casos, esse trabalho pode ser feito em dias ou semanas (não meses), e o impacto no MTTD é imediato.
Conheça mais sobre nossos serviços de NOC e monitoramento para ISPs.
Quer revisar ou estruturar o monitoramento do seu NOC?
Podemos avaliar sua configuração atual de Zabbix, identificar as lacunas de cobertura mais críticas e propor uma estrutura de alertas e dashboards adaptada à sua operação. Sem necessidade de substituir o que você já tem funcionando.
Vamos conversar sobre seu NOC →
Tem perguntas sobre Zabbix, SNMP ou monitoramento de redes ISP? Escreva para [email protected] — respondemos todas as mensagens.