Monitorización y métricas

Métricas por canal

Cada canal expone lo siguiente en la interfaz y a través de la API HTTP.

Bitrate en el cable

La tasa de datos de transport stream que realmente sale por la interfaz hacia el destino de ese canal, medida mediante captura de paquetes en lugar de notificada por el motor. Es el único valor en el que confiar. Es independiente del motor y es la única medición tomada fuera del proceso que genera el flujo, así que no puede engañarla un motor que cree estar funcionando.

Fotogramas por segundo

Frecuencia de fotogramas descodificados. Solo motor de remultiplexado.

Velocidad de reproducción

Avance a través de la fuente en relación con el tiempo real. Un valor sostenido inferior a 1.0 significa que el canal no da abasto. Solo motor de remultiplexado.

Bitrate del codificador

La tasa que el motor cree estar produciendo, a diferencia de la tasa observada en el cable. Solo motor de remultiplexado.

Tiempo de funcionamiento

Tiempo transcurrido desde que se inició el proceso actual del motor. Se pone a cero en cada reinicio, por lo que un tiempo de funcionamiento corto en un canal que usted no ha tocado es, por sí mismo, una señal.

Espectadores

Número de televisores unidos en ese momento al grupo de destino, y sus direcciones. Consulte Emisión bajo demanda para saber cómo se mide y cuándo se marca como degradado.

Tiempo de ida y vuelta a la fuente

Latencia hasta el host de origen. Útil para distinguir entre «el servidor de origen va lento» y «el camino hasta el servidor de origen va lento».

Registro del canal

Un búfer por canal con las últimas 1000 entradas o 24 horas, lo que se alcance antes, que puede leerse en la interfaz sin acceso a la shell del equipo.

No base las alertas en los fotogramas por segundo ni en la velocidad de reproducción

Estos valores proceden de la información que da el propio motor de remultiplexado. El motor pass-through nunca descodifica el vídeo —esa es precisamente su razón de ser—, así que no produce frecuencia de fotogramas ni velocidad de reproducción. Esos campos muestran n/a en esos canales, y ese es el valor correcto, no una avería.

Cualquier watchdog basado en ellos leerá n/a como cero y reiniciará indefinidamente un canal perfectamente sano. Esto ha ocurrido dos veces en producción, con dos comprobaciones distintas. Condicione esas comprobaciones al motor en uso, o básese en el bitrate en el cable, que existe para ambos.

Calidad del transport stream

Más allá de «están saliendo datos del equipo», Castmux mide si el propio transport stream está sano. Esto es lo que convierte «el canal 4 a veces se pixela» en una cifra que indica si el daño llegó con la fuente o se introdujo a la salida. El botón Stats de la tarjeta de un canal muestra gráficas de los últimos 30 minutos. Todos estos valores se sirven en GET /api/channels/{id}/ts-quality, y se exportan las métricas indicadas en OpenTelemetry.

Bitrate y dispersión CBR

La tasa del transport stream y cuánto varía en el último minuto. Conviene conocer una dispersión grande en un canal que debería ser de tasa constante antes de transportarlo por DVB-C, donde cada múltiplex tiene una capacidad fija.

Errores de continuidad

Paquetes perdidos o desordenados, detectados mediante el contador de continuidad de cada paquete y sumados para todos los PID del canal. Es la medida más directa de pérdida. Con el motor pass-through refleja fielmente la fuente. El motor de remultiplexado renumera los contadores de continuidad al escribir, por lo que la pérdida anterior a él no aparece aquí.

Errores de transporte y pérdidas de sincronismo

Paquetes que el propio emisor marcó como dañados y puntos en los que el flujo perdió su alineación de paquetes. Cualquiera de los dos es una avería anterior al equipo.

Saltos de PCR y precisión de PCR

Los saltos de PCR son saltos en el reloj del programa. La precisión de PCR comprueba si cada referencia de reloj llegó cuando su marca de tiempo indica que debía llegar. Una referencia desviada más de ts_pcr_jitter_max_ms (200 ms por defecto) cuenta como evento de jitter. Ese umbral está pensado para señalar ráfagas de entrega que el búfer de un receptor tendría que absorber, no el entrelazado normal. La precisión de PCR se mide para fuentes SRT y MPEG-TS, y en el cable para los canales con motor de remultiplexado. No se mide para HLS con el motor pass-through: los segmentos llegan a ráfagas por diseño, y una medición ahí no tendría sentido.

PID cifrados

