Alertas (alerter)¶

El alerter es un servicio de notificaciones integrado. Vigila el estado de los flujos, el hardware del nodo, la recepción DVB y la grabación DVR, y genera alertas (incidentes) cuando algo supera los límites establecidos. La lista de alertas activas se ve en el panel de administración; en una red con la replicación a nivel de dominio activada, cada nodo muestra un conjunto consolidado de alertas de todo el dominio.

El alerter también funciona en un nodo aislado — Meshwork solo es necesario para la replicación de alertas a nivel de dominio.

Cómo funciona una alerta¶

Cada incidente tiene un identificador estable: la reaparición del mismo problema es el mismo incidente, no uno nuevo.
Un incidente pasa por estados: generado (observado por primera vez), actualizado (observado de nuevo con un cambio significativo), resuelto (el problema ha desaparecido). El conjunto activo son los incidentes que aún no se han resuelto.
Cada alerta tiene un nivel de gravedad (en orden creciente: información, advertencia, error, crítico, requiere acción del administrador), un código (el tipo numérico de incidente — véase el catálogo más abajo), una fuente (flujo, nodo, almacenamiento), un nodo de origen (quién generó la alerta) y un nombre de objeto legible.
El nivel de gravedad no queda fijado al incidente para siempre. Mientras el incidente está abierto, el servicio lo reevalúa junto con las demás comprobaciones (aproximadamente cada 5 segundos) y, si cambia, pasa el incidente al estado «actualizado» — con el mismo identificador, por lo que no aparece una segunda fila en la lista, sino que la lista se reordena. A los destinatarios externos ese cambio no se les envía: una reevaluación no debe convertirse en un correo o en un mensaje de chat.
La mayoría de las alertas son por nivel: el servicio reevalúa periódicamente la condición y genera o resuelve la alerta por sí mismo. Una parte de las alertas que requieren acción del administrador son persistentes: no se resuelven por sí solas hasta que se elimina la causa (se resuelven manualmente, véase Consulta y resolución de alertas).

La lista de alertas activas se mantiene en memoria y se borra al reiniciar el servicio.

Control a nivel de flujo. Cada flujo dispone de un interruptor que silencia por completo sus alertas (junto con las de sus entradas y salidas) y de un retardo de alerta: una fuente que se restablece dentro del tiempo fijado no levanta alerta — esto suaviza los parpadeos breves. El mismo retardo absorbe también un fallo corto de la entrada principal: si el flujo ha llegado a pasar a la de reserva antes de que expirara, no habrá ninguna alerta de error de entrada — de la conmutación informa la alerta de funcionamiento en reserva (código 27), que ese mismo retardo aplaza. El umbral de ausencia de datos de un flujo se cuenta aparte y el retardo no lo contiene, por lo que puede dispararse antes.

Ajustes del alerter¶

Los ajustes se encuentran en la sección de alertas y requieren el rol de administrador. Los campos exactos se describen en la sección Interfaz web; a continuación, lo que se puede configurar.

Interruptor principal del servicio de notificaciones (activado por defecto). Un alerter desactivado calla por completo: el nodo no genera alertas propias y no envía nada a los destinos externos — ni sus propias alertas ni las replicadas a nivel de dominio desde los peers.
Replicación a nivel de dominio (activada por defecto): un nodo comparte sus alertas con los nodos del mismo dominio y recibe las de ellos — cada nodo muestra un conjunto consolidado. Solo tiene efecto cuando hay un dominio definido.
Replicación de alertas del sistema (desactivada por defecto): las alertas sobre el hardware del nodo (CPU y memoria del host, proceso del streamer y transcodificadores, carga de red y GPU, hilos de trabajo y el frontend DVB — códigos 16–23 y 40–45) son locales por defecto; actívela para que también se repliquen a nivel de dominio. Las alertas de almacenamiento (códigos 24–25) permanecen siempre locales.
Umbrales de flujo: tiempo de espera por ausencia de datos (por defecto 15 s), tasa de bits mínima admisible (comprobación desactivada por defecto), umbral de errores del contador de continuidad en una ventana de 10 s (niveles de advertencia y error).
Umbrales de recursos del nodo — pares «advertencia / error» en porcentaje para el CPU y la memoria del host, el proceso del streamer y los transcodificadores, la carga de la interfaz de red y del GPU, así como el llenado del almacenamiento DVR. Los umbrales del host se establecen más altos que los del proceso del streamer y los transcodificadores, de modo que un componente individual advierta antes de que se sature toda la máquina. El valor 0 desactiva el nivel correspondiente.
Umbrales del frontend DVB — nivel de señal, SNR/calidad, tasa de errores de bit y bloques no corregidos; se aplican a un adaptador con enganche de señal.
Umbrales de grabación DVR — el número de escrituras fallidas consecutivas, el multiplicador de estancamiento de la grabación, la proporción de no cobertura del archivo y el tiempo de lectura/escritura de los chunks en disco.

