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, y en una red con la replicación por el 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 replicar las alertas por el 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: una recuperación breve no las resuelve. Unas se resuelven solas solo cuando la causa se ha eliminado de verdad; otras permanecen hasta que 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 genera alerta, lo que 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 entrada 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 se indica qué 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 por el dominio desde los nodos vecinos.
Replicación por el 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. Un super-node, en un dominio adicional, acepta alertas solo de los vecinos de su lista y no genera la alerta de código 26 sobre los demás nodos de ese dominio: su estado se ve en el mapa de red.
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, llenado de la memoria de vídeo de la GPU, hilos de trabajo y el frontend DVB — códigos 16–23, 40–45 y 64) son locales por defecto; actívela para que también se repliquen por el 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).
Entradas de reserva y resincronización (desde la versión 2.0.2.420; los bloques «Resincronización de entrada (códigos 58, 59, 61)» y «Entradas de respaldo (código 65)» de la pantalla Alertador): la alerta de reserva averiada (código 65) y el plazo tras el cual una entrada de reserva que ya no se comprueba sale de su lista; los umbrales de los códigos 58, 59 y 61 (el del código 61 está desactivado por defecto) y el número de horas tranquilas antes de que se retiren (Catálogo de códigos de alerta).
Tiempo de retención de la alerta de errores CC (código 15, desde la versión 2.0.2.417). La alerta se genera o sube de nivel solo cuando las pérdidas continúan durante 30 segundos; las pausas breves entre pérdidas no reinician la cuenta. Se retira tras 60 segundos sin pérdidas. El nivel de error se mantiene hasta que el número de errores en la ventana baja de la mitad del umbral de error. Por eso un solo paquete perdido no produce alerta, y una fuente que pierde paquetes constantemente produce una única alerta estable en lugar de una serie de activaciones y retiradas. Los tiempos se definen en la pantalla Alertador o con las claves stream-cc-raise-sec y stream-cc-clear-sec de la sección alerter del archivo de configuración (El archivo de configuración pss.json): de 0 a 3600 segundos; 0 significa inmediatamente, como en versiones anteriores. La comprobación TR 101 290 (1.4 y veredicto global, código 49) no cambia.
Umbrales de recursos del nodo — pares «advertencia / error» en porcentaje para la CPU y la memoria del host, el proceso del streamer y los transcodificadores, la carga de la interfaz de red y de la 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. Los umbrales de llenado de la memoria de vídeo de las GPU NVIDIA (código 64) son la fila «Memoria de vídeo de la GPU», 85 % y 95 % por defecto (claves gpu-mem-warning-pct y gpu-mem-error-pct de la sección alerter del archivo de configuración, El archivo de configuración pss.json).
Tiempo de retención de las alertas del sistema (desde la versión 2.0.2.416). Una alerta sobre los recursos del nodo (códigos 16–24, 40 y 64) se genera o sube de nivel solo cuando el valor se mantiene más allá del umbral durante 30 segundos. Baja de nivel o se retira cuando el valor se mantiene por debajo del umbral durante 60 segundos. Así, una carga que salta por encima y por debajo del umbral de una medición a otra no produce alertas que aparecen y desaparecen en segundos. Los tiempos se definen en la pantalla Alertador o con las claves system-alert-raise-sec y system-alert-clear-sec de la sección alerter del archivo de configuración: de 0 a 3600 segundos; 0 significa de inmediato, como en versiones anteriores.
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, útil para agrupar y localizar. La columna «Replicación» indica si la alerta se replica por el 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	por el dominio
2	error irrecuperable del ciclo de trabajo, se necesita reinicio manual (requiere acción del administrador)	por el dominio
3	un flujo en ejecución no entrega datos durante más del tiempo de espera	por el dominio
4	la tasa de bits del flujo se mantiene por debajo del mínimo	por el dominio
13	el flujo está detenido en espera de una acción del administrador: no queda ninguna entrada utilizable (no hay entradas o todas están en pausa)	por el dominio
14	una entrada o salida se autoaparcó y no se recupera al reintentar (requiere acción del administrador)	por el dominio
27	el flujo funciona en la entrada de reserva: se produjo una conmutación	por el dominio
39	carga alta de CPU por el hilo de trabajo del flujo	por el 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ó	por el dominio
59	la emisión se resincronizó con el tiempo real: la alimentación no sostiene el retardo configurado	por el dominio
60	un flujo en marcha se ha quedado sin ninguna entrada que lo alimente	por el dominio
61	un salto de PCR de la fuente más allá de la ventana de discontinuidad transcurrió sin pérdidas	por el dominio
62	un módulo CI aparte al que la entrada entrega el flujo no está disponible o ha dejado de devolver paquetes: la entrada transmite el flujo sin desaleatorizar	por el dominio
65	mientras el flujo pasa por una entrada, sus otras entradas están en error: la reserva está averiada (desde la versión 2.0.2.420)	por el dominio

