Überwachung und Metriken

Metriken pro Sender

Jeder Sender stellt die folgenden Werte in der Oberfläche und über die HTTP-API bereit.

Bitrate auf der Leitung

Die Rate der Transportstromdaten, die die Schnittstelle tatsächlich in Richtung des Ziels dieses Senders verlassen — per Paketmitschnitt gemessen, nicht von der Engine gemeldet. Das ist der eine Wert, dem Sie vertrauen können. Er ist unabhängig von der Engine und die einzige Messung, die außerhalb des Prozesses erfolgt, der den Stream erzeugt; eine Engine, die glaubt zu funktionieren, kann ihn daher nicht täuschen.

Bilder pro Sekunde

Dekodierte Bildrate. Nur Remux-Engine.

Wiedergabegeschwindigkeit

Fortschritt durch die Quelle im Verhältnis zur Echtzeit. Ein anhaltender Wert unter 1.0 bedeutet, dass der Sender nicht mithalten kann. Nur Remux-Engine.

Encoder-Bitrate

Die Rate, die die Engine nach eigener Auffassung erzeugt — im Unterschied zu der auf der Leitung beobachteten Rate. Nur Remux-Engine.

Laufzeit

Zeit seit dem Start des aktuellen Engine-Prozesses. Sie wird bei jedem Neustart zurückgesetzt; eine kurze Laufzeit bei einem Sender, den Sie nicht angefasst haben, ist daher schon für sich ein Signal.

Zuschauer

Anzahl der Fernseher, die der Zielgruppe gerade beigetreten sind, samt ihrer Adressen. Wie das gemessen wird und wann es als eingeschränkt markiert wird, steht unter On-Demand-Streaming.

Round-Trip-Zeit zur Quelle

Latenz zum Ursprungsserver. Nützlich, um „der Ursprungsserver ist langsam“ von „der Weg zum Ursprungsserver ist langsam“ zu unterscheiden.

Sender-Log

Ein Puffer pro Sender mit den letzten 1000 Einträgen oder 24 Stunden, je nachdem, was zuerst erreicht ist — lesbar in der Oberfläche, ohne Shell-Zugriff auf das Gerät.

Bauen Sie keine Alarme auf Bildrate oder Wiedergabegeschwindigkeit

Diese Werte stammen aus der Selbstauskunft der Remux-Engine. Die Pass-through-Engine dekodiert nie Video — genau darin besteht ihr Sinn —, sie liefert also weder Bildrate noch Wiedergabegeschwindigkeit. Bei solchen Sendern zeigen diese Felder n/a, und das ist der korrekte Wert, kein Fehler.

Jeder Watchdog, der sich darauf stützt, liest n/a als null und startet einen völlig gesunden Sender immer wieder neu. Das ist im Betrieb zweimal passiert, ausgelöst durch zwei verschiedene Prüfungen. Machen Sie solche Prüfungen von der verwendeten Engine abhängig, oder stützen Sie sie auf die Bitrate auf der Leitung, die es für beide gibt.

Qualität des Transportstroms

Über die Frage „verlassen Daten die Box?“ hinaus misst Castmux, ob der Transportstrom selbst intakt ist. Damit wird aus „Sender 4 bricht manchmal auf“ eine Zahl, die zeigt, ob der Schaden schon mit der Quelle ankam oder erst auf dem Weg nach draußen entstand. Die Schaltfläche Stats auf der Senderkarte stellt die letzten 30 Minuten grafisch dar. Alle Werte liefert GET /api/channels/{id}/ts-quality, und die unter OpenTelemetry aufgeführten Metriken werden exportiert.

Bitrate und CBR-Streuung

Die Rate des Transportstroms und wie stark sie in der letzten Minute schwankt. Eine große Streuung bei einem Sender, der eine konstante Rate haben sollte, sollten Sie kennen, bevor er über DVB-C ausgestrahlt wird, wo jeder Multiplex eine feste Kapazität hat.

Continuity-Fehler

