Marcio Cunha

Como consolidar métricas de rede usando Prometheus e SNMP

Descubra como monitorar switches, roteadores e servidores legados convertendo dados MIB SNMP em séries temporais estruturadas no Prometheus.

Marcio Cunha•6 min
Também disponível em:EnglishEspañol
Resumo
  • A conversão de dados SNMP em séries temporais no Prometheus exige o uso do snmp_exporter para traduzir o protocolo antigo em métricas modernas.
  • Mapear a base de dados MIB correta evita leituras corrompidas e alivia o consumo de CPU em dispositivos de rede legados.
  • Ajustar os intervalos de coleta previne gargalos operacionais e picos de lentidão em roteadores e switches de missão crítica.
  • Estruturar rótulos consistentes facilita a identificação rápida de falhas físicas e gargalos de banda na infraestrutura.
  • Testar a resiliência das consultas garante alertas confiáveis antes que falhas de hardware impactem os usuários finais.

Por que o SNMP ainda importa na infraestrutura moderna

Muitos administradores de sistemas pensam que protocolos antigos como o SNMP (Simple Network Management Protocol, um protocolo padrão para gerenciar e monitorar dispositivos em uma rede IP) estão ultrapassados. Na prática, switches de borda, roteadores industriais e servidores legados que rodam em sua infraestrutura continuam falando essa mesma língua herdada de décadas passadas. Para quem busca uma visão unificada da rede, ignorar esses equipamentos não é uma opção viável. O grande desafio surge quando tentamos colocar dados tabulares e estáticos em bancos de dados modernos baseados em séries temporais, que preferem fluxos contínuos de números ordenados cronologicamente.

Quando ligamos ferramentas modernas de observabilidade a ativos legados, esbarramos na barreira da tradução. O Prometheus, por exemplo, é um coletor formidável que funciona puxando dados de forma ativa, mas ele não entende nativamente a estrutura hierárquica e complexa dos arquivos MIB (Management Information Base, que funcionam como dicionários explicando o significado de cada número e variável em um dispositivo de rede). É justamente aqui que entra a necessidade de traduzir o mundo legado do SNMP para o ecossistema estruturado de métricas que o Prometheus consome diariamente, permitindo análises avançadas de tráfego, pacotes descartados e uso de CPU em switches antigos.

Como funciona a tradução de MIBs para séries temporais

Para fazer essa ponte entre o protocolo antigo e o coletor moderno, utilizamos um tradutor intermediário conhecido como exporter. No caso do monitoramento de rede, o componente padrão da comunidade é o snmp_exporter, um software que recebe uma requisição HTTP, traduz essa chamada em comandos SNMP direcionados ao switch ou roteador, pega as respostas numéricas brutas e as devolve formatadas no padrão que o Prometheus entende. Na prática, isso significa que cada oid (Object Identifier, que funciona como o endereço numérico exato de uma métrica dentro de um dispositivo) é convertido em uma chave legível com rótulos descritivos.

Gerar essas séries temporais exige cuidado com o mapeamento das MIBs proprietárias dos fabricantes. Se você monitora um parque misto com equipamentos de marcas diferentes, cada um terá suas próprias tabelas numéricas para medir temperatura, consumo de energia ou tráfego nas portas Ethernet. Para manter a sanidade operacional, utilizamos arquivos de configuração que convertem OIDs obscuros como .1.3.6.1.4.1.9.9.109.1.1.1.1.5 em uma métrica limpa chamada cpmCPUTotal5min. Caso você precise investigar problemas de conectividade mais profundos ou falhas de pacotes, vale a pena conferir nosso guia prático sobre como auditar fluxos de rede no Kubernetes com eBPF, complementando a visibilidade entre o mundo físico e o virtual.

Arquitetura e planejamento do coletor SNMP

Implementar o monitoramento SNMP em larga escala sem planejamento pode derrubar o plano de controle dos seus roteadores antigos. Dispositivos de rede legados geralmente possuem processadores modestos e memória limitada; se você disparar centenas de consultas simultâneas solicitando tabelas inteiras de roteamento ou contadores de interfaces, o equipamento pode simplesmente travar por exaustão de recursos. Por isso, a arquitetura exige o uso de caches inteligentes, limites rigorosos de concorrência e intervalos de varredura bem dimensionados, geralmente variando entre sessenta segundos e cinco minutos para métricas menos críticas.