Desde la versión 2.0.2.420 la alerta de código 1 es siempre crítica: significa que el flujo ha perdido su fuente o su entrega. Una salida averiada la recibe siempre: detrás de una salida no hay reserva. Una entrada averiada la recibe solo si el flujo pasa precisamente por ella o si todavía no hay entrada activa. Las entradas que fallaron mientras el flujo pasa por otra entrada no reciben una alerta de código 1 propia: en cuanto el flujo ha tomado otra entrada, sus filas se retiran, y la reserva averiada la describe una sola alerta de código 65 por flujo. Así una reserva averiada no pinta de crítico un flujo sano. Antes de la versión 2.0.2.420 cada una de esas entradas mantenía su propia fila de código 1 con el nivel «error», y un destino externo recibía su actualización de «crítico» a «error»; ahora recibe la retirada de la fila de código 1 y la generación del código 65. La causa por la que el flujo dejó una entrada sigue visible en la interfaz como historial (Redundancia de fuentes).

La alerta de código 65 (nivel «advertencia») enumera las entradas averiadas del flujo en el orden de reserva, cada una con su último error: no más de cinco y, después, cuántas más hay. Son tanto una entrada principal averiada mientras el flujo pasa por una de reserva como una entrada de reserva que no se levantó en un intento de conmutación. La alerta se genera tras el retardo de alertas del flujo y solo cuando el flujo ya pasa de forma estable por una misma entrada; una lista que ha cambiado reescribe el mensaje solo después de mantenerse al menos un minuto (o el retardo de alertas del flujo, si es mayor). Mientras el flujo no pasa por ninguna entrada, la alerta no cambia: la avería la describen los códigos 60 y 1. La alerta se retira cuando no quedan entradas averiadas —la entrada se ha recuperado o se ha puesto en pausa, el flujo ha vuelto a ella— y también al detener, pausar o eliminar el flujo. Una entrada de reserva situada por debajo de la activa en el orden ya no se comprueba mientras el flujo funciona, por lo que sale de la lista un día después de su último error. El plazo lo fija la clave stream-backup-input-max-age-min de la sección alerter del archivo de configuración (en minutos, 1440 por defecto, 0: nunca retirar por antigüedad), en la pantalla Alertador, el campo «Olvidar el error de una entrada de respaldo tras, min»; la clave stream-backup-input-alert desactiva la alerta (activada por defecto), en la pantalla, el interruptor «Avisar de entradas de respaldo con fallos». Una entrada situada por encima de la activa se comprueba continuamente y permanece en la lista hasta que se recupera.

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. El código 1, en cambio, 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 generan el código 60. No entran en él un flujo en pausa ni un flujo detenido en espera de una acción del administrador: ese estado lo describen los códigos 13 y 14.

Los códigos 58, 59 y 61 indican 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 genera 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. Desde la versión 2.0.2.420 el código 61 tiene el nivel «información» (antes, «advertencia»; con el umbral predeterminado de los destinos externos no llega a ellos) y está desactivado por defecto: su umbral lo fija una clave propia stream-sync-absorbed-count de la sección alerter (de 0 a 256, 0: desactivado), y la clave stream-sync-gap-count ahora se refiere solo al código 58. Los eventos se cuentan también con la alerta desactivada, por lo que al activarla se evalúa de inmediato el historial acumulado. 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. Esto 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 cuando el número de eventos se mantiene por debajo del umbral durante dos ventanas horarias seguidas. El número de ventanas lo fija la clave stream-sync-quiet-clear-windows de la sección alerter (de 1 a 24, 2 por defecto); antes de la versión 2.0.2.420 hacían falta seis horas sin un solo evento, y una fuente con una o dos rupturas por hora mantenía la fila indefinidamente. Desde la versión 2.0.2.420 también se retira la fila de la entrada desde la que el flujo conmutó a otra entrada, así como la fila de un flujo puesto en pausa. 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 por el 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
63	el frontend DVB mantiene el enganche (lock), pero el multiplex no se recibe: la PAT no se analiza durante 20 segundos, tres resintonizaciones seguidas
64	llenado de la memoria de vídeo de la GPU NVIDIA por encima del umbral (por dispositivo)

Todas las alertas de este grupo son locales por defecto. Los códigos 16–23, 40–45 y 64 pueden replicarse por el dominio con el interruptor de replicación de alertas del sistema; los códigos 24–25 y 63 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). El código 63 se genera solo en un adaptador al que hay flujos conectados, y los indicadores de la señal pueden seguir siendo normales. Tras la tercera resintonización, el adaptador repite el intento cada cinco minutos; la alerta se retira en cuanto se analiza la PAT.

El código 23 vigila la carga de la GPU, y el código 64, cuánta memoria de vídeo de la tarjeta está ocupada. Una tarjeta con la memoria de vídeo llena no puede iniciar un nuevo canal de transcodificador, aunque su carga parezca normal en ese momento. El código 64 se genera solo para tarjetas NVIDIA que informan del llenado de la memoria; para las GPU Intel no existe. Si una tarjeta deja de informar del llenado, la alerta se retira. Un nodo de una versión anterior (antes de 2.0.2.416) muestra sin nombre una alerta de código 64 replicada por el dominio hasta que se actualiza.

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)

