Monitoramento de rede de provedor com Zabbix e Grafana: SNMP, BGP, OLTs e alertas

Em um provedor, o cliente quase sempre descobre o problema antes do NOC: o link de trânsito saturou, a sessão BGP com o IX caiu, a OLT de um bairro perdeu metade das ONUs. Monitorar servidores é o fácil. O que evita incidentes é monitorar a rede: roteadores, switches, OLTs, rádios e os enlaces entre eles.

Neste tutorial você vai ver o que monitorar em um provedor com Zabbix e Grafana, de onde vêm os dados, os erros que tornam os gráficos enganosos e como montar alertas que a equipe não aprenda a ignorar.

O que monitorar em um provedor

Para os servidores, um agente resolve. Para quase todo o resto, a coleta é por SNMP.

SNMP: a base de tudo

Roteadores, switches e OLTs expõem contadores e estados por SNMP, organizados em MIBs. Antes de cadastrar no Zabbix, vale testar a coleta direto do servidor:

# Nome e descrição do equipamento
snmpget -v2c -c COMUNIDADE 10.0.0.1 1.3.6.1.2.1.1.5.0 1.3.6.1.2.1.1.1.0

# Nomes das interfaces
snmpwalk -v2c -c COMUNIDADE 10.0.0.1 1.3.6.1.2.1.31.1.1.1.1

O Zabbix tem templates oficiais por fabricante (MikroTik, Huawei, Cisco, Juniper e outros) que descobrem sozinhos as interfaces e sensores por low-level discovery. São um bom ponto de partida, mas genéricos: coletam muita coisa irrelevante e deixam de fora itens específicos de provedor.

• Prefira SNMPv3 com autenticação e criptografia. No v2c, a comunidade trafega em texto puro.
• Restrinja o acesso SNMP por ACL no equipamento, só para os IPs dos servidores e proxies de monitoramento.
• Nunca deixe o SNMP acessível pela internet: além do risco, ele é usado em ataques de amplificação.

Interfaces e contadores de 64 bits

O erro mais comum em monitoramento de rede é usar os contadores de 32 bits (ifInOctets, ifOutOctets). Um contador de 32 bits chega ao máximo em cerca de 34 segundos em um link de 1 Gbps cheio, e em menos de 4 segundos em 10 Gbps. Com coleta a cada minuto, o gráfico mostra valores errados ou quedas que não existiram.

Use sempre os contadores de 64 bits da IF-MIB:

Além do tráfego, monitore erros e descartes por interface. Um enlace com erros CRC crescendo é um cabo, conector ou transceptor falhando, e costuma dar sinais dias antes de cair.

Sessões BGP

Uma sessão BGP caída com um trânsito ou com o IX pode passar despercebida por horas se houver outro caminho: o tráfego continua fluindo, só que mais caro ou mais lento. O estado de cada sessão está na BGP4-MIB:

# Estado das sessões BGP (6 = established)
snmpwalk -v2c -c COMUNIDADE 10.0.0.1 1.3.6.1.2.1.15.3.1.2

Essa MIB padrão só cobre sessões IPv4 em muitos equipamentos. Sessões IPv6, VRFs e a quantidade de prefixos recebidos por sessão normalmente exigem MIBs do fabricante, e cada um organiza isso de um jeito.

O que vale alertar: sessão fora de established, quantidade de prefixos recebidos muito abaixo do normal (o trânsito parou de mandar a tabela completa) ou próxima do maximum-prefix.

Níveis ópticos e OLTs

Em provedores de fibra, boa parte das falhas é óptica: conector sujo, fibra dobrada, transceptor degradando, splitter com problema. Os transceptores com DDM informam potência de transmissão, recepção, temperatura e tensão, e o nível de recepção caindo aos poucos avisa antes de o enlace cair.

Nas OLTs, os indicadores que mais importam são a quantidade de ONUs online por porta PON e o sinal de cada uma. Uma porta que perde várias ONUs ao mesmo tempo indica problema na rede de distribuição, não no cliente.

O desafio é que cada fabricante de OLT (Huawei, ZTE, Fiberhome, Parks, Nokia e outros) expõe esses dados de um jeito, com MIBs próprias e, às vezes, só por linha de comando. Em redes com dezenas de milhares de ONUs, coletar sinal de todas a cada minuto também sobrecarrega a OLT e o Zabbix.

Proxies por POP e escala

