Cómo monitorear una OLT GPON correctamente en 2026

Monitorear una OLT no es complicado en teoría: te conectas, lees los contadores, los grafías. En la práctica, la mayoría de ISPs terminan ahogados en datos que no procesan o, peor, en alertas que el equipo aprendió a ignorar.

Este artículo no es exhaustivo. Es lo que un operador de NOC necesita saber para empezar a monitorear bien — sin contratar consultores, sin comprar plataformas sobredimensionadas.

Las cuatro métricas que sí importan

Mucha gente persigue 30 métricas y termina mirando ninguna. Estas cuatro cubren más del 90% de los incidentes reales que vas a enfrentar.

1. Señal óptica RX por ONU

Es la métrica más directamente correlacionada con la experiencia del cliente. Si la señal cae por debajo del umbral aceptable (típicamente alrededor de -27 dBm en GPON estándar), el cliente va a tener cortes intermitentes o velocidad degradada antes de desconectar del todo.

Lo importante: detectar la degradación progresiva, no esperar a que la ONU caiga. Una ONU que pasó de -23 a -25 dBm en una semana te está avisando algo: empalme deficiente, mordedura de roedor, doblez en el cable. Si solo monitoreas estado binario (conectada/desconectada), te enteras cuando ya es tarde.

2. Tráfico por puerto PON

Saturar un puerto PON es uno de los errores más comunes al crecer una red. GPON estándar reparte 2.488 Gbps de bajada entre todas las ONUs del puerto. Cuando el promedio de uso en hora pico se acerca al 70% sostenido, ya estás dejando experiencia degradada en la mesa.

Mídelo a nivel de puerto (no a nivel de OLT total) y por intervalo de 5 minutos. Diario es demasiado tarde.

3. Eventos de estado de ONU

Los logs de la OLT te cuentan cosas que el contador no: por qué cayó una ONU (LOSi, LOFi, DyingGasp), cuántas veces se reautenticó en la última hora, si hubo intentos de provisioning fallidos.

Esa data es oro para diagnosticar, pero solo si la consumes estructurada. Cargarla a un log sin procesar es desperdicio.

4. Disponibilidad de la OLT

Suena obvio pero se descuida. La OLT misma puede colgarse, perder conectividad de uplink, o quedar inalcanzable por un cambio de firewall mal hecho. Si no monitoreas la OLT, te enteras cuando suene el primer cliente.

Un ping cada 30 segundos a la IP de gestión + alerta si tres pings seguidos fallan es el mínimo.

Cada cuánto consultar

Acá hay un balance crítico: consultar muy seguido satura la OLT y le quita ciclos al servicio real. Consultar muy poco te deja ciego entre lecturas.

Métrica	Frecuencia recomendada
Disponibilidad OLT (ping)	Cada 30 segundos
Estado de ONUs (online/offline)	Cada 1-2 minutos
Señal óptica RX	Cada 5-10 minutos
Tráfico por puerto PON	Cada 5 minutos
Logs/eventos	Cada 10-15 minutos

Estos números son una base. OLTs con muchas ONUs pueden necesitar intervalos más largos para no saturar el CPU del equipo durante las lecturas.

Reactivo vs. proactivo: la diferencia que cambia tu mesa de ayuda

Una mesa de ayuda reactiva espera que el cliente llame y luego diagnostica. Una mesa proactiva abre el ticket antes de que el cliente se entere del problema.

La diferencia no es tecnología. Es flujo de trabajo:

1. La alerta llega al canal del equipo (idealmente WhatsApp, donde ya viven).
2. La alerta trae el diagnóstico inicial, no solo “ONU X caída”.
3. El técnico decide en segundos: ¿despacho cuadrilla, espero confirmación, escalo?
4. El cliente se entera por mensaje del ISP, no llamando furioso.

Un ISP que cambia de reactivo a proactivo típicamente baja entre 30% y 50% el volumen de tickets entrantes en los primeros tres meses. No es magia: es que mucho del volumen reactivo era duplicado de incidentes que se podían haber comunicado primero.

Lo que hace CentiNetOLT en este frente

Construimos CentiNetOLT para que un operador no tenga que armar este stack desde cero. La plataforma:

• Lee las cuatro métricas anteriores en los intervalos recomendados, sin que tengas que configurar contadores SNMP a mano.
• Detecta degradación progresiva de señal con análisis de tendencia, no solo umbrales fijos.
• Envía alertas estructuradas por WhatsApp con diagnóstico inicial incluido.
• Mantiene histórico navegable para auditoría y análisis post-incidente.

No es la única forma de hacerlo. Si tienes un equipo de ingeniería interno, puedes armar lo mismo con un colector de tu elección, una serie de tiempo y un sistema de alertas. Lo que importa es que las decisiones sobre métricas, frecuencias y flujos sean las correctas. Si no tienes ese equipo, eso es justamente lo que estamos resolviendo.

Para llevarte

• Monitorea cuatro métricas core, no veinte.
• Tendencia importa más que umbral fijo, especialmente en señal óptica.
• 5 minutos es el sweet spot para la mayoría de lecturas pesadas.
• El cambio reactivo → proactivo es de flujo, no de herramienta.
• Si todavía tu equipo se entera de los problemas por las llamadas del cliente, tienes un problema operativo, no un problema técnico.