Fehlende oder in falscher Reihenfolge eintreffende Pakete, erkannt am Continuity Counter jedes Pakets und summiert über die PIDs des Senders. Das ist das direkteste Maß für Verluste. Bei der Pass-through-Engine gibt es die Quelle getreu wieder. Die Remux-Engine nummeriert die Continuity Counter beim Schreiben neu, sodass Verluste vor ihr hier nicht auftauchen.

Transportfehler und Synchronisationsverluste

Pakete, die der Absender selbst als beschädigt markiert hat, und Stellen, an denen der Stream seine Paketausrichtung verloren hat. Beides ist ein Fehler vor dem Gerät.

PCR-Sprünge und PCR-Genauigkeit

PCR-Sprünge sind Sprünge in der Programmuhr. Die PCR-Genauigkeit prüft, ob jede Taktreferenz dann eintraf, wann ihr Zeitstempel es vorgibt. Eine Referenz, die weiter abweicht als ts_pcr_jitter_max_ms (standardmäßig 200 ms), zählt als Jitter-Ereignis. Diese Schwelle ist so gesetzt, dass sie Auslieferungsschübe markiert, die der Puffer eines Empfängers abfangen müsste, nicht gewöhnliches Interleaving. Die PCR-Genauigkeit wird bei SRT- und MPEG-TS-Quellen gemessen und bei Sendern der Remux-Engine auf der Leitung. Bei HLS auf der Pass-through-Engine wird sie nicht gemessen: Segmente treffen dort konstruktionsbedingt in Schüben ein, und eine Messung wäre bedeutungslos.

Verschlüsselte PIDs

Die Anzahl der PIDs des Senders, die verschlüsselte Inhalte tragen. Castmux entschlüsselt nicht; jeder Wert ungleich null bei einem Sender, der unverschlüsselt sein soll, ist daher ein Problem der Quelle.

Wie gemessen wird, hängt von der Engine ab. Ein Pass-through-Sender wird innerhalb seiner eigenen Pipeline gemessen, an der Stelle, an der der Stream auf die Leitung geht. Für einen Remux-Sender läuft ein zweiter, rein lesender Prozess, der der Multicast-Gruppe des Senders beitritt und misst, was ein Empfänger tatsächlich erhält. Keiner von beiden verändert den Stream. Die Messung ist standardmäßig aktiv und lässt sich mit ts_monitoring: false abschalten, um die geringen CPU-Kosten pro Sender zu sparen — siehe Konfiguration.

Die Zähler werden derzeit über die PIDs des Senders summiert; sie zeigen also, dass ein Sender beschädigt ist, aber nicht, ob es das Video oder eine Audiospur betrifft. Eine Aufschlüsselung pro PID steht auf der Roadmap.

Systemmetriken

Für das Gerät als Ganzes gemessen und neben der Senderliste angezeigt, weil die meisten Kapazitätsprobleme hier sichtbar werden, bevor sie pro Sender sichtbar sind:

• CPU-Auslastung. Summiert über alle Kerne.
• Speicherauslastung. Der begrenzende Faktor bei diesen Geräten. Beobachten Sie sie vor dem Hinzufügen von Sendern, nicht danach — siehe Anforderungen.
• CPU-Temperatur. Lüfterlose Boxen in Schränken verhalten sich im August anders.
• Bitrate pro Schnittstelle, eingehend und ausgehend. Eingehend zeigt, was der Uplink von Ihren Ursprungsservern bezieht; ausgehend zeigt, was an die Fernseher gesendet wird und über welche Schnittstelle — oft der schnellste Weg zu bemerken, dass es die falsche ist.

DVB-C-Metriken

Ist ein DVB-C-Modulator eingebaut, meldet jeder Multiplex seinen Betriebszustand, seine Laufzeit und einen Neustartzähler. Siehe DVB-C-Multiplexing.

Zustandsprüfungen durch Castmux

Castmux überwacht seine Sender selbst. Jeder der folgenden Zustände wird fortlaufend erkannt und hat eine feste, bewusst gewählte Reaktion.

