Monitorización de redes con SNMP, LibreNMS y Grafana

Una red no gestionada es una red que falla sin previo aviso. Los equipos de operaciones que solo reaccionan ante incidencias —esperando la llamada del usuario que dice 'no tengo internet'— están perpetuamente apagando fuegos y carecen de la visibilidad necesaria para planificar capacidad, identificar tendencias de degradación o detectar comportamientos anómalos antes de que se conviertan en problemas graves. La monitorización proactiva no es una práctica opcional; es la diferencia entre gestionar la red y ser gestionado por ella.

SNMP (Simple Network Management Protocol) es el protocolo estándar para la monitorización de dispositivos de red. LibreNMS es una de las plataformas de monitorización de red open source más completas y activas de la comunidad, capaz de descubrir, inventariar y monitorizar miles de dispositivos mediante SNMP y otros métodos. Grafana es la herramienta de visualización más utilizada en el mundo DevOps y de infraestructura, que permite construir dashboards ricos y alertas sobre múltiples fuentes de datos.

Este artículo explica cómo funcionan estos tres componentes, cómo integrarlos en una arquitectura coherente y qué métricas clave debes monitorizar en una red empresarial. Es una guía práctica, no una referencia exhaustiva de configuración; el objetivo es que entiendas las decisiones de diseño y puedas construir sobre ellas.

SNMP: fundamentos para administradores

SNMP es un protocolo de capa de aplicación definido por la IETF que permite leer y escribir variables de gestión en dispositivos de red. Opera principalmente sobre UDP (puerto 161 para consultas, puerto 162 para traps). La arquitectura SNMP tiene tres componentes: el agente (software que corre en el dispositivo gestionado y expone las variables de gestión), el NMS o Manager (el sistema que consulta a los agentes o recibe notificaciones) y la MIB (Management Information Base), la base de datos jerárquica que define qué variables están disponibles y cómo se estructuran.

Versiones de SNMP y seguridad

Existen tres versiones de SNMP con diferencias importantes en seguridad. SNMPv1 y SNMPv2c usan community strings (basic strings de texto plano) como único mecanismo de autenticación. Esto significa que cualquiera que capture tráfico de red puede ver la community string y, si tiene la de escritura, puede modificar la configuración del dispositivo. En entornos empresariales, SNMPv1 y v2c deben usarse solo en redes de gestión aisladas y con community strings robustas y no predecibles ('public' y 'private' son absolutamente inaceptables).

SNMPv3 introduce autenticación real (HMAC-MD5 o HMAC-SHA) y cifrado del tráfico (DES, 3DES o AES). Su configuración es más compleja (requiere definir usuarios con credenciales en el dispositivo) pero es el único nivel aceptable si el tráfico SNMP atraviesa segmentos de red no completamente confiables. La transición de v2c a v3 es uno de los elementos de hardening de infraestructura de red que con mayor frecuencia se posterga indefinidamente.

OIDs y MIBs clave para infraestructura de red

Cada variable gestionable tiene un OID (Object Identifier), una cadena de números jerárquicos que la identifica de forma única. Las MIBs estándar más relevantes para infraestructura de red son MIB-II (RFC 1213), que incluye contadores de interfaces (ifInOctets, ifOutOctets, ifOperStatus), tabla de routing IP, tabla ARP y estadísticas ICMP. RFC 2863 define la IF-MIB con contadores extendidos de interfaz (ifHCInOctets para interfaces de alta velocidad donde los contadores de 32 bits hacen overflow en segundos). Los fabricantes complementan con MIBs propietarias que exponen información específica: estado de fuentes de alimentación, temperatura de CPU, uso de memoria, estado de módulos y mucho más.

LibreNMS: instalación y arquitectura

LibreNMS es un fork de Observium con licencia GPLv3 que ha evolucionado de forma independiente y activa. Soporta cientos de fabricantes y tipos de dispositivos (Cisco, Juniper, Aruba, Fortinet, HPE, Ubiquiti, servidores Linux, Windows, VMware ESXi, bases de datos, UPS, y un largo etcétera), tiene un sistema de alertas avanzado, generación de informes de SLA y disponibilidad, y una API REST completa para integración con otras herramientas.

La arquitectura de LibreNMS se basa en un servidor central (o cluster para entornos grandes) que corre el poller de SNMP, almacena datos en MySQL/MariaDB para la configuración y en RRDtool o InfluxDB para las métricas de series temporales, y expone una interfaz web PHP. Para entornos con muchos dispositivos o geográficamente distribuidos, LibreNMS soporta pollers distribuidos (distributed polling) mediante workers coordinados por Redis.

Requisitos y despliegue

LibreNMS se puede instalar en cualquier distribución Linux (Debian/Ubuntu y RHEL/Rocky son las más documentadas). Los requisitos mínimos para un entorno de producción pequeño (hasta 500 dispositivos) son modestos: un servidor con 4 vCPUs, 8 GB RAM y almacenamiento suficiente para los RRDs (que crecen linealmente con el número de métricas y el período de retención). Para entornos de cientos o miles de dispositivos, el componente que más escala debe ser el polling y el almacenamiento de métricas; migrar de RRDtool a InfluxDB para las series temporales es una opción que mejora significativamente el rendimiento de consultas y la integración con Grafana.

