Cómo consolidar métricas de red usando Prometheus y SNMP

Por qué SNMP sigue importando en la infraestructura moderna

Muchos administradores de sistemas piensan que los protocolos antiguos como SNMP (Simple Network Management Protocol, un protocolo estándar para administrar y monitorear dispositivos de red en redes IP) están completamente obsoletos. En la práctica, los switches de borde, routers industriales y servidores heredados que operan en su infraestructura siguen hablando exactamente este mismo idioma heredado de décadas pasadas. Para cualquiera que busque una visión unificada de la red, ignorar estos dispositivos simplemente no es una opción. El gran desafío surge cuando intentamos adaptar datos tabulares y estáticos a bases de datos de series temporales modernas que prefieren flujos continuos de números ordenados cronológicamente.

Al conectar herramientas de observabilidad modernas a activos heredados, nos topamos con una barrera de traducción. Prometheus, por ejemplo, es un recolector formidable que extrae datos de forma activa, pero no comprende nativamente la estructura jerárquica y compleja de los archivos MIB (Management Information Base, que actúan como diccionarios explicando el significado exacto de cada número y variable dentro de un dispositivo de red). Aquí es precisamente donde necesitamos traducir el mundo heredado de SNMP al ecosistema estructurado de métricas que Prometheus consume a diario, permitiendo análisis avanzados de tráfico, paquetes descartados y uso de CPU en switches antiguos.

Cómo funciona la traducción de MIBs para datos de series temporales

Para cerrar la brecha entre el protocolo antiguo y el recolector moderno, utilizamos un traductor intermedio conocido como exporter. Para el monitoreo de red, el componente estándar de la comunidad es snmp_exporter, un software que recibe una solicitud HTTP, traduce esa llamada en comandos SNMP dirigidos al switch o router, toma las respuestas numéricas en bruto y las formatea en el estándar que Prometheus comprende. En la práctica, esto significa que cada OID (Object Identifier, que actúa como la dirección numérica exacta de una métrica dentro de un dispositivo) se convierte en una clave legible con etiquetas descriptivas.

Generar estas series temporales exige un mapeo cuidadoso de las MIBs propietarias de los fabricantes. Si monitorea un entorno mixto con equipos de diferentes marcas, cada uno tendrá sus propias tablas numéricas para medir la temperatura, el consumo de energía o el tráfico en los puertos Ethernet. Para mantener la cordura operativa, utilizamos archivos de configuración que convierten OIDs oscuros como .1.3.6.1.4.1.9.9.109.1.1.1.1.5 en una métrica limpia llamada cpmCPUTotal5min. Si necesita investigar problemas profundos de conectividad o pérdida de paquetes, vale la pena revisar nuestra guía práctica sobre cómo auditar flujos de red en Kubernetes con eBPF, complementando la visibilidad entre el mundo físico y el virtual.

Arquitectura y planificación para el recolector SNMP

Implementar monitoreo SNMP a gran escala sin la debida planificación puede colapsar el plano de control de sus routers antiguos. Los dispositivos de red heredados suelen contar con procesadores modestos y memoria limitada; si dispara cientos de consultas simultáneas solicitando tablas de enrutamiento completas o contadores de interfaces, el equipo puede congelarse fácilmente por agotamiento de recursos. Por lo tanto, la arquitectura exige el uso de cachés inteligentes, límites estrictos de concurrencia e intervalos de raspado bien dimensionados, típicamente variando entre sesenta segundos y cinco minutos para métricas menos críticas.

Otro punto crítico de diseño en la recolección es la separación de módulos dentro del archivo de configuración del exporter. En lugar de intentar leer todas las MIBs posibles de una vez, dividimos los objetivos en perfiles específicos para switches de acceso, routers de borde y servidores físicos desactualizados. En la práctica, esto optimiza el tráfico en la red de gestión y asegura que Prometheus reciba solo los datos estrictamente necesarios para el diagnóstico operativo. Si su entorno también sufre de caídas de energía o fluctuaciones eléctricas que reinician inesperadamente estos equipos, recomiendo cruzar estas métricas de red con las directrices de cómo diagnosticar caídas de tensión en fuentes con osciloscopio para aislar fallas de hardware.

Guía paso a paso para configurar snmp_exporter

Para ponerse manos a la obra y estructurar su colector, ejecutemos una secuencia directa de comandos en la línea de comandos de su servidor de monitoreo. Asegúrese de tener Docker instalado o ejecute la herramienta directamente como un binario compilado.

1. Descargue y compile el generador de configuración de snmp_exporter clonando el repositorio oficial e instalando las dependencias del compilador Go en su máquina local:

   git clone https://github.com/prometheus/snmp_exporter.git && cd snmp_exporter/generator && go build

2. Descargue las MIBs estándar de los fabricantes para su equipo de red, colóquelas en la carpeta mib_sources y ajuste el archivo generator.yml para incluir los módulos deseados, como if_mib para interfaces de red:

   modules:  if_mib:    walk:      - ifDescr      - ifHCInOctets      - ifHCOutOctets

3. Genere el archivo snmp.yml final que será leído por el exporter en producción ejecutando el binario generador con permisos de lectura y escritura:

   ./generator generate && cp snmp.yml /etc/prometheus/snmp.yml

Buenas prácticas para evitar la sobrecarga en switches heredados

A medida que la infraestructura escala, recolectar métricas vía SNMP deja de ser una tarea trivial y exige rigor operativo. Una práctica indispensable es evitar el uso excesivo de comandos SNMP walk en OIDs profundos y desconocidos durante las horas pico comerciales. El comando walk obliga al switch a recorrer todo un árbol de datos de forma secuencial, consumiendo valiosos ciclos de CPU del dispositivo legado. Siempre que sea posible, configure el exporter para buscar solo los OIDs exactos (snmp get) necesarios para el cálculo de tráfico y salud del sistema.

Además, estandarice las etiquetas generadas por Prometheus para que el nombre de las interfaces físicas refleje la realidad del campo, facilitando el trabajo de respuesta a incidentes para el equipo de soporte nocturno. Mantener tableros limpios en Grafana con tasas de error de CRC, utilización de ancho de banda en gigabits y descarte de paquetes transforma números opacos en toma de decisiones ágil. Con una arquitectura de monitoreo bien dimensionada, el equipo heredado deja de ser un punto ciego y pasa a integrar el ecosistema unificado de observabilidad de la empresa.

Consideraciones finales sobre la consolidación de métricas

Consolidar datos de infraestructura heredada utilizando Prometheus y SNMP requiere paciencia en el modelado y disciplina al elegir los intervalos de recolección. Al convertir MIBs complejas en series temporales estructuradas, eliminamos la dependencia de software de monitoreo antiguo y propietario que cobra licencias costosas por número de puertos. La combinación de snmp_exporter con el poder de alerta de Alertmanager otorga visibilidad total sobre switches y routers sin sacrificar la estabilidad del hardware.

En última instancia, invertir tiempo en la configuración correcta del mapeo de OIDs rinde dividendos en la velocidad de respuesta a incidentes y en la planificación de capacidad de la red. Los equipos antiguos seguirán operando durante muchos años en entornos corporativos e industriales, pero ahora se comunican con fluidez con las herramientas más modernas del mercado tecnológico, garantizando predictibilidad y control absoluto sobre el entorno de TI.