Alertes (alerter)¶

L’alerter est un service de notification intégré. Il surveille l’état des flux, du matériel du nœud, de la réception DVB et de l’enregistrement DVR, et déclenche des alertes (incidents) lorsqu’un élément dépasse les limites définies. La liste des alertes actives est visible dans l’interface d’administration, et dans un réseau où la réplication à l’échelle du domaine est activée, chaque nœud affiche un ensemble consolidé des alertes de tout le domaine.

L’alerter fonctionne aussi sur un nœud isolé — Meshwork n’est nécessaire que pour la réplication des alertes à l’échelle du domaine.

Fonctionnement d’une alerte¶

Chaque incident possède un identifiant stable : la réapparition du même problème constitue le même incident, et non un nouveau.
Un incident passe par des états : déclenché (observé pour la première fois), mis à jour (observé à nouveau avec un changement significatif), résolu (le problème a disparu). L’ensemble actif regroupe les incidents qui n’ont pas encore été résolus.
Chaque alerte possède un niveau de gravité (par ordre croissant : information, avertissement, erreur, critique, nécessite une action de l’administrateur), un code (le type numérique d’incident — voir le catalogue ci-dessous), une source (flux, nœud, stockage), un nœud source (qui a déclenché l’alerte) et un nom d’objet lisible.
Le niveau de gravité n’est pas attaché définitivement à un incident. Tant que l’incident est ouvert, le service le réévalue en même temps que les autres contrôles (environ toutes les 5 secondes) et, en cas de changement, fait passer l’incident à l’état « mis à jour » — avec le même identifiant, de sorte qu’aucune seconde ligne n’apparaît dans la liste, qui est simplement retriée. Un tel changement n’est pas envoyé aux destinataires externes : une réévaluation ne doit pas se transformer en e-mail ou en message de chat.
La plupart des alertes sont à seuil : le service réévalue périodiquement la condition et déclenche ou résout l’alerte de lui-même. Une partie des alertes nécessitant une action de l’administrateur sont persistantes : un bref rétablissement ne les résout pas. Certaines se résolvent d’elles-mêmes, mais seulement lorsque la cause est réellement éliminée ; d’autres restent jusqu’à une résolution manuelle (voir Consultation et résolution des alertes).

La liste des alertes actives est conservée en mémoire et est effacée au redémarrage du service.

Contrôle au niveau du flux. Chaque flux dispose d’un interrupteur qui met totalement en sourdine ses alertes (avec celles de ses entrées et sorties) et d’un délai d’alerte : une source qui se rétablit dans le temps imparti ne lève pas d’alerte — cela lisse les brefs scintillements. Le même délai absorbe aussi une courte défaillance de l’entrée principale : si le flux a eu le temps de basculer sur une entrée de secours avant son expiration, il n’y aura aucune alerte d’erreur d’entrée. Le basculement est signalé par l’alerte de fonctionnement sur secours (code 27), que ce même délai diffère. Le seuil d’absence de données d’un flux se compte à part et n’est pas retenu par le délai ; il peut donc se déclencher plus tôt.

Paramètres de l’alerter¶

Les paramètres se trouvent dans la section des alertes et nécessitent le rôle d’administrateur. Les champs exacts sont décrits dans la section Interface web ; ci-dessous, ce qui peut être configuré.