Descubrimiento automático de red en LibreNMS

Una de las capacidades más valiosas de LibreNMS es el autodiscovery. Una vez configurada la community string o las credenciales SNMPv3 en un rango de IPs, LibreNMS puede descubrir automáticamente los dispositivos de red usando SNMP, seguir las adyacencias LLDP/CDP para descubrir dispositivos vecinos, y construir mapas topológicos de la red.

El proceso de descubrimiento funciona en dos fases: el scan inicial identifica qué IPs responden a SNMP y les asocia el tipo de dispositivo correcto (usando el sysObjectID para identificar el fabricante y modelo); el polling periódico (cada 5 minutos por defecto) recoge todas las métricas de cada dispositivo. LibreNMS detecta automáticamente las interfaces, los sensores de hardware (temperatura, voltaje, ventiladores en los dispositivos que los exponen), los módulos BGP y OSPF, y configura el polling de las métricas relevantes para cada tipo de dispositivo.

Configuración de alertas en LibreNMS

El sistema de alertas de LibreNMS es uno de sus puntos fuertes. Las reglas de alerta se definen mediante una sintaxis de consulta flexible que puede combinar métricas de dispositivos, interfaces, sensores y estados. Las condiciones se evalúan en cada ciclo de polling y generan alertas cuando se cumplen.

• Disponibilidad de dispositivos: alerta cuando un dispositivo deja de responder a SNMP (down detection con reintentos configurables).
• Estado de interfaces: alerta cuando ifOperStatus cambia a down en interfaces monitorizadas (con capacidad de excluir interfaces administrativamente down).
• Umbral de utilización de ancho de banda: alerta cuando el uso de una interfaz supera un porcentaje del ancho de banda contratado durante un período sostenido.
• Sensores de hardware: temperatura de CPU o módulos, voltaje fuera de rango, ventiladores fallidos.
• BGP session state: alerta cuando una sesión BGP cae (crítico para empresas con conectividad Internet multihomed o SD-WAN con enrutamiento dinámico).
• Espacio en disco y uso de CPU/RAM en servidores monitorizados vía SNMP.

Las alertas pueden enviarse por múltiples canales: correo electrónico, Slack, Teams, PagerDuty, OpsGenie, Telegram, y más mediante transports configurables. Esto permite integrar LibreNMS con el sistema de gestión de incidencias de la organización (ServiceNow, Jira, Zendesk) a través de webhooks.

InfluxDB como backend de métricas para LibreNMS

Por defecto, LibreNMS almacena las series temporales en ficheros RRD (Round Robin Database), un formato eficiente para monitorización pero con limitaciones para consultas ad-hoc y para la integración con herramientas externas como Grafana. La alternativa es configurar LibreNMS para escribir las métricas también en InfluxDB (versión 1.x o 2.x). InfluxDB es una base de datos de series temporales de alto rendimiento, especialmente diseñada para el tipo de cargas de escritura intensiva que genera la monitorización.

Con las métricas en InfluxDB, Grafana puede conectarse directamente y construir dashboards personalizados con toda la potencia del lenguaje de consulta Flux (InfluxDB 2.x) o InfluxQL (InfluxDB 1.x). Esta combinación LibreNMS + InfluxDB + Grafana es la arquitectura de referencia para equipos que quieren ir más allá de los dashboards integrados de LibreNMS y construir visualizaciones personalizadas para la dirección, para equipos específicos o para SLAs de clientes en entornos MSP.

Grafana: dashboards de red profesionales

Grafana es la herramienta de visualización más utilizada en el mundo de la infraestructura y el DevOps. Su modelo de plugins de fuentes de datos permite conectar a prácticamente cualquier base de datos de métricas: InfluxDB, Prometheus, Elasticsearch, Graphite, Zabbix, y muchas más. Sus paneles son altamente configurables y van desde gráficas de series temporales hasta mapas de calor, tablas, gauges y diagramas de estado.

Para monitorización de redes, los dashboards más valiosos en Grafana son: utilización de ancho de banda por interfaz y por dispositivo (gráficas de área con percentiles), disponibilidad de dispositivos (tabla de estado con código de color), latencia y pérdida de paquetes de los enlaces WAN críticos (gráficas de serie temporal con umbrales visuales), temperatura y estado de hardware (gauges y alertas visuales), y resúmenes de disponibilidad por período para reporting de SLA.

NetFlow e IPFIX: visibilidad del tráfico de aplicaciones

SNMP proporciona información de volumen de tráfico por interfaz, pero no dice qué aplicaciones o qué IPs generan ese tráfico. Para esa visibilidad se usan protocolos de exportación de flujos: NetFlow (Cisco), sFlow (Multi-vendor) e IPFIX (el estándar abierto). Los routers y switches exportan registros de flujo a un colector que los agrega y permite análisis de tráfico por protocolo, dirección IP, aplicación y usuario.