Zustand	Bedeutung	Reaktion von Castmux
Keine Daten beim Start	Die Engine ist gestartet, hat aber noch nichts erzeugt.	Gewährt eine Karenzzeit — Kaltstarts dauern berechtigterweise einige Sekunden — und startet dann neu.
Stille mitten im Stream	Ein Sender, der Daten erzeugt hat, hat aufgehört. Meist hat ihn der Ursprungsserver fallen gelassen.	Startet neu, sobald das Stall-Timeout abgelaufen ist.
Ausgabe stumm, Prozess lebt	Die Engine läuft und hält sich für fehlerfrei, aber auf der Leitung ist nichts. Das schlimmste Fehlerbild, weil jeder interne Zähler gesund aussieht.	Startet nach mehreren Minuten bestätigter Stille neu.
Einbruch der Ausgabe	Die Bitrate auf der Leitung ist gesunken, aber nicht auf null. Kurze Einbrüche sind an Segmentgrenzen und bei Aussetzern des Ursprungsservers normal.	Wird innerhalb eines Karenzfensters toleriert, das ab dem letzten bekannt gesunden Zeitpunkt gemessen wird. Auf jeden Einbruch zu reagieren, würde Sender neu starten, die sich gleich von selbst erholt hätten.
Wiederholtes frühes Beenden	Die Engine stirbt immer wieder kurz nach dem Start. Normalerweise eine Quelle, die nicht erreichbar oder nicht verwendbar ist.	Verlängert die Wartezeit schrittweise, statt den Ursprungsserver zu bombardieren. Das Backoff wird nach einer anhaltend gesunden Laufphase zurückgesetzt, damit eine sporadisch ausfallende Quelle nicht für immer eine strafende Verzögerung ansammelt.
Ziel nicht routbar	Die Multicast-Route führt nirgendwohin, wo sie nützt. Geprüft anhand der Routing-Tabelle von außerhalb des Prozesses, weil ein Socket das nicht erkennen kann.	Nur Alarm. Nie ein Neustart. Siehe Fehlerbehebung.
Doppelte Absender	Etwas anderes sendet an dieselbe Multicast-Gruppe — häufig eine ältere Installation, die deaktiviert, aber nicht gestoppt wurde. Die Fernseher empfangen beide Streams ineinander verschachtelt und zeigen Klötzchenbildung.	Alarm. Ein Neustart würde nicht helfen, und den falschen Absender zu stoppen, ist nicht Castmux’ Entscheidung.
Verwaister Prozess	Ein Engine-Prozess, der von einem früheren Überwachungszyklus übrig geblieben ist.	Reaped.

Neu starten, was ein Neustart beheben kann; alarmieren bei allem anderen

Das ist die Regel, die die obige Tabelle abbildet, und sie verdient eine klare Formulierung, weil sie erklärt, warum einige ernste Zustände gar keinen Neustart auslösen.

Ein Neustart ist die richtige Reaktion auf einen hängenden Prozess, eine abgerissene Verbindung zum Ursprungsserver oder eine festgefahrene Engine. Er ist die falsche Reaktion auf einen Netzwerkfehler. Zeigt die Multicast-Route auf eine Schnittstelle ohne Link, erzeugt ein Neustart des Senders einen frischen Prozess, der ins selbe Nichts sendet — und das alle paar Minuten, wodurch das Log mit Neustartereignissen gefüllt wird, unter denen die eine Zeile begraben liegt, die die wahre Ursache nennt. Eine Neustartschleife gegen einen Netzwerkfehler ist schlimmer als der Fehler selbst, weil sie die Beweise vernichtet.

Deshalb startet Castmux neu, was ein Neustart plausibel beheben kann; bei allem anderen hält es an, sagt, was nicht stimmt, und lässt den Sender in Ruhe.

Exporte

OpenTelemetry-Metriken