Catálogo de códigos de alerta¶

El código es el tipo numérico de incidente, cómodo para la agrupación y la localización. La columna «Replicación» indica si la alerta se replica a nivel de dominio (cuando la replicación está activada) o permanece local al nodo.

Flujos: estado y ciclo de trabajo (fuente — flujo)

Código	Evento	Replicación
1	una entrada o salida pasó al estado de error	a nivel de dominio
2	error irrecuperable del ciclo de trabajo, se necesita reinicio manual (requiere acción del administrador)	a nivel de dominio
3	un flujo en ejecución no entrega datos durante más del tiempo de espera	a nivel de dominio
4	la tasa de bits del flujo se mantiene por debajo del mínimo	a nivel de dominio
13	el flujo está en pausa: no queda ninguna entrada utilizable (requiere acción del administrador)	a nivel de dominio
14	una entrada o salida se autoaparcó y no se recupera al reintentar (requiere acción del administrador)	a nivel de dominio
27	el flujo funciona en la entrada de reserva — se produjo una conmutación	a nivel de dominio
39	carga alta de CPU por el hilo de trabajo del flujo	a nivel de dominio
58	un salto de PCR de la fuente más allá de la ventana de discontinuidad rompió la emisión: lo acumulado se descartó	a nivel de dominio
59	la emisión se resincronizó con el tiempo real: la alimentación no sostiene el retardo configurado	a nivel de dominio
60	un flujo en marcha se ha quedado sin ninguna entrada que lo alimente	a nivel de dominio
61	un salto de PCR de la fuente más allá de la ventana de discontinuidad transcurrió sin pérdidas	a nivel de dominio

El nivel de una alerta de código 1 lo determinan las consecuencias del fallo, no el mero hecho de un error. Una salida averiada es siempre «crítica»: detrás de ella no hay reserva, es una entrega perdida. Una entrada averiada es crítica solo si el flujo pasa precisamente por ella o si todavía no hay entrada activa; el fallo de una entrada que el flujo no está usando ahora es una pérdida de redundancia, y a esa alerta se le asigna el nivel «error». Así la severidad resumida de un flujo concuerda con su estado: una reserva averiada no pinta de crítico un flujo sano. Y si ya no hay adónde conmutar y el flujo se ha parado, un incidente sobre una entrada que aún intenta levantarse se lee como «crítico»: detrás de ella ya no hay reserva. Al conmutar a la reserva, el incidente de la entrada abandonada se retira por completo: la entrada se detiene, mientras que la causa por la que el flujo la dejó sigue visible en la interfaz como historial (Redundancia de fuentes).

El código 60 describe el flujo entero y no un punto concreto: se mantiene mientras ninguna entrada de un flujo en marcha aporte datos y sobrevive a cualquier número de conmutaciones a la reserva, a diferencia del código 1, que siempre está ligado a una entrada o salida concreta y por eso, en un flujo con reserva, se fragmenta en varios incidentes efímeros. La condición debe mantenerse quince segundos, de modo que el arranque del nodo y la aplicación de ajustes, donde las entradas dejan de entregar datos por un instante, no levantan el código 60. Un flujo detenido por el administrador o puesto en pausa no entra en él: ese estado lo describen los códigos 13 y 14.