El número de PID del canal que transportan contenido cifrado. Castmux no descifra, así que cualquier valor distinto de cero en un canal que debería estar en abierto es un problema de la fuente.

La forma de medirlo depende del motor. Un canal pass-through se mide dentro de su propia cadena de procesamiento, en el punto en que el flujo sale hacia el cable. Un canal de remultiplexado recibe un segundo proceso, de solo lectura, que se une al grupo multicast del canal y mide lo que realmente recibe un receptor. Ninguno de los dos altera el flujo. La medición está activada por defecto y puede desactivarse con ts_monitoring: false para ahorrar el pequeño coste de CPU por canal; consulte Configuración.

Actualmente los recuentos se suman para todos los PID del canal, por lo que muestran que un canal está dañado, pero no si se trata del vídeo o de una pista de audio. Un desglose por PID figura en la hoja de ruta.

Métricas del sistema

Se miden para el equipo en su conjunto y se muestran junto a la lista de canales, porque la mayoría de los problemas de capacidad se ven aquí antes que en cada canal:

• Uso de CPU. Agregado de todos los núcleos.
• Uso de memoria. La restricción determinante en estos equipos. Vigílela antes de añadir canales, no después; consulte Requisitos.
• Temperatura de la CPU. Los equipos sin ventilador dentro de armarios se comportan de otra manera en agosto.
• Bitrate por interfaz, de entrada y de salida. El de entrada indica lo que el enlace ascendente descarga de sus servidores de origen; el de salida, lo que se envía a los televisores y por qué interfaz, que con frecuencia es la forma más rápida de darse cuenta de que es la equivocada.

Métricas DVB-C

Si hay un modulador DVB-C instalado, cada múltiplex informa de su estado de ejecución, su tiempo de funcionamiento y un contador de reinicios. Consulte Multiplexación DVB-C.

Comprobaciones de salud que realiza Castmux

Castmux supervisa sus propios canales. Cada una de las condiciones siguientes se detecta de forma continua y tiene una respuesta fija y deliberada.

Condición	Qué significa	Qué hace Castmux
Sin datos al arrancar	El motor ha arrancado, pero todavía no ha producido nada.	Concede un periodo de gracia —los arranques en frío tardan legítimamente varios segundos— y después reinicia.
Silencio a mitad del flujo	Un canal que estaba produciendo datos se ha detenido. Normalmente lo ha cortado el servidor de origen.	Reinicia en cuanto vence el tiempo de espera por bloqueo.
Salida en silencio, proceso vivo	El motor está en ejecución y cree que todo va bien, pero no hay nada en el cable. El peor modo de fallo, porque todos los contadores internos parecen sanos.	Reinicia tras varios minutos de silencio confirmado.
Caída de la salida	El bitrate en el cable ha bajado, pero no se ha detenido. Las caídas breves son normales en los límites de segmento y durante los fallos momentáneos del servidor de origen.	Se tolera dentro de una ventana de gracia medida desde el último punto en que se sabía que estaba sano. Actuar ante cada caída reiniciaría canales que estaban a punto de recuperarse por sí solos.
Terminaciones prematuras repetidas	El motor muere una y otra vez poco después de arrancar. Normalmente se debe a una fuente inaccesible o inutilizable.	Espacia progresivamente los reintentos en lugar de bombardear al servidor de origen. La espera se restablece tras un periodo prolongado de funcionamiento sano, para que una fuente intermitente no acumule para siempre un retraso punitivo.
Destino sin ruta	La ruta multicast no lleva a ningún sitio utilizable. Se comprueba contra la tabla de rutas desde fuera del proceso, porque un socket no puede detectarlo.	Solo alerta. Nunca reinicia. Consulte Solución de problemas.
Emisores duplicados	Otra cosa está transmitiendo al mismo grupo multicast; habitualmente, un despliegue anterior que se deshabilitó pero no se detuvo. Los televisores reciben ambos flujos entrelazados y muestran pixelación.	Alerta. Reiniciar no serviría de nada, y detener el emisor equivocado no es una decisión que le corresponda a Castmux.
Proceso huérfano	Un proceso de motor que ha quedado de un ciclo de supervisión anterior.	Reaped.

Reiniciar lo que un reinicio puede arreglar, alertar de lo que no

Esta es la regla que refleja la tabla anterior, y merece la pena enunciarla claramente porque explica por qué algunas condiciones graves no provocan ningún reinicio.