Outro ponto crítico no design da coleta é a separação de módulos dentro do arquivo de configuração do exporter. Em vez de tentar ler todas as MIBs possíveis de uma só vez, dividimos os alvos em perfis específicos para switches de acesso, roteadores de borda e servidores físicos desatualizados. Na prática, isso otimiza o tráfego na rede de gerência e garante que o Prometheus receba apenas os dados estritamente necessários para o diagnóstico operacional. Se o seu ambiente também sofre com quedas de energia ou oscilações elétricas que reiniciam esses equipamentos inesperadamente, recomendo cruzar esses dados de rede com as orientações do artigo sobre como diagnosticar quedas de tensão em fontes com osciloscópio para isolar falhas de hardware.

Passo a passo para configurar o snmp_exporter

Para colocar a mão na massa e estruturar o seu coletor, vamos executar uma sequência direta de comandos na linha de comando do seu servidor de monitoramento. Certifique-se de ter o Docker instalado ou execute a ferramenta diretamente como binário compilado.

  1. Baixe e compile o gerador de configurações do snmp_exporter clonando o repositório oficial e instalando as dependências do compilador Go em sua máquina local:
    git clone https://github.com/prometheus/snmp_exporter.git && cd snmp_exporter/generator && go build
  2. Baixe as MIBs padrão dos fabricantes de seus equipamentos de rede, coloque-as na pasta mib_sources e ajuste o arquivo generator.yml para incluir os módulos desejados, como if_mib para interfaces de rede:
    modules:  if_mib:    walk:      - ifDescr      - ifHCInOctets      - ifHCOutOctets
  3. Gere o arquivo snmp.yml final que será lido pelo exporter em produção executando o binário gerador com permissões de leitura e escrita:
    ./generator generate && cp snmp.yml /etc/prometheus/snmp.yml

Boas práticas para evitar sobrecarga em switches legados

Quando a infraestrutura cresce, coletar métricas via SNMP deixa de ser uma tarefa trivial e passa a exigir rigor operacional. Uma prática indispensável é evitar o uso excessivo de comandos SNMP walk em OIDs profundas e desconhecidas durante o horário de pico comercial. O comando walk obriga o switch a varrer toda uma árvore de dados sequencialmente, consumindo ciclos preciosos do processador do dispositivo legado. Sempre que possível, configure o exporter para buscar apenas os OIDs exatos (snmp get) necessários para o cálculo de tráfego e saúde do sistema.

Além disso, padronize os rótulos gerados pelo Prometheus para que o nome das interfaces físicas reflita a realidade do campo, facilitando o trabalho da equipe de suporte durante incidentes noturnos. Manter dashboards limpos no Grafana com taxas de erro de CRC, utilização de banda em gigabits e descarte de pacotes transforma dados numéricos opacos em tomadas de decisão ágeis. Com uma arquitetura de monitoramento bem dimensionada, o legado deixa de ser um ponto cego e passa a integrar o ecossistema unificado de observabilidade da empresa.

Considerações finais sobre a consolidação de métricas

Consolidar dados de infraestrutura legada utilizando Prometheus e SNMP exige paciência na modelagem e disciplina na escolha dos intervalos de coleta. Ao converter MIBs complexas em séries temporais estruturadas, eliminamos a dependência de softwares de monitoramento antigos e proprietários que cobram caro por licenças baseadas no número de portas. A combinação do snmp_exporter com o poder de alerta do Alertmanager entrega visibilidade total sobre switches e roteadores sem sacrificar a estabilidade do hardware.

Em última análise, investir tempo na configuração correta do mapeamento de OIDs paga dividendos na velocidade de resposta a incidentes e no planejamento de capacidade da rede. Equipamentos antigos continuarán operando por muitos anos em ambientes corporativos e industriais, mas agora eles conversam fluentemente com as ferramentas mais modernas do mercado de tecnologia, garantindo previsibilidade e controle absoluto sobre o ambiente de TI.