Los códigos 58, 59 y 61 son una recomendación sobre los ajustes de sincronización de la entrada, no el informe de un fallo puntual: el nodo cuenta esos eventos en una ventana deslizante de una hora y levanta un incidente cuando superan el umbral. Se distinguen por el coste para el destinatario. El código 58 es un salto de PCR de la fuente que costó contenido: el búfer de sincronización se descartó y la emisión se rompió; el mensaje indica cuánto flujo acumulado descartó el último caso de este tipo. El código 61 es la misma ruptura de la línea temporal de la fuente, pero llevada a cabo sin pérdidas. El código 59 no trata de la fuente en absoluto: el búfer de sincronización se vaciaba, es decir, la alimentación no sostiene el retardo configurado; se corrige aumentando el búfer (Sincronización) y, en una entrada de transcodificador, además suavizando el bitrate en el flujo padre. Los tres son persistentes: reconectar la entrada no los resuelve. El incidente se resuelve solo cuando se cambia cualquiera de los ajustes de sincronización de la entrada o del flujo —el ajuste cambiado se evalúa de nuevo— o tras seis horas sin un solo evento. Un flujo detenido conserva el incidente: la recomendación sigue en pie.

Conformidad del flujo de transporte (analizador TR 101 290) (fuente — flujo; todas se replican a nivel de dominio)

Código	Evento
5	discontinuidades PCR repetidas (TR 101 290, 2.3)
6	intervalo de repetición PCR mayor de 40 ms (2.3a)
7	intervalo de repetición PAT mayor de 500 ms (1.3)
8	intervalo de repetición PMT mayor de 500 ms (1.5)
9	intervalo de repetición PTS mayor de 700 ms (2.5)
10	precisión PCR peor que 500 ns (2.4)
11	desbordamiento o subdesbordamiento del buffer T-STD para vídeo (3.3)
12	deriva PCR mayor de 30 ppm (histórico: la alerta ya no se genera, la deriva se muestra como métrica — Mediciones permanentes)
15	errores del contador de continuidad por encima del umbral en una ventana corta (1.4)
46	error de CRC en las tablas PSI (2.2)
47	el indicador transport_error_indicator está activado (2.1)
48	intervalo de repetición de la tabla SI superado (SDT / EIT / TDT / NIT)
49	veredicto global: el flujo no cumple con TR 101 290

Una parte de los códigos del analizador aparece solo cuando las opciones de análisis están activadas (análisis profundo, análisis de discontinuidades PTS, análisis del buffer T-STD) y se aplica únicamente a flujos de tasa de bits constante; el veredicto global (49) solo se emite para una tasa de bits fiablemente constante. Más detalles en la sección Analizador.

Recursos y hardware del nodo (fuente — sistema)

Código	Evento
16	carga de CPU del host por encima del umbral
17	uso de memoria del host por encima del umbral
18	CPU del proceso del streamer por encima del umbral
19	memoria del proceso del streamer por encima del umbral
20	CPU total de los transcodificadores por encima del umbral
21	memoria total de los transcodificadores por encima del umbral
22	carga de la interfaz de red por encima del umbral (por interfaz)
23	carga de GPU por encima del umbral (por dispositivo)
24	llenado del almacenamiento DVR por encima del umbral (por almacenamiento)
25	el sistema de archivos del almacenamiento DVR no está disponible (requiere acción del administrador)
40	carga alta de CPU por el hilo de trabajo del adaptador DVB
41	el frontend DVB perdió la señal (lock)
42	nivel de señal DVB por debajo del umbral
43	SNR/calidad de la señal DVB por debajo del umbral
44	tasa de errores de bit (BER) DVB por encima del umbral
45	bloques no corregidos DVB por encima del umbral

Todas las alertas de este grupo son locales por defecto. Los códigos 16–23 y 40–45 pueden replicarse a nivel de dominio con el interruptor de replicación de alertas del sistema; los códigos 24–25 permanecen siempre locales. Las alertas de umbral del frontend DVB (42–45) se evalúan solo en un adaptador con enganche de señal; el código 41 se genera al perder el enganche (lock). El BER (44) está desactivado por defecto, ya que la escala en bruto depende del receptor (véase Receptor DVB).

Meshwork y ciclo de vida (fuente — red/sistema; local)

Código	Evento
26	un nodo de la red se quedó en silencio — dejó de confirmar la conexión
28	el proceso del streamer terminó de arrancar (notificación de corta duración)
37	dos nodos con el mismo nombre en un mismo dominio (requiere acción del administrador)