Em uma rede com vários POPs, o servidor Zabbix central não deve coletar tudo diretamente. O Zabbix Proxy coleta os dados localmente e envia ao servidor:

• se o enlace com o POP cair, o proxy continua coletando e envia tudo quando voltar, sem buracos no histórico;
• a carga de coleta é distribuída, e o SNMP não atravessa o backbone;
• só uma conexão por POP precisa ser liberada até o servidor central.

A outra metade da escala é o banco de dados. Com milhares de interfaces coletadas a cada minuto, o histórico cresce rápido, e um banco sem particionamento ou com retenção mal planejada é a causa mais comum de Zabbix lento.

Alertas que não viram ruído

O risco de um monitoramento completo é gerar alertas demais. Quando o NOC recebe centenas de notificações por dia, para de ler, e o alerta importante passa junto. Os cuidados que fazem diferença:

• Dependências. Se o roteador de um POP cair, os 50 equipamentos atrás dele não devem gerar 50 alertas. O Zabbix suporta dependência entre triggers, mas ela precisa refletir a topologia real.
• Limites por elemento. 80% de ocupação é crítico em um trânsito e normal em um enlace de cliente. Templates genéricos usam o mesmo limite para tudo.
• Tempo de confirmação. Um pico de dez segundos não é incidente. Alertar só quando a condição persiste.
• Gravidade e destino. O que acorda alguém de madrugada é diferente do que vira relatório semanal.
• Revisão periódica. Alertas que disparam toda semana e ninguém trata devem ser corrigidos ou removidos.

Grafana para cada público

Com o plugin do Zabbix, o Grafana lê os dados coletados e monta painéis independentes da interface do Zabbix. A vantagem é poder fazer um painel para cada público:

• NOC: mapa da rede, enlaces críticos, sessões BGP e alertas ativos em uma tela;
• Gestão: ocupação dos trânsitos, crescimento de tráfego e capacidade por POP, para planejar upgrades antes de saturar;
• Clientes corporativos: o tráfego do próprio link, sem acesso ao restante da rede.

Precisa só acompanhar CPU, memória, disco e disponibilidade de alguns servidores e sites, sem manter um Zabbix? O BTECH Monitor é gratuito e instala com um comando.

Do tutorial à produção

Saber o que monitorar é o começo. Ter um monitoramento em que o NOC confia, cobrindo a rede inteira sem soterrar a equipe em alertas, é o que este tutorial não cobre:

• Templates para a sua rede. Itens e descobertas ajustados aos seus fabricantes de roteadores, switches e OLTs, sem coletar o que não importa.
• BGP, óptica e OLTs. Sessões IPv4 e IPv6, prefixos por sessão, sinal de transceptores e ONUs coletados sem sobrecarregar os equipamentos.
• Arquitetura e banco de dados. Proxies por POP, banco particionado e retenção planejada para anos de histórico.
• Alertas com dependências. Topologia refletida nos triggers, limites por elemento e escalonamento por gravidade.
• Painéis e relatórios. Grafana para NOC, gestão e clientes, e relatórios de capacidade para planejar a rede.

Perguntas frequentes

Zabbix ou Grafana: qual usar?

Os dois, com papéis diferentes. O Zabbix coleta os dados, guarda o histórico e dispara os alertas. O Grafana lê os dados do Zabbix (pelo plugin oficial) e monta painéis mais flexíveis e bonitos para o NOC, a gestão e os clientes.

SNMP v2c ou v3?

O v3 tem autenticação e criptografia, e deve ser preferido sempre que o equipamento suportar e a coleta passar por redes que você não controla. O v2c ainda é muito usado em redes de gerência isoladas, mas a comunidade trafega em texto puro e precisa ser restrita por ACL no equipamento.

Por que o gráfico de tráfego mostra quedas falsas em links de 10G?

Provavelmente o item usa os contadores de 32 bits (ifInOctets e ifOutOctets), que dão a volta em segundos em links rápidos. Use os contadores de 64 bits (ifHCInOctets e ifHCOutOctets), que os templates atuais do Zabbix já usam por padrão.

Quantos equipamentos um Zabbix aguenta?

Depende muito mais da quantidade de itens e do intervalo de coleta do que do número de equipamentos. Um roteador de borda com centenas de interfaces pode gerar mais carga que dezenas de servidores. Para redes grandes, o que define a escala é o banco de dados e o uso de proxies.