Monitoramento SNMP para provedores: o que realmente medir
Muito provedor monitora a coisa errada. O painel está cheio de bolinhas verdes, o ICMP responde, o uptime do roteador está em dias — e mesmo assim o cliente liga reclamando de lentidão, jitter na chamada de voz e Netflix travando. O motivo é simples: "ping verde" responde uma única pergunta — o equipamento está ligado? Para um NOC de ISP isso é o piso, não o teto. O SNMP existe para medir o que acontece dentro do equipamento e do link, e é exatamente aí que o incidente se forma antes de virar chamado.
Este artigo trata do que coletar de verdade via SNMP, com OIDs concretos e thresholds que fazem sentido na operação real de um provedor brasileiro.
Disponibilidade não é saúde
Um roteador pode estar 100% acessível e ainda assim entregar uma experiência ruim: interface saturada, CPU em teto, buffer estourando, sessão BGP oscilando. Disponibilidade (o equipamento responde) e saúde (o equipamento entrega bem) são coisas diferentes. Monitorar só a primeira é operar no escuro.
A regra prática: toda métrica que vira reclamação de cliente precisa de uma série temporal SNMP antes de o cliente perceber. Se a saturação do uplink só aparece para você quando o suporte enche, o monitoramento falhou.
Os quatro pilares do que medir
1. Tráfego e saturação de interface
A base de tudo. Use os contadores de 64 bits da IF-MIB — em links de 1 Gbps ou mais, os contadores de 32 bits (ifInOctets/ifOutOctets, OIDs .1.3.6.1.2.1.2.2.1.10 e .16) dão wrap em segundos e poluem o gráfico.
ifHCInOctets—.1.3.6.1.2.1.31.1.1.1.6ifHCOutOctets—.1.3.6.1.2.1.31.1.1.1.10ifHighSpeed—.1.3.6.1.2.1.31.1.1.1.15(capacidade da interface, para calcular o % de uso)
O que importa não é o valor instantâneo, e sim o percentil 95 ao longo do dia e o pico no horário nobre (por volta das 20h às 23h). Um threshold de alerta razoável: warning em 70% de utilização sustentada, crítico em 85%. Acima disso você já tem fila e descarte, mesmo sem o link "cair". Vale tanto para uplinks de trânsito quanto para a sua participação no IX.br — saturar a porta do PIX é um clássico que ninguém vê até a latência subir.
2. Erros e descartes — onde a degradação se esconde
Saturação derruba performance; erro de camada física derruba sessão. Estes contadores entregam fibra suja, transceiver degradando ou patch cord ruim antes de o link cair de vez:
ifInErrors—.1.3.6.1.2.1.2.2.1.14ifOutErrors—.1.3.6.1.2.1.2.2.1.20ifInDiscards/ifOutDiscards—.1.3.6.1.2.1.2.2.1.13e.19
Aqui o threshold não é percentual de banda, é taxa de erro: qualquer erro crescente e contínuo já é sinal de investigar. Descartes de saída quase sempre apontam para fila por congestionamento — correlacione com a saturação do pilar 1. Em redes FTTH, erro na uplink da OLT costuma ser o primeiro sintoma de um problema óptico no backbone.
3. Saúde do hardware: CPU, memória e temperatura
Roteador com CPU em teto não processa o plano de controle (BGP, OSPF, ARP) na velocidade certa, e a rede fica "lenta sem motivo". Os OIDs aqui são vendor-specific — não existe padrão único, e essa é uma das dores reais do monitoramento multi-marca:
- MikroTik: CPU via HOST-RESOURCES-MIB (
hrProcessorLoad,.1.3.6.1.2.1.25.3.3.1.2); temperatura, tensão e fonte viamtxrHealthda MIKROTIK-MIB (.1.3.6.1.4.1.14988.1.1.3). O RouterOS expõe boa parte do básico pela HOST-RESOURCES-MIB padrão. - Cisco: CPU via CISCO-PROCESS-MIB (
cpmCPUTotal5minRev,.1.3.6.1.4.1.9.9.109.1.1.1.1.8); memória via CISCO-MEMORY-POOL-MIB; ambiente via CISCO-ENVMON-MIB. - Huawei: CPU via
hwEntityCpuUsage(.1.3.6.1.4.1.2011.5.25.31.1.1.1.1.5), com sub-MIBs próprias para temperatura e fonte. - Juniper: JUNIPER-MIB /
jnxOperatingTablepara CPU, temperatura e estado de placas.
Threshold de CPU: warning em 75%, crítico em 90% sustentado. Picos curtos são normais; o que mata é o platô. Memória acima de 85% em equipamento que carrega tabela BGP full merece atenção — esgotamento de RAM com a tabela de rotas crescendo é causa real de reboot inesperado.
4. Roteamento e sessões: BGP via SNMP
Para quem tem ASN e faz peering no IX.br ou trânsito IP, monitorar o estado das sessões BGP é inegociável. A BGP4-MIB expõe:
bgpPeerState—.1.3.6.1.2.1.15.3.1.2(6 =established; qualquer outro valor sustentado é problema)bgpPeerFsmEstablishedTime—.1.3.6.1.2.1.15.3.1.16(tempo desde o últimoestablished; flaps zeram esse contador)
O alerta deve disparar quando o estado sai de established e quando esse tempo reseta com frequência (sessão flapando). Uma sessão de trânsito que oscila tira e reintroduz rotas, causando reconvergência e perda de pacote intermitente — o tipo de problema que o cliente sente e o ping não mostra. Vale lembrar que muitos equipamentos modernos expõem BGP melhor por telemetria/gNMI do que por SNMP, mas para boa parte do parque instalado no Brasil a BGP4-MIB ainda é o caminho.
Polling, intervalo e o erro de só olhar média
Coletar a cada 5 minutos esconde microestouros. Para uplinks críticos e portas de PIX, vá para polling de 1 minuto. E nunca confie só na média: uma interface com média de 40% pode estar batendo 100% nos picos de 30 segundos que justamente derrubam jogos online e chamadas de voz. Guarde os dados com resolução suficiente para enxergar o percentil 95 e o pico, não só a linha suavizada.
Outra armadilha: o SNMPv2c manda a community em texto puro. Em rede de gerência exposta, prefira SNMPv3 com autenticação e criptografia — não é paranoia, é higiene básica, ainda mais com as obrigações de guarda e segurança que recaem sobre a operação de um provedor.
Do dado ao incidente: correlação é o que falta
Coletar OID é o fácil. O difícil é transformar centenas de séries temporais, de equipamentos MikroTik, Cisco e Huawei misturados, em alerta acionável sem afogar o plantão em ruído. Isso exige inventário confiável (qual equipamento, qual papel, qual cliente atrás dele), thresholds por tipo de elemento e correlação entre pilares — saturação com descarte com CPU alta é um incidente; cada um isolado pode não ser nada.
É justamente esse trabalho de juntar inventário, IPAM, monitoramento SNMP e documentação num só lugar que a CloudFace construiu no NetPulse, a plataforma de NOC multi-tenant que usamos na nossa própria operação. Mas a ferramenta é meio: o que evita incidente é medir a coisa certa.
Se o seu painel está verde e o telefone está tocando, há um descompasso entre o que você monitora e o que seus clientes sentem. A CloudFace ajuda a fechar essa lacuna, seja via consultoria e NOC, seja com o NetPulse. Se quiser, chame no WhatsApp para um diagnóstico inicial gratuito do seu monitoramento — direto ao ponto, sem compromisso.