La alerta del código 26 se mantiene todo el tiempo que el nodo figura como inaccesible, hasta una semana (Mapa de red). Se resuelve por sí sola cuando el nodo vuelve a estar en contacto, y desaparece junto con la fila del nodo si el nodo inaccesible se ha olvidado manualmente.

Salud de la grabación DVR (fuente — flujo; local)

Código	Evento
29	las escrituras de segmentos o del índice DVR fallan — el archivo no se está escribiendo
30	la grabación DVR se ha estancado: hay entrada, pero no se guarda un nuevo segmento durante mucho tiempo
31	el archivo DVR se ha degradado — huecos en la cobertura reciente
32	el índice del archivo DVR está dañado (requiere acción del administrador)
50	tiempo de lectura/escritura elevado de los chunks DVR en disco

Configuración, transcodificadores, OTT, certificados y licencia (fuente — sistema/flujo)

Código	Evento	Replicación
33	la configuración principal no se pudo cargar al arrancar, el servicio arrancó con la de reserva (requiere acción del administrador)	a nivel de dominio
34	en modo low-latency HLS/DASH se descartaron pistas de audio en un códec no compatible (se admiten AAC y AC-3)	a nivel de dominio
35	no se pudo emitir o renovar el certificado HTTPS mediante el cliente ACME integrado	a nivel de dominio
36	un transcodificador configurado no se pudo cargar al arrancar — no hay archivo ejecutable o dispositivo (requiere acción del administrador)	a nivel de dominio
38	el flujo requiere un transcodificador (software, NVIDIA o Intel VPL) no disponible en este nodo (requiere acción del administrador)	local
55	la licencia del nodo está por caducar: una advertencia dos semanas antes del fin del plazo y, una vez cumplido este, requiere acción del administrador, y el nodo reinicia el servicio	a nivel de dominio
56	la licencia del nodo se ha considerado no auténtica (requiere acción del administrador): el nodo reinicia el servicio y el arranque se rechaza — el servicio permanece detenido hasta que en el nodo haya una licencia auténtica y se vuelva a iniciar	a nivel de dominio
57	la licencia del nodo es auténtica pero pertenece a una generación que esta versión ya no acepta (requiere acción del administrador): el plazo no ha vencido y no hay falsificación — la generación 2 solo se acepta como licencia de prueba temporal, por lo que una perpetua de esa generación se rechaza de inmediato	a nivel de dominio

Descifrado: módulo de acceso condicional (CI/CAM, EN 50221) y BISS (fuente — sistema; local)

Código	Evento
51	el módulo CAM ha sido extraído (requiere acción del administrador)
52	sin suscripción: el módulo informa de que el programa no está pagado
53	error CI/CA — un error irrecuperable de canal o de acceso condicional
54	el descifrado no funciona: un programa con la clave BISS indicada o asignado al CAM sigue cifrado

Consulta y resolución de alertas¶

El panel de administración tiene una sección de alertas con una lista de alertas. Se puede filtrar por conjunto (solo activas / solo resueltas / todas), por nivel de gravedad, por tipo e identificador de la fuente, por código, por dominio y por tiempo, y también se puede buscar por el texto del mensaje. Por defecto se muestran tanto los registros activos como los resueltos recientemente (el registro de transiciones), por lo que el número total de filas puede superar el número de incidentes activos — para el conjunto activo actual, elija el modo «solo activas».

No es necesario consultar el estado manualmente: el panel de administración recibe los cambios del conjunto activo en tiempo real y actualiza la lista por sí mismo, en cuanto una alerta se genera, se actualiza o se resuelve.

Las alertas por nivel se resuelven automáticamente cuando la condición desaparece. Las alertas persistentes que requieren acción del administrador (por ejemplo, un error de carga de la configuración, la indisponibilidad del almacenamiento, un error grave del ciclo de trabajo) no se resuelven por sí solas: una vez eliminada la causa, dicho incidente se resuelve (se confirma) manualmente. La resolución tiene efecto en el nodo que generó la alerta: si en la red ve un incidente ajeno (replicado a nivel de dominio), debe resolverlo en el nodo de origen (se indica en la fila). Si la fuente enmudece, los vecinos retiran sus filas de su lista consolidada unos cuarenta y cinco segundos después de su último mensaje. Esto no es una resolución del incidente, sino la eliminación de la copia: en la propia fuente el incidente permanece y, cuando el nodo vuelva a comunicarse, las filas no resueltas allí regresarán a la lista. Así abandona también la lista consolidada la alerta de licencia caducada de un nodo detenido: no es posible resolverla en la fuente, porque allí el servicio no funciona.

