Supervision et métriques

Métriques par chaîne

Chaque chaîne expose les éléments suivants dans l’interface et via l’API HTTP.

Débit sur le fil

Le débit de données transport stream qui sort réellement de l’interface vers la destination de cette chaîne, mesuré par capture de paquets plutôt que déclaré par le moteur. C’est le chiffre auquel se fier. Il est indépendant du moteur, et c’est la seule mesure prise en dehors du processus qui produit le flux : un moteur persuadé de fonctionner ne peut donc pas le tromper.

Images par seconde

Fréquence d’images décodée. Moteur de remultiplexage uniquement.

Vitesse de lecture

Progression dans la source par rapport au temps réel. Une valeur durablement inférieure à 1.0 signifie que la chaîne n’arrive pas à suivre. Moteur de remultiplexage uniquement.

Débit de l’encodeur

Le débit que le moteur pense produire, par opposition au débit observé sur le fil. Moteur de remultiplexage uniquement.

Durée de fonctionnement

Temps écoulé depuis le démarrage du processus moteur actuel. Elle est remise à zéro à chaque redémarrage : une durée courte sur une chaîne que vous n’avez pas touchée est donc un signal en soi.

Spectateurs

Nombre de téléviseurs actuellement abonnés au groupe de destination, et leurs adresses. Voir Diffusion à la demande pour la manière dont cette valeur est mesurée et le moment où elle est marquée dégradée.

Temps aller-retour vers la source

Latence vers l’hôte d’origine. Utile pour distinguer « le serveur d’origine est lent » de « le chemin vers le serveur d’origine est lent ».

Journal de la chaîne

Un tampon par chaîne contenant les 1000 dernières entrées ou les dernières 24 heures, selon la limite atteinte en premier, consultable dans l’interface sans accès shell à l’appareil.

Qualité du transport stream

Au-delà de « des données sortent-elles du boîtier ? », Castmux mesure si le transport stream lui-même est sain. C’est ce qui transforme « la chaîne 4 se dégrade parfois » en un chiffre qui indique si les dégâts sont arrivés avec la source ou ont été introduits à la sortie. Le bouton Stats de la carte d’une chaîne affiche les graphiques des 30 dernières minutes. Toutes ces valeurs sont servies par GET /api/channels/{id}/ts-quality, et les métriques listées sous OpenTelemetry sont exportées.

Débit et dispersion CBR

Le débit du transport stream, et son degré de variation sur la dernière minute. Une forte dispersion sur une chaîne censée être à débit constant mérite d’être connue avant qu’elle ne soit transportée en DVB-C, où chaque multiplex a une capacité fixe.

Erreurs de continuité

Paquets manquants ou hors séquence, détectés à partir du compteur de continuité de chaque paquet et additionnés sur l’ensemble des PID de la chaîne. C’est la mesure la plus directe des pertes. Avec le moteur pass-through, elle reflète fidèlement la source. Le moteur de remultiplexage renumérote les compteurs de continuité en écrivant : les pertes en amont n’apparaissent donc pas ici.

Erreurs de transport et pertes de synchronisation

Paquets que l’émetteur lui-même a signalés comme endommagés, et endroits où le flux a perdu l’alignement de ses paquets. Dans les deux cas, il s’agit d’un défaut en amont de l’appareil.

Sauts de PCR et précision du PCR

Les sauts de PCR sont des sauts de l’horloge de programme. La précision du PCR vérifie si chaque référence d’horloge est arrivée au moment indiqué par son horodatage. Une référence qui s’en écarte de plus de ts_pcr_jitter_max_ms (200 ms par défaut) compte comme un événement de gigue. Ce seuil est réglé pour signaler les rafales de livraison que le tampon d’un récepteur devrait absorber, pas l’entrelacement ordinaire. La précision du PCR est mesurée pour les sources SRT et MPEG-TS, et sur le fil pour les chaînes du moteur de remultiplexage. Elle n’est pas mesurée pour le HLS avec le moteur pass-through : les segments arrivent par rafales par conception, et une mesure à cet endroit n’aurait aucun sens.

PID embrouillés

Le nombre de PID de la chaîne qui transportent un contenu embrouillé. Castmux ne désembrouille pas : toute valeur non nulle sur une chaîne censée être en clair est un problème de source.