Interrupteur principal du service de notification (activé par défaut). Désactivé, l’alerter reste entièrement silencieux. Le nœud ne déclenche pas ses propres alertes et n’envoie rien vers les destinations externes — ni ses propres alertes, ni celles répliquées à l’échelle du domaine depuis les nœuds voisins.
Réplication à l’échelle du domaine (activée par défaut) : un nœud partage ses alertes avec les nœuds du même domaine et reçoit les leurs ; chaque nœud affiche un ensemble consolidé. Effective uniquement lorsqu’un domaine est défini. Dans un domaine supplémentaire, un super-node n’accepte les alertes que des voisins de sa liste et ne déclenche pas d’alerte de code 26 au sujet des autres nœuds de ce domaine — leur état est visible sur la carte du réseau.
Réplication des alertes système (désactivée par défaut) : les alertes concernant le matériel du nœud (CPU et mémoire de l’hôte, processus du streamer et transcodeurs, charge réseau et GPU, remplissage de la mémoire vidéo du GPU, threads de travail et frontend DVB — codes 16–23, 40–45 et 64) sont locales par défaut ; activez cette option pour qu’elles soient également répliquées à l’échelle du domaine. Les alertes de stockage (codes 24–25) restent toujours locales.
Seuils de flux : délai d’absence de données (par défaut 15 s), débit minimal admissible (contrôle désactivé par défaut), seuil d”erreurs du compteur de continuité sur une fenêtre de 10 s (niveaux avertissement et erreur).
Entrées de secours et resynchronisation (depuis la version 2.0.2.420 ; les blocs « Resynchronisation d’entrée (codes 58, 59, 61) » et « Entrées de secours (code 65) » de l’écran Alerteur) : l’alerte de secours défaillant (code 65) et le délai au bout duquel une entrée de secours qui n’est plus vérifiée sort de sa liste ; les seuils des codes 58, 59 et 61 (le seuil du code 61 est désactivé par défaut) et le nombre d’heures calmes avant leur levée (Catalogue des codes d’alerte).
Temporisation de l’alerte d’erreurs CC (code 15, depuis la version 2.0.2.417). L’alerte n’est déclenchée ou ne monte de niveau que lorsque les pertes durent 30 secondes ; de courtes pauses entre les pertes ne remettent pas le décompte à zéro. Elle se résout après 60 secondes sans pertes. Le niveau erreur est maintenu tant que le nombre d’erreurs sur la fenêtre ne descend pas sous la moitié du seuil d’erreur. Ainsi, un seul paquet perdu ne produit pas d’alerte, et une source qui perd des paquets en permanence produit une seule alerte stable au lieu d’une suite de déclenchements et de résolutions. Les durées se définissent sur l’écran Alerteur ou par les clés stream-cc-raise-sec et stream-cc-clear-sec de la section alerter du fichier de configuration (Le fichier de configuration pss.json) : de 0 à 3600 secondes ; 0 signifie immédiatement, comme dans les versions précédentes. Le contrôle TR 101 290 (1.4 et verdict global, code 49) ne change pas.
Seuils des ressources du nœud — paires « avertissement / erreur » en pourcentage pour le CPU et la mémoire de l’hôte, le processus du streamer et les transcodeurs, la charge de l’interface réseau et du GPU, ainsi que le remplissage du stockage DVR. Les seuils de l’hôte sont fixés plus haut que ceux du processus du streamer et des transcodeurs, afin qu’un composant individuel avertisse avant que toute la machine ne sature. La valeur 0 désactive le niveau correspondant. Les seuils de remplissage de la mémoire vidéo des GPU NVIDIA (code 64) correspondent à la ligne « Mémoire vidéo GPU », 85 % et 95 % par défaut (clés gpu-mem-warning-pct et gpu-mem-error-pct de la section alerter du fichier de configuration, Le fichier de configuration pss.json).
Temporisation des alertes système (depuis la version 2.0.2.416). Une alerte sur les ressources du nœud (codes 16–24, 40 et 64) n’est déclenchée ou ne monte de niveau que lorsque la valeur reste au-delà du seuil pendant 30 secondes. Elle baisse de niveau ou se résout lorsque la valeur reste sous le seuil pendant 60 secondes. Ainsi, une charge qui franchit le seuil dans un sens puis dans l’autre d’une mesure à l’autre ne produit pas d’alertes qui apparaissent et disparaissent en quelques secondes. Les durées se définissent sur l’écran Alerteur ou par les clés system-alert-raise-sec et system-alert-clear-sec de la section alerter du fichier de configuration : de 0 à 3600 secondes ; 0 signifie immédiatement, comme dans les versions antérieures.
Seuils du frontend DVB — niveau du signal, SNR/qualité, taux d’erreur binaire et blocs non corrigés ; appliqués à un adaptateur ayant acquis le verrouillage du signal.
Seuils d’enregistrement DVR — le nombre d’écritures échouées consécutives, le multiplicateur de blocage de l’enregistrement, le taux de non-couverture de l’archive et le temps de lecture/écriture des chunks sur le disque.

Catalogue des codes d’alerte¶

Le code est le type numérique d’incident, pratique pour le regroupement et la localisation. La colonne « Réplication » indique si l”alerte est répliquée à l’échelle du domaine (lorsque la réplication est activée) ou reste locale au nœud.