Desde la versión 2.0.2.417, la alerta del código 26 se genera solo cuando el nodo lleva más de un minuto en silencio, aunque en el mapa de red se marca como inaccesible ya a los 15 segundos. Por eso un reinicio rápido de un vecino no produce alerta. El retardo lo define el campo «Alerta de nodo caído tras, s» del bloque «Contacto de Meshwork (avanzado)» de la configuración del servidor (Configuración del servidor) y, en el archivo de configuración, el parámetro cluster-node-down-sec de la sección cluster (El archivo de configuración pss.json): 60 segundos por defecto, de 0 a 3600; nunca es inferior a 15 segundos.

Un nodo que se detiene o se reinicia intencionadamente (parada o reinicio del servicio, la acción «Reiniciar ahora» del panel de administración, restauración de la configuración, actualización de la licencia) primero lo comunica a sus vecinos. Durante 5 minutos los vecinos no generan para él la alerta del código 26, y en la tabla de nodos figura como «Reiniciando (N s)» (Nodos); si en ese tiempo el nodo no ha vuelto, la alerta se genera como de costumbre. El plazo lo define el campo «Gracia tras parada planificada, s» del mismo bloque y, en el archivo de configuración, el parámetro cluster-leave-grace-sec de la misma sección: 300 segundos por defecto, de 0 a 86400. El aviso lo reciben los vecinos a los que el nodo se conecta por sí mismo; un vecino que solo se conecta a él (por ejemplo, un nodo detrás de NAT) no recibe el aviso, y para él rige el retardo habitual. Los nodos de versiones anteriores a la 2.0.2.417 no tienen en cuenta el aviso. Desde la versión 2.0.2.420, un nodo avisa solo a los vecinos de la versión 2.0.2.417 o posterior (y a aquellos cuya versión aún se desconoce), y a todos a la vez, por lo que en una red con nodos antiguos la parada del servicio es unos 3 segundos más corta. Una parada del servicio por la licencia (caducada, no auténtica o rechazada) no avisa a los vecinos.

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: hay huecos en la cobertura reciente
32	el índice del archivo DVR está dañado y no se vuelve a crear — fallo del disco (requiere acción del administrador); los registros dañados sueltos del índice se omiten sin esta alerta
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)	por el 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)	por el dominio
35	no se pudo emitir o renovar el certificado HTTPS mediante el cliente ACME integrado	por el dominio
36	un transcodificador configurado no se pudo cargar al arrancar: no hay archivo ejecutable o dispositivo (requiere acción del administrador)	por el 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; el servicio no volverá a arrancar hasta que el nodo tenga una licencia vigente	por el 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	por el 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	por el dominio

La alerta del código 35 se resuelve por sí sola en la siguiente emisión correcta del certificado, y también al desactivar la emisión automática. Desde la versión 2.0.2.417, una alerta sobre un problema del propio nodo (no hay servidor HTTPS con el nombre del host, el puerto de validación HTTP-01 está ocupado, error de la clave de la cuenta ACME) se resuelve en cuanto el siguiente intento de emisión supera ese paso; antes se mantenía hasta desactivar la emisión automática (Certificados HTTPS).

Desaleatorización: 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	la desaleatorización no funciona: un programa con la clave BISS indicada o asignado al CAM sigue codificado

Un módulo CI aparte al que la entrada entrega el flujo (CI/CAM en la entrada de un flujo) informa del fallo con el código de flujo 62, no con los códigos de este grupo. Cada entrada tiene una sola alerta de este tipo, aunque use varias ranuras. La alerta se retira cuando el módulo vuelve a responder durante 30 segundos, cuando se quita el módulo de la entrada o cuando se elimina la entrada. Un módulo que responde pero no desaleatoriza nada no genera esta alerta.

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 por el 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.

Cuando un incidente se genera y se resuelve una y otra vez, el nodo deja de apagarlo de inmediato. Tras tres ciclos completos de «generación — 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). Si el incidente vuelve a generarse, la cuenta atrás se cancela, 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, 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 por el 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 vecinos 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 por el 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, su consideración como no auténtica y una licencia de una generación que esta versión ya no acepta.
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 la desaleatorización fallida, y la pérdida del multiplex con enganche DVB (código 63). 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 vecino que dejó de responder, por lo que, para un mismo nodo caído, sus vecinos generarán esa 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 por el dominio) que no sea inferior a este nivel, tanto al generarse como al resolverse. El nivel se aplica al incidente en su conjunto: si la gravedad subió hasta el nivel después de generarse, la generación se notifica en el momento de la subida, y la resolución se notifica siempre que se notificó la generación: generación y resolución llegan en pareja. Los parámetros de conexión de cada canal se describen en la sección Interfaz web. Cómo se ejecuta el comando externo, qué recibe y cómo escribir un script para él, con plantillas listas para /bin/sh y Python, se explica en Scripts externos para alertas.

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 nodos vecinos, ni por la resolución de un incidente del que ya se había informado.

Problemas comunes¶

Las alertas de los vecinos no se ven. Compruebe que la replicación por el 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 en todo el 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 por el dominio, aunque en el panel de administración se sigan viendo.