La méthode de mesure dépend du moteur. Une chaîne pass-through est mesurée dans son propre pipeline, au point où le flux part vers le fil. Une chaîne en remultiplexage reçoit un second processus, en lecture seule, qui rejoint le groupe multicast de la chaîne et mesure ce qu’un récepteur reçoit réellement. Aucun des deux ne modifie le flux. La mesure est activée par défaut et peut être désactivée avec ts_monitoring: false pour économiser le faible coût CPU par chaîne — voir Configuration.

À ce jour, les compteurs sont additionnés sur l’ensemble des PID de la chaîne : ils montrent qu’une chaîne est endommagée, mais pas s’il s’agit de la vidéo ou d’une piste audio. Une ventilation par PID figure sur la feuille de route.

Métriques système

Mesurées pour l’appareil dans son ensemble et affichées à côté de la liste des chaînes, car la plupart des problèmes de capacité sont visibles ici avant de l’être chaîne par chaîne :

Utilisation CPU. Cumulée sur tous les cœurs.
Utilisation mémoire. La contrainte déterminante sur ces appareils. Surveillez-la avant d’ajouter des chaînes, pas après — voir Prérequis.
Température CPU. Les boîtiers sans ventilateur installés dans des placards ne se comportent pas de la même façon en août.
Débit par interface, entrant et sortant. L’entrant indique ce que la liaison montante tire de vos serveurs d’origine ; le sortant indique ce qui est envoyé aux téléviseurs, et sur quelle interface — c’est souvent le moyen le plus rapide de remarquer que ce n’est pas la bonne.

Métriques DVB-C

Lorsqu’un modulateur DVB-C est installé, chaque multiplex indique son état de fonctionnement, sa durée de fonctionnement et un compteur de redémarrages. Voir Multiplexage DVB-C.

Contrôles de santé effectués par Castmux

Castmux supervise ses propres chaînes. Chaque condition ci-dessous est détectée en continu et donne lieu à une réaction fixe et délibérée.

Condition	Signification	Réaction de Castmux
Aucune donnée au démarrage	Le moteur a démarré mais n'a encore rien produit.	Accorde un délai de grâce — un démarrage à froid prend légitimement quelques secondes — puis redémarre.
Silence en cours de flux	Une chaîne qui produisait des données s'est arrêtée. En général, le serveur d'origine l'a lâchée.	Redémarre à l'expiration du délai de blocage.
Sortie muette, processus vivant	Le moteur tourne et pense que tout va bien, mais rien ne passe sur le fil. Le pire mode de défaillance, car tous les compteurs internes semblent sains.	Redémarre après plusieurs minutes de silence confirmé.
Baisse de la sortie	Le débit sur le fil a chuté sans s'arrêter. De brèves baisses sont normales aux limites de segments et lors des hoquets du serveur d'origine.	Tolérée dans une fenêtre de grâce mesurée depuis le dernier point sain connu. Réagir à chaque baisse redémarrerait des chaînes qui étaient sur le point de se rétablir seules.
Arrêts précoces répétés	Le moteur meurt systématiquement peu après le démarrage. Normalement, une source injoignable ou inutilisable.	Espace progressivement les tentatives plutôt que de marteler le serveur d'origine. Ce délai est réinitialisé après une période prolongée de bon fonctionnement, afin qu'une source intermittente n'accumule pas indéfiniment un délai pénalisant.
Destination non routable	La route multicast ne mène nulle part d'utilisable. Vérifié par rapport à la table de routage depuis l'extérieur du processus, car une socket ne peut pas le détecter.	Alerte uniquement. Ne redémarre jamais. Voir Dépannage.
Émetteurs en double	Quelque chose d'autre émet vers le même groupe multicast — souvent un ancien déploiement désactivé mais pas arrêté. Les téléviseurs reçoivent les deux flux entrelacés et affichent de la pixellisation.	Alerte. Un redémarrage n'aiderait pas, et arrêter le mauvais émetteur n'est pas une décision qui revient à Castmux.
Processus orphelin	Un processus moteur laissé par un cycle de supervision précédent.	Reaped.

Redémarrer ce qu’un redémarrage peut réparer, alerter pour le reste

C’est la règle qu’encode le tableau ci-dessus, et elle mérite d’être énoncée clairement, car elle explique pourquoi certaines conditions graves ne provoquent aucun redémarrage.

