Monitoreo de una cabecera IPTV en producción: detectar la falla antes que el cliente

El fallo que no dispara ninguna alarma obvia

En los posts anteriores sobre esta cabecera cubrimos la captación (TVHeadend con tarjetas TBS multi-tuner), la arquitectura de failover entre dos nodos, el descifrado legítimo vía CI/CAM, la sincronización del EPG y el diseño de la escalera de transcodificación ABR. Cada una de esas piezas puede estar "funcionando" en el sentido más literal —proceso vivo, sin excepciones en el log, CPU dentro de rango— y el canal seguir estando roto para el usuario que lo está viendo en ese momento.

Eso hace distinto al monitoreo de streaming del de una API o una base de datos. Un endpoint que responde 500 es una falla binaria y ruidosa: se ve en el primer request de prueba. Un canal con imagen congelada, audio desincronizado, o macro-bloqueo constante sigue devolviendo HTTP 200 en cada segmento HLS, sigue reportando bitrate "normal" si el frame congelado se repite a la tasa esperada, y sigue apareciendo verde en cualquier dashboard que solo mida "¿hay proceso corriendo y hay bytes saliendo?". La falla es de contenido, no de transporte, y el transporte es lo único que la mayoría de los monitoreos genéricos saben medir.

Las capas se vigilan por separado, no como un solo semáforo

La tentación de equipo chico es construir un dashboard con un semáforo por canal —verde, amarillo, rojo— y llamarlo terminado. El problema es que ese semáforo esconde en qué capa está el fallo, y sin esa información cada incidente empieza con diez minutos de "a ver, ¿es la señal, el transcoder, o el portal?" antes de poder empezar a arreglar algo. Lo que funciona mejor es tratar la cabecera como lo que es —una cadena de capas independientes, cada una con su propio modo de fallo— y monitorear cada una con las métricas que le corresponden:

• Captación — la señal llega desde satélite o TDT hasta las tarjetas TBS.
• Origen / relay — TVHeadend o Flussonic entregan ese stream hacia adelante, con o sin transcodificación.
• Transcodificación — cuando hay perfiles ABR, cada uno es un proceso con su propio riesgo de fallo.
• Metadata — el EPG, que falla en silencio de forma independiente de la señal.
• Entrega al dispositivo — el portal Stalker y el STB, la única capa que el servidor central no puede ver directamente.

Una caída real casi siempre se origina en una sola capa y se propaga hacia las de abajo. Saber cuál cayó primero es la diferencia entre un fix de cinco minutos y una hora de diagnóstico a ciegas.

Captación: más allá de "hay señal o no hay señal"

Un tuner de TVHeadend no falla solo apagándose. La forma más común de degradación es progresiva: la relación señal-ruido (SNR) empieza a caer por un desajuste de antena, viento, o interferencia, y el sistema de corrección de errores del demodulador todavía logra recuperar el stream —hasta que deja de poder. En ese tramo intermedio el canal sigue "arriba" pero empieza a meter macro-bloques y congelamientos que el decodificador del STB disimula mal.

Lo que vale la pena vigilar en esta capa, por tuner:

• SNR y BER (bit error rate) como serie de tiempo, no como valor puntual — una caída sostenida de SNR durante quince minutos antes de que el tuner pierda el lock es la ventana donde se puede actuar antes de que el cliente note algo.
• Pérdida de lock del tuner (el demodulador deja de sincronizar con la señal) — esto sí es un evento binario y debe alertar de inmediato, no como tendencia.
• Re-tuning frecuente — un tuner que se resincroniza varias veces por hora casi siempre apunta a un problema físico (cable, LNB, alineación) más que a software, y ese patrón se pierde si solo se registra el estado actual y no el historial de eventos.

La captación con failover geográfico (el caso Caribe/Francia del post de arquitectura multi-nodo) añade una métrica más: cuánto tiempo lleva un canal sirviéndose desde la fuente secundaria. Un failover que nunca vuelve a la fuente principal después de que esta se recupera es un fallo silencioso — el canal se ve bien, pero la redundancia real ya no existe hasta que alguien lo note.

El origen que sí reporta datos y el que miente con ellos

Tanto Flussonic como TVHeadend exponen APIs HTTP con estadísticas por stream: bitrate actual, clientes conectados, tiempo desde el último keyframe, estado del proceso. Hacerles polling cada pocos segundos es la base de cualquier monitoreo de esta capa, pero el bitrate por sí solo es una métrica engañosa: un canal con imagen completamente congelada puede seguir reportando un bitrate razonable si el codificador sigue produciendo frames diferenciales vacíos a la tasa esperada — no hay movimiento en la imagen, pero el stream técnicamente "vive".

Dos señales adicionales cierran ese punto ciego:

• Bitrate como anomalía contra una línea base por canal, no contra un umbral fijo. Un canal de noticias en horario nocturno y uno de deportes en vivo tienen perfiles de bitrate completamente distintos; comparar ambos contra el mismo umbral produce falsos positivos en uno y falsos negativos en el otro. Lo que funciona es una línea base móvil por canal y por franja horaria, alertando quiebres relativos —una caída del 40% respecto al promedio de la última hora— en vez de un número absoluto compartido entre canales.
• Muestreo periódico de frame y comparación contra el anterior. Tomar un frame del stream cada cierto intervalo y compararlo (por diferencia de histograma o de píxeles) contra el frame anterior detecta imagen congelada incluso cuando el bitrate y el conteo de bytes parecen normales. Es la única forma confiable de distinguir "no hay movimiento en la escena" de "el decodificador se atascó".

Transcodificación: la capa con más formas de fallar en silencio

Ya cubrimos en el post sobre ABR por qué cada perfil transcodificado es un proceso de CPU o GPU corriendo en tiempo real. Desde el ángulo de monitoreo, eso significa que cada perfil puede fallar de forma independiente al perfil original: el passthrough puede estar perfecto mientras el perfil de 480p se congeló porque su proceso de transcode murió o quedó atascado. Sin monitoreo por perfil, ese fallo solo se nota cuando un STB que consume justamente ese perfil empieza a fallar, y el reporte llega como "el canal no funciona" sin ninguna pista de que el resto de los perfiles están sanos.

Dos métricas específicas de esta capa cierran el cuadro: tiempo de generación de cada segmento HLS respecto a su duración real (un segmento de 4 segundos que tarda más de 4 en producirse indica que el transcoder no da abasto), y carga de CPU/GPU por proceso individual, no solo agregada por servidor — un promedio saludable puede esconder un solo proceso saturado mientras el resto están ociosos.

El EPG falla distinto — y ya escribimos sobre eso

Dedicamos un post completo a por qué el EPG (la guía de programación) es una capa de fallo separada de la señal, con su propio ciclo de vida: grabbers que dejan de actualizar, mapeos de channel ID que se rompen cuando una fuente cambia su numeración, normalización de zona horaria que se desalinea con reglas de horario de verano. Vale la pena repetir aquí solo el punto central: un EPG desactualizado no aparece en ninguna métrica de señal o bitrate, así que un "ahora/después" roto en los STB puede llevar días sin que nadie lo note, porque el video sigue funcionando perfectamente. La métrica mínima aquí es simple y se ignora seguido: edad del último EPG importado por fuente, con alerta si supera el intervalo esperado de actualización.

Portal y STB: la capa que el servidor no ve directamente

Todo lo anterior se mide desde el servidor. La capa de entrega —el portal Stalker sirviendo la lista de canales y el STB reproduciéndola— es distinta porque el servidor central no tiene visibilidad directa de lo que pasa en el dispositivo del cliente; en el mejor de los casos ve logs de conexión y solicitudes de playlist, no el frame que efectivamente se muestra en pantalla.

Dos cosas sí son observables desde el servidor en esta capa: el conteo de sesiones activas por canal a lo largo del tiempo —una caída abrupta y sostenida sin cambio deliberado es una señal indirecta de que algo dejó de ser reproducible del lado del dispositivo, aunque el servidor lo reporte sano— y la tasa de errores de autenticación o de solicitud de playlist del portal, que suele apuntar a un problema del portal mismo (base de datos, licencias, capacidad) más que de un canal, y conviene distinguirlo claramente para no perder tiempo revisando señal cuando el problema está en otro lado. No sustituye una verificación real desde un dispositivo, pero detecta patrones sin depender enteramente de que un cliente llame primero.

Diseñar alertas sin fatiga de alertas

Un equipo chico no puede darse el lujo de una alerta que llega cada vez que una métrica cruza un umbral por un segundo. Eso entrena al operador a ignorar el canal de alertas, que es el peor resultado posible — el sistema puede estar generando la señal correcta y aun así no servir de nada porque nadie le presta atención. Tres decisiones de diseño que reducen ese ruido sin perder sensibilidad real:

1. Sostenimiento antes de alertar, no umbral instantáneo. Una caída de bitrate que dura dos segundos y se recupera sola es ruido normal de red; la misma caída sostenida durante dos minutos es un incidente. Exigir que la condición se mantenga por una ventana mínima antes de disparar la alerta elimina la mayoría de los falsos positivos sin retrasar de forma relevante la detección de un fallo real.
2. Agregación por incidente, no por métrica. Cuando un tuner pierde el lock, eso puede disparar simultáneamente una alerta de SNR, una de pérdida de señal y una de caída de bitrate en el canal que dependía de ese tuner. Enviar las tres por separado entrena al operador a desconfiar del sistema de alertas; agruparlas en un solo aviso ("tuner 4 perdió lock, afecta canal X") es lo que realmente ayuda a actuar rápido.
3. Severidad distinta según la capa. Una pérdida de lock de tuner con failover automático exitoso no necesita despertar a nadie a las 3 a.m. — sí necesita quedar registrada para revisión al día siguiente. Reservar la notificación inmediata para lo que de verdad interrumpe el servicio evita que las alertas de baja severidad ahoguen a las que sí importan.

