Monitoreo proactivo con Zabbix para ISPs: lo que tu NOC necesita ver antes de que el suscriptor llame
En la operación diaria de un ISP, hay dos tipos de problemas: los que tu equipo detecta primero, y los que detecta el suscriptor primero. La diferencia entre esos dos escenarios es la diferencia entre un incidente gestionado y una crisis. Entre un cliente que renueva y uno que cancela.
El monitoreo reactivo (esperar el ticket, atender el reclamo, entonces investigar) fue aceptable cuando los suscriptores tenían pocas alternativas. Hoy no lo es. Y la buena noticia es que las herramientas para hacer monitoreo proactivo son accesibles, maduras, y completamente viables para ISPs de cualquier tamaño en Latinoamérica.
Zabbix es la plataforma central de ese stack. Esta guía cubre qué monitorear, cómo estructurarlo, y cómo integrarlo con Grafana para que tu NOC tenga visibilidad real antes de que el teléfono suene.
Por qué el monitoreo reactivo destruye la experiencia del suscriptor
El monitoreo reactivo tiene un problema estructural: el suscriptor siempre es el primer detector. Cuando un OLT pierde una tarjeta, cuando un uplink satura al 98%, cuando una sesión BGP cae a las 3 de la madrugada, la primera señal visible para el ISP es el volumen de llamadas al soporte.
Ese modelo tiene consecuencias en cascada. El tiempo entre la falla y la detección (MTTD) puede ser de 15, 30, 60 minutos. El tiempo de resolución (MTTR) empieza a correr recién cuando el NOC recibe la alerta humana. Mientras tanto, el suscriptor ya formó su opinión sobre la calidad del servicio.
Más allá de la experiencia: en entornos con SLA corporativos, cada minuto de falla no detectada es minuto acumulado contra el uptime comprometido en contrato. La detección tardía no es solo un problema de imagen: puede tener costo económico directo.
El monitoreo proactivo invierte ese ciclo. El sistema detecta la degradación (no la falla total, sino la degradación) y alerta al equipo antes de que el suscriptor lo perciba como problema.
Qué debe monitorear un ISP: la lista que no puede faltar
El error más común al arrancar con Zabbix es monitorear solo lo que es fácil de agregar (ping a la gestión de los equipos) y asumir que eso es suficiente. No lo es. Hay categorías de monitoreo que deben estar activas para tener visibilidad real:
Interfaces de red (estado y utilización)
El estado operacional de cada interfaz crítica (uplinks al transit, enlaces entre POP, interfaces hacia OLTs) debe monitorearse con alertas diferenciadas: una alerta cuando la interfaz baja (ifOperStatus), y otra cuando la utilización supera umbrales (por ejemplo, alerta al 80% de capacidad, crítico al 95%). La saturación de enlace que llega al 100% durante horas degrada la experiencia sin generar una caída visible: es exactamente el tipo de problema que el suscriptor siente y el NOC no ve sin monitoreo de utilización.
Sesiones BGP
Cada sesión eBGP e iBGP debe tener un item en Zabbix con alerta inmediata ante cambio de estado. Una sesión BGP caída puede significar pérdida de tránsito, de peers, o de redundancia de ruteo. El tiempo de detección aceptable para una sesión BGP es de segundos, no minutos. (Sobre los errores de configuración BGP que amplifican estos problemas, ver nuestro artículo sobre BGP para ISPs.)
Adyacencias OSPF e IS-IS
En redes con IGP corriendo en el core o en la distribución, la pérdida de una adyacencia OSPF o IS-IS puede causar convergencia no óptima o huecos de ruteo que no son evidentes hasta que el tráfico empieza a caer. Monitorear el número de adyacencias activas por router y alertar ante cualquier reducción.
CPU y memoria en equipos de red
Un router con CPU al 95% está a punto de empezar a perder paquetes de control, degradar BGP, o simplemente trabarse. Monitorear CPU y memoria en todos los equipos de core y distribución, con umbrales que disparen alertas preventivas antes de llegar al límite.
OLTs y su estado de puertos PON
En redes GPON/EPON, el estado de las tarjetas de línea y los puertos PON debe monitorearse en tiempo real. La pérdida de una tarjeta OLT puede afectar a decenas o cientos de suscriptores simultáneamente. Los contadores de errores (FEC corrections, BIP errors) son indicadores tempranos de problemas ópticos antes de que el ONT pierda señal completamente.
RADIUS y autenticación
Si el servidor RADIUS no responde, los suscriptores no pueden autenticarse cuando reinician su conexión. En redes con muchos cortes y reconexiones simultáneas (un corte de luz en un barrio, por ejemplo), la saturación o caída del RADIUS puede convertir un incidente menor en un problema masivo. Monitorear disponibilidad del RADIUS, tiempo de respuesta de autenticaciones, y tasa de errores de autenticación.
Latencia de bucle (round-trip time interno)
La latencia interna entre POP propios es un indicador de salud de la red que raramente falla de golpe pero que se degrada gradualmente. Monitorear RTT entre puntos clave de la red con umbrales históricos permite detectar aumentos de latencia que aún no se expresan como falla pero que anticipan un problema de capacidad o de ruta.
Uplinks de tránsito y utilización total
La saturación de los uplinks de tránsito impacta directamente en la experiencia del suscriptor con destinos de internet. Monitorear utilización total y por dirección (in/out), con proyecciones de crecimiento si es posible.
Zabbix como plataforma: por dónde empezar
Zabbix es una plataforma de monitoreo open source con más de 20 años de desarrollo activo. Para ISPs es especialmente adecuada por tres razones: soporte nativo de SNMP, capacidad de escala a decenas de miles de items, y una colección creciente de templates oficiales para los vendors más comunes.
Templates oficiales para vendors ISP
Zabbix mantiene una biblioteca de templates que cubre los principales vendors:
- Huawei: templates para VRP (router/switch), Huawei CE series (switches de datacenter), SmartAX (OLTs MA5600/MA5800). El template oficial de Huawei VRP cubre interfaces, BGP, OSPF, CPU y memoria via SNMP.
- MikroTik: template oficial que cubre RouterOS via SNMP y via API. Incluye interfaces, BGP sessions (si RouterOS ≥ 7.x), CPU, memoria, y tablas de ruteo.
- Cisco IOS/IOS-XE/IOS-XR: templates que cubren interfaces, BGP, OSPF, ISIS, CPU y memoria. Cisco IOS-XR tiene soporte adicional via gRPC/gNMI para telemetría streaming.
Estos templates son un punto de partida, no una configuración final. En producción siempre hay que ajustar umbrales, deshabilitar items irrelevantes, y agregar items custom para métricas específicas de cada red.
SNMP polling: la base del monitoreo de red
La mayoría de las métricas de red se obtienen via SNMP v2c o v3. La configuración básica en Zabbix para un equipo Huawei:
# En el equipo Huawei (VRP)
snmp-agent
snmp-agent community read COMUNIDAD-LECTURA
snmp-agent sys-info version v2c v3
snmp-agent target-host trap address udp-domain 10.0.0.100 params securityname COMUNIDAD-LECTURA
# En Zabbix (host configuration)
SNMP community: {$SNMP_COMMUNITY}
SNMP version: SNMPv2
Port: 161
Para redes con requerimientos de seguridad más estrictos, SNMPv3 con autenticación SHA y privacidad AES es la opción correcta:
snmp-agent usm-user v3 ZABBIX-USER
authentication-mode sha PASSPHRASE-AUTH
privacy-mode aes128 PASSPHRASE-PRIV
ICMP para disponibilidad básica
Además del SNMP polling, Zabbix debe hacer ICMP checks periódicos a la IP de gestión de cada equipo. Esto detecta la pérdida total de acceso cuando SNMP ya no responde. El intervalo recomendado para equipos críticos es de 30 a 60 segundos.
Zabbix Agent para servidores de infraestructura
Para los servidores que forman parte de la infraestructura ISP (RADIUS, DNS autoritativo, portales cautivos, servidores de gestión), el agente Zabbix permite monitoreo más granular: disco, procesos específicos, logs, servicios. Instalar el agente en estos servidores y usar los templates de Linux correspondientes.
Traps SNMP vs polling activo: cuándo usar cada uno
Esta es una de las preguntas que más frecuentemente genera confusión en equipos de NOC que están estructurando su monitoreo.
SNMP Traps son mensajes que el equipo de red envía activamente al servidor de monitoreo cuando ocurre un evento específico: una interfaz baja, un threshold de CPU se supera, una adyacencia OSPF cae. Son inmediatos: el tiempo entre el evento y la notificación puede ser de milisegundos. Su desventaja es que dependen de que el equipo esté vivo y configurado para enviar el trap. Si el equipo falla de forma catastrófica, puede no llegar a enviar el trap.
Polling activo es el ciclo inverso: Zabbix consulta periódicamente al equipo (cada 1, 5, o 10 minutos según el item) y registra el valor. Detecta tanto fallas como degradaciones graduales. Su desventaja es la latencia de detección: si un enlace cae y el próximo poll es en 3 minutos, la detección se demora hasta ese momento.
La respuesta correcta para un ISP es usar ambos en complemento:
- Traps SNMP para eventos discretos de alta criticidad: cambio de estado de interfaz, cambio de estado BGP, cambio de rol en protocolos de alta disponibilidad (VRRP, MC-LAG). Estos eventos merecen notificación inmediata.
- Polling activo para métricas continuas: utilización de CPU, utilización de interfaz, latencia, memoria. El polling construye el histórico de tendencias que permite detectar degradaciones graduales.
En Zabbix, la recepción de traps se configura habilitando el proceso zabbix_trap_receiver y configurando snmptrapd como receptor:
# /etc/snmp/snmptrapd.conf
authCommunity log,execute,net COMUNIDAD-TRAP
traphandle default /usr/lib/zabbix/externalscripts/zabbix_trap_handler.pl
Integración con Grafana para dashboards operativos en el NOC
Zabbix tiene sus propias visualizaciones, pero para dashboards de NOC pensados para ser vistos en pantallas grandes durante turnos de 8 horas, Grafana ofrece una experiencia significativamente mejor.
La integración se hace via el plugin oficial de Zabbix para Grafana (desarrollado por Alexander Alexandrov, actualmente mantenido como plugin comunitario):
grafana-cli plugins install alexanderzobnin-zabbix-app
Una vez configurado el datasource apuntando a la API de Zabbix, es posible construir dashboards que combinen:
- Mapa de red en tiempo real: estado de cada enlace crítico con color por estado (verde/amarillo/rojo según utilización o disponibilidad).
- Tabla de alertas activas: ordenada por severidad y tiempo de inicio, con información de qué equipo y qué métrica disparó la alerta.
- Gráficas de utilización de uplinks: en tiempo real y con ventana histórica de 24 horas para identificar patrones.
- Panel de sesiones BGP: estado de cada sesión, tiempo activo, prefijos recibidos/anunciados.
- Disponibilidad por zona geográfica: si los equipos están etiquetados por zona en Zabbix, un mapa por región muestra rápidamente dónde está el problema.
El objetivo del dashboard de NOC no es mostrar toda la información disponible: es permitir que el operador de turno identifique en segundos si hay algo que requiere acción, y qué es ese algo.
Alertas escalonadas: NOC, ingeniería y guardia nocturna
Tener visibilidad es condición necesaria pero no suficiente. La visibilidad tiene que traducirse en acción, y para eso el esquema de alertas debe estar pensado para el contexto operativo real.
Un modelo de escalamiento efectivo para ISPs tiene tres niveles:
Nivel 1 — NOC (alerta en dashboard y notificación inmediata)
Todos los eventos críticos llegan al dashboard del NOC y generan una notificación por canal de mensajería (Telegram, Slack, correo). El operador de NOC tiene el primer nivel de respuesta: verificar, intentar resolver con procedimientos documentados, o escalar.
Nivel 2 — Ingeniería (si el NOC no resuelve en N minutos)
Si la alerta no es reconocida o no se resuelve en el tiempo definido (por ejemplo, 15 minutos para un uplink caído), Zabbix escala automáticamente la notificación al equipo de ingeniería de redes. Zabbix soporta escalamiento nativo via “escalation steps” en la configuración de acciones.
# Ejemplo de acción con escalamiento en Zabbix
Action: UPLINK-DOWN
Step 1 (0 min): Notificar a NOC-Team via Telegram
Step 2 (15 min, si no resuelto): Notificar a Ingeniería-Red via Telegram + llamada
Step 3 (30 min, si no resuelto): Notificar a Gerencia-Técnica
Nivel 3 — Guardia nocturna (horario fuera de oficina)
Para incidentes de alta severidad fuera del horario del NOC, el escalamiento debe incluir contacto telefónico o por PagerDuty. Integrar Zabbix con servicios de on-call management (PagerDuty, OpsGenie, o un esquema custom via webhook) garantiza que un incidente a las 3 de la madrugada no espera hasta las 9 para ser atendido.
El criterio de severidad debe estar acordado con el equipo antes de configurarlo: no todos los problemas justifican despertar a alguien. Una interfaz de gestión caída a las 2am probablemente puede esperar. Un uplink de tránsito principal caído, no.
Métricas clave: los números que importan
Un sistema de monitoreo bien configurado produce métricas que permiten tanto la detección en tiempo real como el análisis de tendencias. Las métricas que todo ISP debe poder responder con datos:
Disponibilidad de servicio
Porcentaje de tiempo que los enlaces y servicios críticos estuvieron operativos en el período. Zabbix calcula esto automáticamente para cada item cuando se configura el SLA report. El objetivo debe estar definido en función de los compromisos contractuales con clientes.
Latencia promedio y percentil 95
La latencia promedio puede ocultar picos. El percentil 95 de latencia (el valor que el 95% de las mediciones no supera) es un indicador más honesto de la experiencia del suscriptor. Monitorear ambos.
Pérdida de paquetes
Zabbix mide pérdida de paquetes en los checks ICMP. Una pérdida del 1-2% en un enlace es un indicador temprano de congestión o de un problema físico incipiente. Definir umbrales: alerta al 1%, crítico al 5%.
Saturación de enlace (peak y promedio)
La utilización pico (máximo en 5 minutos) y el promedio en períodos de mayor tráfico (busy hour) son los dos números que determinan si hace falta ampliar capacidad. Un enlace que tiene promedio del 40% pero picos al 95% durante 2 horas al día tiene un problema de capacidad aunque el promedio “se vea bien”.
MTTD y MTTR operativos
Con los datos de Zabbix es posible calcular el tiempo promedio de detección (tiempo entre inicio del evento y primer reconocimiento en el sistema) y el tiempo promedio de resolución. Estos dos KPIs deben estar en el reporte operativo mensual del NOC.
Notas sobre vendors: Huawei, MikroTik y Cisco
Cada vendor tiene particularidades que afectan cómo se implementa el monitoreo:
Huawei VRP: el soporte SNMP es completo y estable. Las MIBs de Huawei para BGP (hwBgp), OSPF y IS-IS están bien documentadas. El template oficial de Zabbix para Huawei VRP cubre la mayoría de los casos de uso. Para OLTs Huawei SmartAX, el monitoreo via SNMP de puertos PON (estado, potencia óptica rx, errores FEC) requiere las MIBs específicas de la serie, disponibles en el portal de soporte de Huawei.
MikroTik RouterOS: para versiones anteriores a 7.x, el monitoreo BGP via SNMP tiene limitaciones (la MIB estándar BGP4-MIB no siempre está completamente implementada). La alternativa es usar la API de RouterOS desde Zabbix via scripts externos, o actualizar a RouterOS 7.x donde el soporte SNMP para BGP es más completo. Para el monitoreo de interfaces y recursos del sistema, el template oficial funciona bien desde RouterOS 6.x.
Cisco IOS-XE / IOS-XR: el soporte SNMP en Cisco es maduro. IOS-XR agrega la posibilidad de usar gRPC/gNMI para telemetría streaming, que es más eficiente que el polling para redes con miles de métricas. Integrar telemetría gNMI con Zabbix requiere un collector intermediario (como Telegraf + InfluxDB, o un script custom), pero es la dirección correcta para redes Cisco de escala media/grande.
Nuestra experiencia en campo
En Ayuda.LA trabajamos con equipos NOC de ISPs de distintos tamaños en Latinoamérica. El patrón que vemos con más frecuencia no es falta de herramientas: es Zabbix (u otro sistema) instalado pero configurado solo para disponibilidad básica (ping), sin cobertura de los items que realmente anticipan problemas.
El salto de “monitoreo de disponibilidad” a “monitoreo proactivo operativo” no requiere reemplazar nada. Requiere agregar items, definir umbrales con criterio operativo, construir dashboards orientados al operador de NOC, y acordar un proceso de escalamiento que funcione a las 3 de la madrugada.
En la mayoría de los casos, ese trabajo puede hacerse en días o semanas (no meses), y el impacto en MTTD es inmediato.
Conocé más sobre nuestros servicios de NOC y monitoreo para ISPs.
¿Querés revisar o estructurar el monitoreo de tu NOC?
Podemos evaluar tu configuración actual de Zabbix, identificar los gaps de cobertura más críticos, y proponer una estructura de alertas y dashboards adaptada a tu operación. Sin necesidad de reemplazar lo que ya tenés funcionando.
¿Tenés preguntas sobre Zabbix, SNMP o monitoreo de redes ISP? Escribinos a [email protected] — respondemos todos los mensajes.