Flux : état et cycle de travail (source — flux)

Code	Événement	Réplication
1	une entrée ou une sortie est passée à l’état d’erreur	à l’échelle du domaine
2	erreur irrécupérable du cycle de travail, réinitialisation manuelle requise (nécessite une action de l’administrateur)	à l’échelle du domaine
3	un flux en cours ne fournit aucune donnée au-delà du délai	à l’échelle du domaine
4	le débit du flux reste inférieur au minimum	à l’échelle du domaine
13	le flux est arrêté en attente d’une action de l’administrateur : plus aucune entrée utilisable (aucune entrée, ou toutes en pause)	à l’échelle du domaine
14	une entrée ou une sortie s’est auto-mise en pause et ne se rétablit pas après une nouvelle tentative (nécessite une action de l’administrateur)	à l’échelle du domaine
27	le flux fonctionne sur l”entrée de secours — un basculement a eu lieu	à l’échelle du domaine
39	charge CPU élevée par le thread de travail du flux	à l’échelle du domaine
58	un saut de PCR de la source au-delà de la fenêtre de discontinuité a rompu la diffusion — les données accumulées ont été rejetées	à l’échelle du domaine
59	la diffusion a été resynchronisée sur le temps réel : l’alimentation ne tient pas le délai configuré	à l’échelle du domaine
60	un flux démarré n’a plus aucune entrée qui l’alimente	à l’échelle du domaine
61	un saut de PCR de la source au-delà de la fenêtre de discontinuité s’est passé sans perte	à l’échelle du domaine
62	un module CI distinct auquel l’entrée remet le flux est indisponible ou a cessé de renvoyer des paquets : l’entrée transmet le flux sans désembrouillage	à l’échelle du domaine
65	pendant que le flux passe par une entrée, ses autres entrées sont en erreur — le secours est défaillant (depuis la version 2.0.2.420)	à l’échelle du domaine

Depuis la version 2.0.2.420, une alerte de code 1 est toujours critique : elle signifie que le flux a perdu sa source ou sa diffusion. Une sortie défaillante la reçoit toujours — il n’y a pas de secours derrière une sortie. Une entrée défaillante ne la reçoit que si le flux passe précisément par elle ou s’il n’y a pas encore d’entrée active. Les entrées tombées en panne pendant que le flux passe par une autre entrée ne reçoivent pas d’alerte de code 1 propre : dès que le flux a pris une autre entrée, leurs lignes sont levées, et le secours défaillant est décrit par une seule alerte de code 65 par flux. Ainsi, un secours défaillant ne fait pas passer en critique un flux sain. Avant la version 2.0.2.420, chacune de ces entrées gardait sa propre ligne de code 1 au niveau « erreur », et une destination externe en recevait la mise à jour de « critique » à « erreur » ; désormais, elle reçoit la levée de la ligne de code 1 et le déclenchement du code 65. La cause pour laquelle le flux a quitté une entrée reste visible dans l’interface à titre d’historique (Redondance des sources).

Une alerte de code 65 (niveau « avertissement ») énumère les entrées défaillantes du flux dans l’ordre de redondance, chacune avec sa dernière erreur : cinq au plus, puis le nombre restant. Il s’agit aussi bien d’une entrée principale défaillante pendant que le flux passe par une entrée de secours que d’une entrée de secours qui n’a pas démarré lors d’une tentative de basculement. L’alerte se déclenche après le délai d’alerte du flux et seulement lorsque le flux passe déjà de façon stable par une seule et même entrée ; une liste modifiée ne réécrit le message qu’après avoir tenu au moins une minute (ou le délai d’alerte du flux, s’il est plus long). Tant que le flux ne passe par aucune entrée, l’alerte ne change pas : la panne est décrite par les codes 60 et 1. L’alerte est levée lorsqu’il ne reste plus d’entrée défaillante — l’entrée s’est rétablie ou a été mise en pause, le flux y est revenu —, ainsi qu’à l’arrêt, à la mise en pause ou à la suppression du flux. Une entrée de secours placée plus bas que l’entrée active dans l’ordre n’est plus vérifiée pendant que le flux fonctionne ; c’est pourquoi elle sort de la liste un jour après sa dernière erreur. Ce délai est fixé par la clé stream-backup-input-max-age-min de la section alerter du fichier de configuration (en minutes, 1440 par défaut, 0 — jamais de retrait selon l’âge), sur l’écran Alerteur le champ « Oublier l’erreur d’une entrée de secours après, min » ; la clé stream-backup-input-alert désactive l’alerte (activée par défaut), sur l’écran l’interrupteur « Alerter sur les entrées de secours en échec ». Une entrée placée plus haut que l’entrée active est vérifiée en permanence et reste dans la liste jusqu’à son rétablissement.