Un reinicio es la respuesta correcta ante un proceso atascado, una conexión muerta con un servidor de origen o un motor bloqueado. Es la respuesta equivocada ante una avería de red. Si la ruta multicast apunta a una interfaz sin portadora, reiniciar el canal produce un proceso nuevo que envía al mismo vacío, y lo hace cada pocos minutos, llenando el registro de eventos de reinicio que entierran la única línea que indica la causa real. Un bucle de reinicios frente a una avería de red es peor que la avería, porque destruye las pruebas.

Por eso Castmux reinicia lo que un reinicio puede razonablemente arreglar y, para todo lo demás, se detiene, indica qué falla y deja el canal en paz.

Exportaciones

Métricas OpenTelemetry

Castmux exporta sus métricas y eventos mediante OpenTelemetry (OTLP sobre gRPC) al colector de telemetría de Castmux en otel.alteox.app, puerto 4317. La exportación está siempre activa y el colector es fijo: actualmente no se puede dirigir a un colector propio. Cada serie se etiqueta con location_name y re_seller de la instalación, el nombre de host y la versión de software del equipo, y el nombre, el protocolo, el host y el puerto de origen y el motor de cada canal. Si no se puede acceder al colector, la exportación falla sin avisar y la emisión no se ve afectada.

Los valores de calidad del transport stream se exportan por canal como go_udp_channel_ts_bitrate_kbps, go_udp_channel_cbr_spread_percent, go_udp_channel_ts_continuity_errors_total, go_udp_channel_ts_transport_errors_total, go_udp_channel_ts_pcr_leaps_total, go_udp_channel_pcr_jitter_max_microseconds y go_udp_channel_pcr_violation_percent.

Las series se etiquetan con el nombre del canal

Cambiar el nombre de un canal inicia una serie nueva; la antigua deja de recibir puntos. Si cambia el nombre de los canales con frecuencia, cuente con una discontinuidad en los paneles en ese momento. Las eliminaciones se gestionan correctamente —la serie se retira en lugar de quedarse obsoleta—, así que eliminar un canal no deja una línea plana permanente en sus gráficas.

Eventos estructurados

Junto a las métricas numéricas, Castmux emite eventos estructurados para todo lo que cambia de estado. A partir de ellos se construye una cronología después de un incidente:

• motor iniciado, motor terminado
• reinicio iniciado
• salida en silencio, salida recuperada, salida degradada
• destino sin ruta
• emisores duplicados detectados
• errores del transport stream (ts_quality_errors), con los recuentos que lo provocaron, como máximo una vez por minuto y canal
• llegada de espectadores, salida de espectadores
• ajustes modificados

Un reinicio por sí solo dice poco. Un reinicio precedido de «salida en silencio» y seguido de «salida recuperada» es un fallo momentáneo de la fuente gestionado correctamente; el mismo reinicio precedido de «destino sin ruta» es alguien que ha reiniciado un canal a mano frente a una avería de red.

Registros

Castmux escribe JSON estructurado en stdout, que un recolector de registros de contenedores puede ingerir sin capa de análisis. El mismo contenido está disponible por canal en la interfaz, con un búfer de 1000 entradas o 24 horas, lo que normalmente basta para diagnosticar una avería notificada esa misma mañana sin acceso a la shell del equipo.

Al abrir un caso de soporte, el registro del canal afectado es el adjunto más útil. Solución de problemas enumera el resto.

Hoja de ruta

Lo siguiente está comprometido, pero aún no se ha publicado. Se enumera aquí para que pueda planificar teniendo en cuenta su ausencia en lugar de descubrirla durante la puesta en marcha.

Endpoint de Prometheus previsto

Un endpoint de scrape junto a la exportación OpenTelemetry, con un panel suministrado para que la instalación no tenga que construir los paneles desde cero.

Alertas por correo electrónico y webhook previsto

Entrega de las condiciones de alerta anteriores sin una plataforma de monitorización externa de por medio.

Analizador de transport stream previsto

Análisis integrado que informa de errores del contador de continuidad, errores PES y recuentos de paquetes cifrados por PID: las mediciones que distinguen la pérdida en la fuente de la pérdida introducida localmente.

Contador de reinicios e informe de disponibilidad previsto

Recuentos de reinicios y disponibilidad por canal a lo largo de un periodo. Hoy la frecuencia de reinicios solo puede obtenerse leyendo los registros, lo que hace que responder a «¿está empeorando este canal?» sea más difícil de lo que debería.