Un redémarrage est la bonne réponse à un processus bloqué, à une connexion morte vers un serveur d’origine ou à un moteur coincé. C’est la mauvaise réponse à un défaut réseau. Si la route multicast pointe vers une interface sans porteuse, redémarrer la chaîne produit un nouveau processus qui envoie dans le même vide — et ce, toutes les quelques minutes, en remplissant le journal d’événements de redémarrage qui enfouissent la seule ligne nommant la vraie cause. Une boucle de redémarrages face à un défaut réseau est pire que le défaut lui-même, car elle détruit les preuves.

Castmux redémarre donc ce qu’un redémarrage peut raisonnablement réparer ; pour tout le reste, il s’arrête, indique ce qui ne va pas et laisse la chaîne tranquille.

Exports

Métriques OpenTelemetry

Castmux exporte ses métriques et événements via OpenTelemetry (OTLP sur gRPC) vers le collecteur de télémétrie Castmux à otel.alteox.app, port 4317. L’export est toujours actif et le collecteur est fixe : il n’est pas possible pour l’instant de le diriger vers votre propre collecteur. Chaque série est étiquetée avec le location_name et le re_seller du site, le nom d’hôte et la version logicielle de l’appareil, ainsi que le nom, le protocole, l’hôte et le port source et le moteur de chaque chaîne. Si le collecteur est injoignable, l’export échoue silencieusement et la diffusion n’est pas affectée.

Les chiffres de qualité du transport stream sont exportés par chaîne sous go_udp_channel_ts_bitrate_kbps, go_udp_channel_cbr_spread_percent, go_udp_channel_ts_continuity_errors_total, go_udp_channel_ts_transport_errors_total, go_udp_channel_ts_pcr_leaps_total, go_udp_channel_pcr_jitter_max_microseconds et go_udp_channel_pcr_violation_percent.

Événements structurés

En plus des métriques numériques, Castmux émet des événements structurés pour tout ce qui change d’état. C’est à partir d’eux que l’on reconstitue une chronologie après un incident :

moteur démarré, moteur arrêté
redémarrage lancé
sortie muette, sortie rétablie, sortie dégradée
destination non routable
émetteurs en double détectés
erreurs de transport stream (ts_quality_errors), avec les compteurs qui les ont déclenchées, au plus une fois par minute et par chaîne
arrivée de spectateurs, départ de spectateurs
réglages modifiés

Un redémarrage seul en dit peu. Un redémarrage précédé de « sortie muette » et suivi de « sortie rétablie » est un hoquet de source correctement géré ; le même redémarrage précédé de « destination non routable », c’est quelqu’un qui a redémarré une chaîne à la main face à un défaut réseau.

Journaux

Castmux écrit du JSON structuré sur stdout, qu’un collecteur de journaux de conteneurs peut ingérer sans couche d’analyse. Le même contenu est disponible par chaîne dans l’interface, dans un tampon de 1000 entrées ou 24 heures, ce qui suffit normalement à diagnostiquer une panne signalée le matin même sans accès shell à l’appareil.

Lors de l’ouverture d’un dossier de support, le journal de la chaîne concernée est la pièce jointe la plus utile. Dépannage liste les autres.

Feuille de route

Les éléments suivants sont engagés mais pas encore publiés. Ils sont listés ici pour que vous puissiez planifier en tenant compte de leur absence plutôt que de la découvrir pendant la mise en service.

Point de terminaison Prometheus prévu

Un point de terminaison de collecte (scrape) en complément de l’export OpenTelemetry, avec un tableau de bord fourni pour qu’un site n’ait pas à construire ses panneaux de zéro.

Alertes par e-mail et webhook prévu

L’envoi des conditions d’alerte ci-dessus sans pile de supervision externe intermédiaire.

Analyseur de transport stream prévu

Une analyse intégrée signalant les erreurs de compteur de continuité, les erreurs PES et le nombre de paquets embrouillés par PID — les mesures qui distinguent les pertes côté source des pertes introduites localement.

Compteur de redémarrages et rapport de disponibilité prévu

Nombre de redémarrages et disponibilité par chaîne sur une période. Aujourd’hui, la fréquence des redémarrages ne peut être retrouvée qu’en lisant les journaux, ce qui rend la question « cette chaîne se dégrade-t-elle ? » plus difficile à trancher qu’elle ne devrait l’être.