---
title: Alertes (alerter)
url: https://doc2.pstreamer.tv/fr/manual/meshwork/alerts.html
lang: fr
product: Perfect Streamer
version: 2.0.2.362
---

# 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 ; dans un réseau où la réplication à l’échelle du domaine est activée, chaque nœud affiche un ensemble consolidé d’alertes pour l’ensemble du 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** — elles ne se résolvent pas d’elles-mêmes tant que la cause n’est pas éliminée (elles se résolvent manuellement, 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](../webui/index.md#webui) ; 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.
- **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, threads de travail et frontend DVB — codes 16–23 et 40–45) 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).
- **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 plus tôt que la saturation de toute la machine. La valeur 0 désactive le niveau correspondant.
- **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 en pause : plus aucune entrée utilisable (nécessite une action de l’administrateur) | à 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 — l’accumulé a été rejeté | à 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 |

Le niveau d’une alerte de code 1 est déterminé par les conséquences de la défaillance et non par le simple fait d’une erreur. Une sortie défaillante est toujours « critique » : il n’y a pas de secours derrière elle, c’est une diffusion perdue. Une entrée défaillante n’est critique que si le flux passe précisément par elle ou s’il n’y a pas encore d’entrée active ; la défaillance d’une entrée que le flux n’utilise pas en ce moment est une perte de redondance, et une telle alerte reçoit le niveau « erreur ». La gravité globale d’un flux s’accorde ainsi avec son état : un secours défaillant ne peint pas en critique un flux sain. Et lorsqu’il n’y a plus rien vers quoi basculer et que le flux est arrêté, un incident sur une entrée qui tente encore de démarrer se lit comme « critique » — il n’y a plus de secours derrière elle. Lors d’un basculement vers un secours, l’incident sur l’entrée abandonnée est entièrement levé : l’entrée est arrêtée, tandis que la cause pour laquelle le flux l’a quittée reste visible dans l’interface à titre d’historique ([Redondance des sources](../streamer/spts.md#streamer-spts-reservation)).

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 — contrairement au code 1, toujours rattaché à une entrée ou une sortie précise et qui, sur un flux avec réservation, 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. Un flux arrêté par l’administrateur ou mis en pause n’en relève pas — cet état est décrit par les codes 13 et 14.

Les codes 58, 59 et 61 constituent 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. 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](../streamer/spts.md#streamer-spts-sync)), 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 après six heures sans le moindre événement. 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](../streamer/analyzer.md#streamer-analyzer-metrics)) |
| 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](../streamer/analyzer.md#streamer-analyzer).

**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 |

Toutes les alertes de ce groupe sont locales par défaut. Les codes 16–23 et 40–45 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 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](../streamer/dvb.md#streamer-dvb)).

**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) |

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](map.md#meshwork-map-nodes)). 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 (nécessite une action de l’administrateur) |
| 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 : un avertissement deux semaines avant la fin du terme et, une fois celui-ci atteint — nécessite une action de l’administrateur, et le nœud redémarre le service | à 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 |

**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é |

## 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 rétablissement premier ou rare est éteint instantanément, comme auparavant, 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 l’ensemble du domaine : les alertes propres au nœud plus les alertes des peers 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 et le constat de sa non-authenticité.
- **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 et le désembrouillage échoué. 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 peer qui a cessé de répondre — c’est pourquoi, pour un même nœud tombé en panne, ses peers 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. Les paramètres de connexion de chaque canal sont décrits dans la section [Interface web](../webui/index.md#webui).

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 peers 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.