Un incidente que se levanta y se resuelve una y otra vez deja de apagarse de inmediato en el nodo. Tras tres ciclos completos de «levantamiento — resolución» separados por no más de diez minutos, las resoluciones se retienen: la fila permanece en el conjunto activo y una única resolución verdadera sale solo cuando la condición se ha mantenido resuelta al menos tanto como duró la propia serie, por defecto esos mismos diez minutos. Un nuevo levantamiento cancela la cuenta atrás, y la serie se lee como un incidente continuo en lugar de una decena de cortos. Una recuperación primera o poco frecuente se apaga al instante, como antes, mientras que una resolución manual, la eliminación del flujo, la desactivación de las alertas en el flujo y la desconexión del propio servicio eluden la espera. El mecanismo está activado por defecto y hace falta sobre todo para la entrega externa: sin él, una condición oscilante enviaría a los destinatarios un par de mensajes por ciclo.

Replicación de alertas a nivel de dominio¶

Con la replicación activada y un dominio definido, cada nodo muestra un conjunto activo consolidado de todo el dominio: las alertas propias del nodo más las alertas de los peers del mismo dominio. Cada fila indica el nodo de origen, de modo que se ve en qué nodo exactamente se produjo el problema.

Se replican a nivel de dominio: las alertas de flujo y las alertas de conformidad del flujo de transporte, la conmutación a la entrada de reserva, los errores de carga de la configuración y del transcodificador, el descarte de audio OTT, el error de certificado ACME, la caducidad de la licencia y su consideración como no auténtica.
Permanecen locales: las alertas de recursos sobre hardware y almacenamiento, «nodo en silencio», la colisión de nombres de nodos, la notificación de arranque del servicio, las alertas de salud de la grabación DVR, la exigencia de un transcodificador no disponible en el nodo, las alertas del módulo de acceso condicional y el descifrado fallido. Las alertas del sistema sobre el hardware (códigos 16–23 y 40–45) se pueden pasar a replicación con el interruptor de replicación de alertas del sistema.

Cada nodo genera por sí mismo la alerta «nodo de la red en silencio» sobre el peer que dejó de responder — por eso, para un mismo nodo caído, sus peers generarán tal alerta de forma independiente unos de otros.

Entrega externa de alertas¶

Además de la lista en el navegador, las alertas se pueden entregar a un comando externo, a un chat de Telegram y por correo electrónico (SMTP). Cada canal es independiente y está desactivado por defecto, y realiza la entrega en su propio hilo en segundo plano, por lo que un destinatario lento o inaccesible no retrasa los demás canales ni el propio servicio.

Cada canal tiene un nivel de gravedad mínimo para la entrega (advertencia por defecto): se entrega cada alerta visible en el nodo (propia o replicada a nivel de dominio) que no sea inferior a este nivel, tanto al generarse como al resolverse. Los parámetros de conexión de cada canal se describen en la sección Interfaz web.

Los canales son independientes solo entre sí: los tres están sujetos al interruptor principal del alerter (Ajustes del alerter). Con el servicio desactivado no se envía nada: ni por las alertas propias, ni por las replicadas desde los peers, ni por la resolución de un incidente del que ya se había informado.

Problemas comunes¶

Las alertas de los peers no se ven. Compruebe que la replicación a nivel de dominio está activada en los nodos y que hay un dominio común definido. Las alertas del sistema sobre el hardware son locales por defecto — active la replicación de alertas del sistema si también necesita verlas a nivel de dominio.
Una alerta persistente no desaparece tras eliminar la causa. Resuélvala manualmente en el nodo de origen.
No llegan notificaciones externas aunque el canal esté configurado y el umbral sea el adecuado. Compruebe el interruptor principal del alerter en el nodo del que espera la entrega: con el servicio desactivado también calla ante las alertas ajenas, replicadas a nivel de dominio, aunque en el panel de administración se sigan viendo.