Le code 60 décrit le flux dans son ensemble et non un point particulier : il se maintient tant qu’aucune entrée d’un flux démarré n’apporte de données, et il survit à un nombre quelconque de basculements sur la réserve. Le code 1, à l’inverse, est toujours rattaché à une entrée ou une sortie précise et, sur un flux avec redondance, se fragmente donc en plusieurs incidents éphémères. La condition doit tenir quinze secondes ; le démarrage du nœud et l’application de réglages, où les entrées cessent un instant de fournir des données, ne déclenchent donc pas le code 60. Ne relèvent pas de ce code un flux en pause et un flux arrêté en attente d’une action de l’administrateur : cet état est décrit par les codes 13 et 14.

Les codes 58, 59 et 61 signalent une recommandation portant sur les réglages de synchronisation de l’entrée, et non le compte rendu d’une défaillance ponctuelle : le nœud compte ces événements dans une fenêtre glissante d’une heure et déclenche un incident lorsqu’ils dépassent le seuil. Ils sont distingués par le coût pour le destinataire. Le code 58 est un saut de PCR de la source qui a coûté du contenu : le tampon de synchronisation a été rejeté, la diffusion rompue ; le message indique quelle quantité de flux accumulé le dernier cas de ce type a rejetée. Le code 61 est la même rupture de la ligne temporelle de la source, mais menée sans perte. Depuis la version 2.0.2.420, le code 61 a le niveau « information » (auparavant « avertissement » ; avec le seuil par défaut des destinations externes, il n’y est pas envoyé) et il est désactivé par défaut : son seuil est fixé par une clé distincte stream-sync-absorbed-count de la section alerter (de 0 à 256, 0 — désactivé), et la clé stream-sync-gap-count ne concerne plus que le code 58. Les événements sont comptés même lorsque l’alerte est désactivée ; son activation évalue donc aussitôt l’historique accumulé. Le code 59 ne concerne pas la source du tout : le tampon de synchronisation se vidait, autrement dit l’alimentation ne tient pas le délai configuré. Le remède est un tampon plus grand (Synchronisation), et sur une entrée de transcodeur également le lissage du débit sur le flux parent. Les trois sont persistantes : reconnecter l’entrée ne les résout pas. L’incident se résout de lui-même dès que l’un des réglages de synchronisation de l’entrée ou du flux est modifié (le réglage modifié est réévalué), ou lorsque le nombre d’événements reste sous le seuil pendant deux fenêtres horaires consécutives. Le nombre de fenêtres est fixé par la clé stream-sync-quiet-clear-windows de la section alerter (de 1 à 24, 2 par défaut) ; avant la version 2.0.2.420, il fallait six heures sans le moindre événement, et une source présentant une ou deux ruptures par heure gardait la ligne indéfiniment. Depuis la version 2.0.2.420, la ligne de l’entrée que le flux a quittée pour une autre entrée est également levée, de même que la ligne d’un flux mis en pause. Un flux arrêté conserve l’incident : la recommandation reste valable.

Conformité du flux de transport (analyseur TR 101 290) (source — flux ; toutes répliquées à l’échelle du domaine)

Code	Événement
5	discontinuités PCR répétées (TR 101 290, 2.3)
6	intervalle de répétition PCR supérieur à 40 ms (2.3a)
7	intervalle de répétition PAT supérieur à 500 ms (1.3)
8	intervalle de répétition PMT supérieur à 500 ms (1.5)
9	intervalle de répétition PTS supérieur à 700 ms (2.5)
10	précision PCR inférieure à 500 ns (2.4)
11	débordement ou sous-alimentation du buffer T-STD pour la vidéo (3.3)
12	dérive PCR supérieure à 30 ppm (historique : l’alerte n’est plus déclenchée, la dérive est présentée comme une métrique — Mesures permanentes)
15	erreurs du compteur de continuité au-dessus du seuil sur une courte fenêtre (1.4)
46	erreur CRC des tables PSI (2.2)
47	l’indicateur transport_error_indicator est activé (2.1)
48	intervalle de répétition de la table SI dépassé (SDT / EIT / TDT / NIT)
49	verdict global : le flux n’est pas conforme à TR 101 290

