Una notificación por falla, no una por ONU: alertas con causa raíz en redes FTTH

Son las 3 de la mañana y el teléfono de guardia vibra 38 veces seguidas. Cada vibración es una ONU sin señal. Todas cuelgan del mismo puerto PON. El técnico no necesita 38 avisos: necesita uno que diga «se cayó el puerto 1/2/3 de la OLT Norte, 38 ONUs afectadas».

El problema de alertar por síntoma

Un monitoreo que alerta por cada equipo que deja de responder convierte una falla en una avalancha. Y la avalancha tiene costos concretos:

• El técnico tarda en encontrar la causa entre tantos avisos.
• Los avisos importantes quedan enterrados debajo de los repetidos.
• Con el tiempo, el equipo empieza a silenciar las notificaciones. Y ahí se pierde la que importaba.

La cadena de dependencias

En una red GPON, cada ONU depende de una cadena de equipos. Si un eslabón se cae, todo lo que cuelga de él se cae también:

1. El túnel VPN hacia el MikroTik del ISP, si la OLT se alcanza por ahí.
2. La OLT.
3. El puerto PON o la caja NAP.
4. La ONU del cliente.

Alertar con causa raíz es recorrer esa cadena de arriba hacia abajo y notificar solo el eslabón que falló, con la cuenta de todo lo afectado debajo. Si el túnel está caído, no tiene sentido avisar que la OLT no responde: se sabe por qué.

Qué tiene que decir la notificación

Una buena alerta de causa raíz responde en una línea lo que el técnico va a preguntar:

• Qué falló: el puerto, la caja NAP o la OLT concreta.
• Cuánto afecta: la cantidad de ONUs detrás.
• Por qué, si se sabe: pérdida de señal (LOS) o falta de energía (dying gasp).

Esa última distinción ahorra salidas de camioneta. Si la mayoría de las ONUs de una caja NAP avisó falta de energía antes de caerse, lo más probable es un corte de luz en la zona, no una fibra cortada. Esa diferencia decide si sale una cuadrilla o se espera a que vuelva la electricidad.

Rápido, pero sin falsas alarmas

La velocidad importa: una caída que se detecta en el ciclo de sondeo de 10 minutos llega tarde. Si la OLT manda sus alarmas por syslog, la caída de una ONU se conoce al instante. Pero una ONU que solo se reinicia también avisa que cayó, y no conviene despertar a nadie por eso. Un buen criterio es esperar un minuto: si el aviso sigue abierto, se alerta; si la ONU volvió, no.

Escalar sin repetir

Una alerta que empieza como advertencia puede volverse crítica si la falla crece. Eso merece una nueva notificación, no una cada cinco minutos. Y cuando el equipo vuelve, la alerta se cierra sola: nadie tiene que acordarse de marcarla como resuelta.

Y cuando es mantenimiento

Si el corte es programado, las alertas tienen que quedar registradas pero no notificarse, y ese tiempo no debería contar contra el SLA. Una ventana de mantenimiento cargada con anticipación resuelve las dos cosas.

Cómo lo hace eCloud OLT Controller

El panel recorre la cadena túnel VPN → OLT → puerto o NAP → ONU y notifica solo el eslabón que falla, por Telegram, email o webhook firmado. Tiene más de 20 tipos de alerta, umbrales editables en vivo y ventanas de mantenimiento. Lo que todavía no hace: no manda SMS ni WhatsApp, y la causa de cada caída aparece solo si la OLT la informa.

Más detalle en la página de la plataforma.