Castmux exportiert seine Metriken und Ereignisse per OpenTelemetry (OTLP über gRPC) an den Castmux-Telemetrie-Collector unter otel.alteox.app, Port 4317. Der Export ist immer aktiv, und der Collector ist fest vorgegeben: Er kann derzeit nicht auf einen eigenen Collector umgeleitet werden. Jede Zeitreihe trägt als Labels location_name und re_seller des Standorts, Hostname und Softwareversion des Geräts sowie Name, Protokoll, Quellhost und -port und Engine jedes Senders. Ist der Collector nicht erreichbar, schlägt der Export still fehl, und das Streaming ist nicht betroffen.

Die Qualitätswerte des Transportstroms werden pro Sender exportiert als 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 und go_udp_channel_pcr_violation_percent.

Zeitreihen sind nach Sendernamen gelabelt

Das Umbenennen eines Senders beginnt eine neue Zeitreihe; die alte erhält keine Datenpunkte mehr. Benennen Sie Sender regelmäßig um, rechnen Sie in diesem Moment mit einem Bruch in den Dashboards. Löschungen werden sauber behandelt — die Zeitreihe wird beendet, statt zu veralten —, sodass das Entfernen eines Senders keine dauerhaft flache Linie in Ihren Graphen hinterlässt.

Strukturierte Ereignisse

Neben den numerischen Metriken sendet Castmux strukturierte Ereignisse für alles, was seinen Zustand ändert. Daraus bauen Sie nach einem Vorfall eine Zeitleiste auf:

• Engine gestartet, Engine beendet
• Neustart eingeleitet
• Ausgabe stumm, Ausgabe wiederhergestellt, Ausgabe eingeschränkt
• Ziel nicht routbar
• doppelte Absender erkannt
• Transportstromfehler (ts_quality_errors) mit den auslösenden Zählerständen, höchstens einmal pro Minute und Sender
• Zuschauer hinzugekommen, Zuschauer gegangen
• Einstellungen geändert

Ein Neustart allein sagt wenig. Ein Neustart, dem „Ausgabe stumm“ vorausgeht und „Ausgabe wiederhergestellt“ folgt, ist ein korrekt behandelter Aussetzer der Quelle; derselbe Neustart nach „Ziel nicht routbar“ bedeutet, dass jemand einen Sender trotz eines Netzwerkfehlers von Hand neu gestartet hat.

Logs

Castmux schreibt strukturiertes JSON auf stdout, das ein Container-Log-Collector ohne Parsing-Schicht übernehmen kann. Dieselben Informationen stehen pro Sender in der Oberfläche zur Verfügung, gepuffert auf 1000 Einträge oder 24 Stunden — normalerweise genug, um einen am Morgen gemeldeten Fehler ohne Shell-Zugriff auf das Gerät zu diagnostizieren.

Beim Eröffnen eines Supportfalls ist das Log des betroffenen Senders der mit Abstand nützlichste Anhang. Was sonst noch hilft, steht unter Fehlerbehebung.

Roadmap

Die folgenden Punkte sind fest eingeplant, aber noch nicht veröffentlicht. Sie stehen hier, damit Sie ihr Fehlen einplanen können, statt es erst bei der Inbetriebnahme zu entdecken.

Prometheus-Endpunkt geplant

Ein Scrape-Endpunkt neben dem OpenTelemetry-Export, mit einem mitgelieferten Dashboard, damit ein Standort seine Panels nicht von Grund auf bauen muss.

Alarmierung per E-Mail und Webhook geplant

Zustellung der oben genannten Alarmzustände ohne zwischengeschalteten externen Monitoring-Stack.

Transportstrom-Analysator geplant

Eingebaute Analyse, die Continuity-Counter-Fehler, PES-Fehler und die Anzahl verschlüsselter Pakete pro PID meldet — die Messungen, die Verluste auf Seiten der Quelle von lokal verursachten unterscheiden.

Neustartzähler und Verfügbarkeitsbericht geplant

Neustartzähler und Verfügbarkeit pro Sender über einen Zeitraum. Heute lässt sich die Neustarthäufigkeit nur durch Lesen der Logs ermitteln, was die Frage „wird dieser Sender schlechter?“ schwerer zu beantworten macht, als es sein sollte.