Une partie des codes de l’analyseur n’apparaît que lorsque les options d’analyse sont activées (analyse approfondie, analyse des discontinuités PTS, analyse du buffer T-STD) et ne s’applique qu’aux flux à débit constant ; le verdict global (49) n’est rendu que pour un débit constant fiable. Pour en savoir plus, voir la section Analyseur.

Ressources et matériel du nœud (source — système)

Code	Événement
16	charge CPU de l’hôte au-dessus du seuil
17	utilisation de la mémoire de l’hôte au-dessus du seuil
18	CPU du processus du streamer au-dessus du seuil
19	mémoire du processus du streamer au-dessus du seuil
20	CPU total des transcodeurs au-dessus du seuil
21	mémoire totale des transcodeurs au-dessus du seuil
22	charge de l’interface réseau au-dessus du seuil (par interface)
23	charge GPU au-dessus du seuil (par périphérique)
24	remplissage du stockage DVR au-dessus du seuil (par stockage)
25	le système de fichiers du stockage DVR est indisponible (nécessite une action de l’administrateur)
40	charge CPU élevée par le thread de travail de l’adaptateur DVB
41	le frontend DVB a perdu le signal (lock)
42	niveau du signal DVB en dessous du seuil
43	SNR/qualité du signal DVB en dessous du seuil
44	taux d’erreur binaire (BER) DVB au-dessus du seuil
45	blocs non corrigés DVB au-dessus du seuil
63	le frontend DVB garde le verrouillage (lock), mais le multiplex n’est pas reçu : la PAT n’est pas analysée pendant 20 secondes, sur trois réaccords consécutifs
64	remplissage de la mémoire vidéo du GPU NVIDIA au-dessus du seuil (par périphérique)

Toutes les alertes de ce groupe sont locales par défaut. Les codes 16–23, 40–45 et 64 peuvent être répliqués à l’échelle du domaine à l’aide de l’interrupteur de réplication des alertes système ; les codes 24–25 et 63 restent toujours locaux. Les alertes de seuil du frontend DVB (42–45) ne sont évaluées que sur un adaptateur ayant acquis le verrouillage du signal ; le code 41 est déclenché en cas de perte du verrouillage (lock). Le BER (44) est désactivé par défaut, car l’échelle brute dépend du récepteur (voir Récepteur DVB). Le code 63 n’est déclenché que sur un adaptateur auquel des flux sont rattachés, et les indicateurs du signal peuvent alors rester normaux. Après le troisième réaccord, l’adaptateur réessaie toutes les cinq minutes ; l’alerte se résout dès que la PAT est analysée.

Le code 23 surveille la charge du GPU, et le code 64 la quantité de mémoire vidéo occupée sur la carte. Une carte dont la mémoire vidéo est pleine ne peut pas lancer un nouveau canal de transcodeur, même si sa charge peut alors paraître normale. Le code 64 n’est déclenché que pour les cartes NVIDIA qui signalent le remplissage de la mémoire ; il n’existe pas pour les GPU Intel. Si une carte cesse de signaler le remplissage, l’alerte se résout. Un nœud d’une version antérieure (avant 2.0.2.416) affiche sans nom une alerte de code 64 répliquée à l’échelle du domaine, tant qu’il n’est pas mis à jour.

Meshwork et cycle de vie (source — réseau/système ; local)

Code	Événement
26	un nœud du réseau s’est tu — a cessé de confirmer la connexion
28	le processus du streamer a terminé son démarrage (notification de courte durée)
37	deux nœuds portant le même nom dans un même domaine (nécessite une action de l’administrateur)

Depuis la version 2.0.2.417, l’alerte de code 26 n’est déclenchée que lorsque le nœud reste silencieux plus d’une minute, bien qu’il soit marqué inactif sur la carte du réseau dès 15 secondes. Un redémarrage rapide d’un voisin ne produit donc pas d’alerte. Le délai se définit par le champ « Alerte de nœud hors ligne après, s » du bloc « Contact Meshwork (avancé) » des paramètres du serveur (Paramètres du serveur) et, dans le fichier de configuration, par le paramètre cluster-node-down-sec de la section cluster (Le fichier de configuration pss.json) : 60 secondes par défaut, de 0 à 3600 ; il n’est jamais inférieur à 15 secondes.