LibreNMS tiene soporte integrado para recibir y visualizar flows a través del módulo LibreNMS Flow (basado en ntopng o en el flow collector integrado). Para análisis más avanzados, ntopng, Elastic Stack con el módulo Filebeat de NetFlow, o soluciones comerciales como SolarWinds NTA o Plixer Scrutinizer ofrecen capacidades de análisis de tráfico más completas. La integración de flows en Grafana es posible mediante plugins específicos o exportando datos del colector a InfluxDB.

Monitorización sintética y SLA de conectividad

Además de la monitorización pasiva (recogida de métricas SNMP), es importante implementar monitorización activa o sintética: generar tráfico de prueba desde puntos estratégicos para medir latencia, jitter y pérdida de paquetes de extremo a extremo. Herramientas como Smokeping (integrable con LibreNMS) o el módulo RANCID de LibreNMS para verificación de configuraciones, o simplemente scripts que ejecutan ICMP pings y traceroutes periódicos, permiten detectar degradaciones de conectividad antes de que afecten a los usuarios.

En entornos SD-WAN, los propios controladores exponen métricas de rendimiento de enlace por aplicación que deben integrarse en el stack de monitorización. Cisco SD-WAN, Fortinet SD-WAN y VeloCloud tienen APIs o exportadores SNMP/NetFlow que pueden alimentar LibreNMS o Grafana directamente.

Inventario y CMDB: LibreNMS como fuente de verdad

Una funcionalidad frecuentemente subestimada de LibreNMS es su capacidad como repositorio de inventario de activos de red. Cada dispositivo descubierto acumula información sobre módulos hardware, versiones de firmware, puertos, VLANs, tablas de routing, vecinos LLDP/CDP, certificados SSL de servicios y mucho más. Esta información puede exportarse vía API para alimentar una CMDB (Configuration Management Database) en herramientas como NetBox, ServiceNow o i-doit, manteniendo el inventario actualizado de forma automática.

Buenas prácticas operativas de monitorización

• Segmenta el tráfico SNMP en una VLAN de gestión dedicada, separada del tráfico de datos.
• Migra a SNMPv3 en todos los dispositivos que lo soporten. Si un dispositivo no soporta v3, evalúa su reemplazo.
• Configura umbrales de alerta basados en percentiles históricos, no en valores absolutos arbitrarios. Una interfaz de 1 Gbps al 80% de uso sostenido es una alerta; la misma al 50% durante un minuto puede ser normal.
• No monitorizces todo: prioriza los dispositivos y métricas críticos para el negocio. Un dashboard con 500 paneles es tan inútil como ninguno.
• Revisa y depura las alertas periódicamente para evitar alert fatigue: si el equipo recibe decenas de alertas falsas positivas, empieza a ignorarlas.
• Documenta los runbooks de respuesta a alertas: cada alerta crítica debe tener un procedimiento definido de qué hacer cuando se dispara.
• Mantén LibreNMS y sus dependencias actualizadas: el proyecto tiene releases frecuentes con correcciones de seguridad y nuevos soportes de dispositivos.

Una alerta que nadie atiende no vale nada. La calidad de un sistema de monitorización no se mide por el número de métricas que recoge, sino por la rapidez con que el equipo detecta y resuelve los problemas que afectan al negocio.

Alternativas y complementos a considerar

LibreNMS no es la única opción en el espacio de monitorización de red open source. Zabbix es una plataforma más generalista (cubre también monitorización de servidores y aplicaciones) con un modelo de agentes propio además de SNMP; su curva de aprendizaje es mayor pero su flexibilidad también. Checkmk tiene un enfoque similar y una experiencia de usuario que muchos equipos encuentran más intuitiva. Prometheus con exportadores SNMP (snmp_exporter) es otra opción muy popular en entornos nativos de nube donde ya existe un stack Prometheus/Grafana. Para entornos muy grandes, plataformas comerciales como SolarWinds Network Performance Monitor, Auvik o ManageEngine OpManager ofrecen capacidades adicionales de gestión de cambios y cumplimiento.

Conclusión

Construir un sistema de monitorización de red robusto con SNMP, LibreNMS y Grafana es un proyecto con alta rentabilidad operativa. La inversión inicial en despliegue y configuración se recupera rápidamente en mayor tiempo medio entre fallos detectado a tiempo, menor tiempo medio de resolución de incidencias y mejor capacidad de planificación de capacidad basada en datos reales.

Si partes de cero, el camino más directo es instalar LibreNMS, configurar la community string SNMPv2c en un segmento piloto de dispositivos, activar el autodiscovery y explorar lo que la herramienta encuentra por sí sola. La primera vez que LibreNMS te avise de que un switch en un armario remoto ha perdido un módulo o tiene un ventilador fallido antes de que genere una incidencia, habrá merecido la pena. Desde ahí, el paso a InfluxDB y Grafana para dashboards personalizados es incremental y con documentación abundante disponible en la comunidad.