Una arquitectura de monitoreo que no necesita un equipo de SRE

Nada de lo descrito arriba requiere una plataforma de observabilidad de nivel empresarial. Para un equipo chico operando varios nodos, la arquitectura mínima que cubre las cinco capas es, en esencia: un proceso liviano que hace polling periódico a las APIs de TVHeadend y Flussonic por cada canal y tuner, guarda esas lecturas como serie de tiempo, calcula líneas base móviles por canal, y evalúa las condiciones de alerta descritas arriba antes de notificar. El muestreo de frames para detección de congelamiento corre aparte y con frecuencia menor —cada treinta o sesenta segundos por canal ya acorta drásticamente la ventana de un fallo silencioso sin generar carga de procesamiento significativa.

La pieza que más rendimiento da por esfuerzo invertido no es la más sofisticada: un canal de notificación simple y confiable —un bot en un chat que el equipo revisa constantemente— supera en la práctica a un dashboard elaborado que nadie mira si no hay una alarma activa. El dashboard sirve para el diagnóstico una vez que ya se sabe que algo falló; la notificación es lo que reduce el tiempo entre la falla y el primer humano enterado.

Qué no monitorear

El error simétrico al de no monitorear lo suficiente es monitorear todo lo monitoreable "porque se puede". Cada métrica adicional es una fuente potencial de falsos positivos y una superficie más que mantener. Tres cosas que casi nunca justifican una alerta dedicada en esta capa: métricas de sistema operativo genéricas (disco, memoria) en servidores con un rol conocido y estable, útiles para diagnóstico posterior pero rara vez la primera señal de un incidente real; alertas de baja prioridad que nadie atendería a las 3 a.m. —mejor en un resumen diario que en el canal de notificación inmediata—; y duplicar la misma condición en dos capas distintas, como una alerta redundante de bitrate cuando la pérdida de lock del tuner que la causó ya disparó su propio aviso.

Errores que más tiempo cuestan en producción

1. Confiar solo en "proceso corriendo" como señal de salud

Es la causa más común de que un canal congelado tarde en detectarse — el proceso sigue activo, el monitoreo básico lo marca en verde, y el primer indicio real llega por un cliente.

2. Umbral de bitrate único para todos los canales

Calibrado para el canal más exigente genera falsos positivos en los de bajo bitrate; calibrado para el más liviano no detecta nada en los demás. La línea base tiene que ser por canal.

3. No distinguir failover exitoso de canal sano sin failover

Un canal que lleva días operando desde la fuente secundaria porque nadie revirtió el failover ya perdió su redundancia real, y eso no aparece en ningún semáforo de "¿está el canal arriba?".

4. Igualar la urgencia de un EPG desactualizado con la de una caída de señal

Ambas son fallos reales, pero mezclarlas en el mismo canal de notificación con la misma severidad entrena al operador a tratar todo con la misma indiferencia.

Checklist antes de dar por lista la capa de monitoreo

• Cada capa (captación, origen, transcodificación, EPG, entrega) tiene sus propias métricas, no un solo semáforo compartido.
• Hay al menos una señal que mira el frame en sí (congelamiento, frame negro), no solo bitrate y estado del proceso.
• Los umbrales de bitrate son relativos a una línea base por canal, no un número fijo compartido.
• Las condiciones de alerta exigen sostenimiento en el tiempo, no un cruce instantáneo de umbral.
• Las alertas relacionadas de un mismo incidente llegan agrupadas, no por separado.
• Existe un canal de notificación que el equipo realmente revisa, no solo un dashboard pasivo.
• Un failover que sigue activo después de que la fuente principal se recuperó genera su propia alerta de revisión.

Cierre

El monitoreo de una cabecera IPTV no es distinto en espíritu del de cualquier sistema en producción: la meta es enterarse antes que el usuario, con la menor cantidad de ruido posible. Lo que sí es distinto es dónde está el punto ciego — en la mayoría de los sistemas, si el proceso responde, el servicio funciona; aquí, un proceso perfectamente vivo puede estar entregando quince minutos de nada. Diseñar el monitoreo alrededor de esa diferencia, capa por capa, es lo que separa un incidente que se resuelve en cinco minutos de uno que empieza cuando el cliente llama.

Si estás operando o por montar una plataforma de streaming y la parte de observabilidad quedó para "después", hablemos.