Un nœud que l’on arrête ou redémarre volontairement (arrêt ou redémarrage du service, action « Redémarrer maintenant » dans l’interface d’administration, restauration de la configuration, mise à jour de la licence) en informe d’abord ses voisins. Pendant 5 minutes, les voisins ne déclenchent pas d’alerte de code 26 pour lui, et le tableau des nœuds l’affiche comme « Redémarrage (N s) » (Nœuds) ; si le nœud n’est pas revenu dans ce délai, l’alerte est déclenchée normalement. Le délai se définit par le champ « Délai de grâce après arrêt planifié, s » du même bloc et, dans le fichier de configuration, par le paramètre cluster-leave-grace-sec de la même section : 300 secondes par défaut, de 0 à 86400. L’avis parvient aux voisins auxquels le nœud se connecte lui-même ; un voisin qui se connecte seulement à lui (par exemple, un nœud derrière un NAT) ne le reçoit pas, et le délai habituel s’applique pour lui. Les nœuds de versions antérieures à 2.0.2.417 ne tiennent pas compte de l’avis. Depuis la version 2.0.2.420, un nœud ne prévient que les voisins de version 2.0.2.417 et plus récente (et ceux dont la version n’est pas encore connue), et tous à la fois ; ainsi, dans un réseau comportant d’anciens nœuds, l’arrêt du service est plus court d’environ 3 secondes. Un arrêt du service dû à la licence (expirée, non authentique ou rejetée) ne prévient pas les voisins.

L’alerte de code 26 subsiste tout le temps que le nœud est considéré comme inactif — jusqu’à une semaine (Carte du réseau). Elle se résout d’elle-même lorsque le nœud revient en liaison, et disparaît en même temps que la ligne du nœud si le nœud inactif a été oublié manuellement.

Santé de l’enregistrement DVR (source — flux ; local)

Code	Événement
29	les écritures des segments ou de l’index DVR échouent — l’archive n’est pas enregistrée
30	l’enregistrement DVR est bloqué : l’entrée est présente, mais aucun nouveau segment n’est enregistré depuis longtemps
31	l’archive DVR s’est dégradée — lacunes dans la couverture récente
32	l’index de l’archive DVR est corrompu et n’est pas recréé — défaillance du disque (nécessite une action de l’administrateur) ; les enregistrements d’index endommagés isolés sont ignorés sans cette alerte
50	temps de lecture/écriture élevé des chunks DVR sur le disque

Configuration, transcodeurs, OTT, certificats et licence (source — système/flux)

Code	Événement	Réplication
33	la configuration principale n’a pas pu être chargée au démarrage, le service a démarré sur celle de secours (nécessite une action de l’administrateur)	à l’échelle du domaine
34	en mode low-latency HLS/DASH, les pistes audio dans un codec non pris en charge ont été supprimées (AAC et AC-3 sont pris en charge)	à l’échelle du domaine
35	impossible d’émettre ou de renouveler le certificat HTTPS via le client ACME intégré	à l’échelle du domaine
36	un transcodeur configuré n’a pas pu être chargé au démarrage — pas de fichier exécutable ou de périphérique (nécessite une action de l’administrateur)	à l’échelle du domaine
38	le flux nécessite un transcodeur (logiciel, NVIDIA ou Intel VPL) indisponible sur ce nœud (nécessite une action de l’administrateur)	local
55	la licence du nœud arrive à expiration : avertissement deux semaines avant la fin du terme ; une fois celui-ci atteint, une action de l’administrateur est nécessaire et le nœud redémarre le service ; le service ne redémarrera pas tant qu’une licence valide ne sera pas présente sur le nœud	à l’échelle du domaine
56	la licence du nœud a été jugée non authentique (nécessite une action de l’administrateur) : le nœud redémarre le service et le démarrage est refusé — le service reste arrêté tant qu’une licence authentique n’est pas présente sur le nœud et qu’il n’est pas relancé	à l’échelle du domaine
57	la licence du nœud est authentique mais appartient à une génération que cette version n’accepte plus (nécessite une action de l’administrateur) : le terme n’est pas échu et il n’y a pas de contrefaçon — la génération 2 n’est acceptée que comme licence d’essai temporaire, aussi une licence perpétuelle de cette génération est-elle rejetée d’emblée	à l’échelle du domaine

L’alerte de code 35 se résout d’elle-même à la prochaine émission réussie d’un certificat, ainsi qu’à la désactivation de l’émission automatique. Depuis la version 2.0.2.417, une alerte portant sur un problème du nœud lui-même (pas de serveur HTTPS avec le nom d’hôte, port de validation HTTP-01 occupé, erreur de la clé de compte ACME) se résout dès qu’une nouvelle tentative d’émission franchit cette étape ; auparavant, elle subsistait jusqu’à la désactivation de l’émission automatique (Certificats HTTPS).

Désembrouillage : module d’accès conditionnel (CI/CAM, EN 50221) et BISS (source — système ; local)

Code	Événement
51	le module CAM a été retiré (nécessite une action de l’administrateur)
52	pas d’abonnement : le module signale que le programme n’est pas payé
53	erreur CI/CA — une erreur irrécupérable de canal ou d’accès conditionnel
54	le désembrouillage échoue : un programme doté de la clé BISS renseignée ou affecté au CAM reste embrouillé

Un module CI distinct auquel l’entrée remet le flux (CI/CAM sur une entrée de flux) signale une défaillance par le code de flux 62, et non par les codes de ce groupe. Une entrée n’a qu’une seule alerte de ce type, même si elle utilise plusieurs slots. L’alerte se résout lorsque le module répond de nouveau pendant 30 secondes, lorsque le module est retiré de l’entrée ou lorsque l’entrée est supprimée. Un module qui répond mais ne désembrouille rien ne déclenche pas cette alerte.

Consultation et résolution des alertes¶

L’interface d’administration comporte une section des alertes avec une liste d”alertes. Elle peut être filtrée par ensemble (actives uniquement / résolues uniquement / toutes), par niveau de gravité, par type et identifiant de source, par code, par domaine et par heure, et vous pouvez également effectuer une recherche par texte du message. Par défaut, les enregistrements actifs et récemment résolus sont affichés (le journal des transitions), de sorte que le nombre total de lignes peut dépasser le nombre d’incidents actifs. Pour l’ensemble actif actuel, choisissez le mode « actives uniquement ».

Il n’est pas nécessaire d’interroger l’état manuellement : l’interface d’administration reçoit les modifications de l’ensemble actif en temps réel et met à jour la liste d’elle-même, dès qu’une alerte est déclenchée, mise à jour ou résolue.

Les alertes à seuil se résolvent automatiquement lorsque la condition disparaît. Les alertes persistantes nécessitant une action de l’administrateur (par exemple, une erreur de chargement de la configuration, l’indisponibilité du stockage, une erreur grave du cycle de travail) ne se résolvent pas d’elles-mêmes : une fois la cause éliminée, un tel incident est résolu (acquitté) manuellement. La résolution prend effet sur le nœud qui a déclenché l’alerte : si vous voyez dans le réseau un incident d’un autre nœud (répliqué à l’échelle du domaine), vous devez le résoudre sur le nœud source (il est indiqué dans la ligne). Si la source se tait, les voisins retirent ses lignes de leur liste récapitulative environ quarante-cinq secondes après son dernier message. Ce n’est pas une résolution de l’incident mais une suppression de la copie : chez la source elle-même l’incident demeure et, lorsque le nœud reprend contact, les lignes qui n’y ont pas été résolues reviennent dans la liste. C’est ainsi que quitte la liste récapitulative l’alerte de licence expirée d’un nœud arrêté — elle ne peut pas être résolue à la source, car le service n’y fonctionne pas.

Un incident qui est déclenché et résolu encore et encore n’est plus éteint immédiatement par le nœud. Après trois cycles « déclenchement — résolution » achevés et espacés de dix minutes au plus, les résolutions sont retenues : la ligne reste dans l’ensemble actif, et une seule véritable résolution ne part qu’une fois que la condition est demeurée résolue au moins aussi longtemps que la série elle-même (par défaut ces mêmes dix minutes). Un nouveau déclenchement annule le décompte, et la série se lit comme un incident continu plutôt que comme une dizaine de courts. Un premier rétablissement, ou un rétablissement rare, est éteint instantanément, tandis qu’une résolution manuelle, la suppression du flux, la désactivation des alertes sur le flux et l’arrêt du service lui-même contournent la temporisation. Le mécanisme est activé par défaut et sert avant tout à la livraison externe : sans lui, une condition en battement enverrait aux destinataires deux messages par cycle.

Réplication des alertes à l’échelle du domaine¶

Lorsque la réplication est activée et qu’un domaine est défini, chaque nœud affiche un ensemble actif consolidé pour tout le domaine : les alertes propres au nœud plus les alertes des voisins du même domaine. Chaque ligne indique le nœud source, de sorte que l’on voit sur quel nœud précis le problème s’est produit.

Répliquées à l’échelle du domaine : les alertes de flux et les alertes de conformité du flux de transport, le basculement vers l”entrée de secours, les erreurs de chargement de la configuration et du transcodeur, le rejet de l’audio OTT, l’erreur de certificat ACME, l”expiration de la licence, le constat de sa non-authenticité et une licence d’une génération que cette version n’accepte plus.
Restent locales : les alertes de ressources concernant le matériel et le stockage, « nœud silencieux », la collision de noms de nœuds, la notification de démarrage du service, les alertes de santé de l’enregistrement DVR, l’exigence d’un transcodeur indisponible sur le nœud, les alertes du module d’accès conditionnel, le désembrouillage échoué et la perte du multiplex malgré le verrouillage DVB (code 63). Les alertes système matérielles (codes 16–23 et 40–45) peuvent être basculées en réplication à l’aide de l’interrupteur de réplication des alertes système.

Chaque nœud déclenche lui-même l’alerte « nœud du réseau silencieux » à propos du voisin qui a cessé de répondre, c’est pourquoi, pour un même nœud tombé en panne, ses voisins déclencheront une telle alerte indépendamment les uns des autres.

Livraison externe des alertes¶

Outre la liste dans le navigateur, les alertes peuvent être livrées à une commande externe, dans un chat Telegram et par e-mail (SMTP). Chaque canal est indépendant et désactivé par défaut, et effectue la livraison sur son propre thread d’arrière-plan, de sorte qu’un destinataire lent ou inaccessible ne retarde pas les autres canaux ni le service lui-même.

Chaque canal possède un niveau de gravité minimal pour la livraison (avertissement par défaut) : chaque alerte visible sur le nœud (la sienne ou celle répliquée à l’échelle du domaine) au moins égale à ce niveau est livrée, tant au déclenchement qu’à la résolution. Le niveau s’applique à l’incident dans son ensemble : si la gravité n’a atteint le niveau qu’après le déclenchement, le déclenchement est signalé au moment de cette hausse, et la résolution est toujours signalée lorsque le déclenchement l’a été — déclenchement et résolution arrivent par paire. Les paramètres de connexion de chaque canal sont décrits dans la section Interface web. Le lancement de la commande externe, ce qu’elle reçoit et la manière d’écrire un script pour elle, avec des modèles prêts à l’emploi en /bin/sh et en Python, sont décrits dans Scripts externes pour les alertes.

Les canaux ne sont indépendants que les uns des autres : tous les trois sont soumis à l’interrupteur principal de l’alerter (Paramètres de l’alerter). Lorsque le service est désactivé, rien ne part — ni pour les alertes propres au nœud, ni pour celles répliquées depuis les nœuds voisins, ni pour la résolution d’un incident déjà signalé.

Problèmes courants¶

Les alertes des voisins ne sont pas visibles. Vérifiez que la réplication à l’échelle du domaine est activée sur les nœuds et qu’un domaine commun est défini. Les alertes système matérielles sont locales par défaut — activez la réplication des alertes système si vous devez également les voir à l’échelle du domaine.
Une alerte persistante ne disparaît pas après l’élimination de la cause. Résolvez-la manuellement sur le nœud source.
Les notifications externes n’arrivent pas, alors que le canal est configuré et que le seuil convient. Vérifiez l’interrupteur principal de l’alerter sur le nœud dont vous attendez la livraison : un service désactivé reste également silencieux pour les alertes d’autres nœuds répliquées à l’échelle du domaine, bien qu’elles restent visibles dans l’interface d’administration.