Benachrichtigungen (Alerter)¶
Der Alerter ist ein integrierter Benachrichtigungsdienst. Er überwacht den Zustand von Streams, der Node-Hardware, des DVB-Empfangs und der DVR-Aufnahme und löst Alerts (Vorfälle) aus, wenn etwas die festgelegten Grenzen überschreitet. Die Liste aktiver Alerts ist im Admin-Bereich sichtbar; in einem Netzwerk mit aktivierter domänenweiter Replikation zeigt jeder Node einen zusammengefassten Alert-Satz für die gesamte Domain.
Der Alerter funktioniert auch auf einem einzelnen Node — Meshwork wird nur für die Replikation von Alerts über die Domain benötigt.
Wie ein Alert aufgebaut ist¶
Jeder Vorfall hat eine stabile Kennung: das erneute Auftreten desselben Problems ist derselbe Vorfall, kein neuer.
Ein Vorfall durchläuft Zustände: ausgelöst (erstmals bemerkt), aktualisiert (erneut mit einer wesentlichen Änderung bemerkt), behoben (das Problem ist weg). Der aktive Satz sind die Vorfälle, die noch nicht behoben wurden.
Jeder Alert hat einen Schweregrad (in aufsteigender Reihenfolge: Information, Warnung, Fehler, kritisch, erfordert Administrator-Eingriff), einen Code (die numerische Art des Vorfalls — siehe Katalog unten), eine Quelle (Stream, Node, Storage), einen Quell-Node (wer den Alert ausgelöst hat) und einen menschenlesbaren Objektnamen.
Die meisten Alerts sind pegelbasiert: der Dienst bewertet die Bedingung periodisch neu und löst den Alert selbst aus oder behebt ihn. Ein Teil der Alerts, die einen Administrator-Eingriff erfordern, ist haftend — sie werden nicht von selbst behoben, bis die Ursache beseitigt ist (sie werden manuell behoben, siehe Alerts anzeigen und beheben).
Die Liste aktiver Alerts wird im Speicher gehalten und beim Neustart des Dienstes geleert.
Steuerung auf Stream-Ebene. Jeder Stream hat einen Schalter, der seine Alerts vollständig stummschaltet (zusammen mit den Alerts seiner Inputs und Outputs), und eine Alert-Verzögerung: eine Quelle, die sich innerhalb der festgelegten Zeit erholt, löst keinen Alert aus — das glättet kurzzeitiges Flattern.
Alerter-Einstellungen¶
Die Einstellungen befinden sich im Benachrichtigungsbereich und erfordern die Administrator-Rolle. Die genauen Felder sind im Abschnitt Weboberfläche beschrieben; nachfolgend, was konfiguriert werden kann.
Hauptschalter des Benachrichtigungsdienstes (standardmäßig aktiviert).
Domänenweite Replikation (standardmäßig aktiviert): ein Node teilt seine Alerts mit Nodes derselben Domain und empfängt deren Alerts — jeder Node zeigt einen zusammengefassten Satz. Nur wirksam, wenn eine Domain festgelegt ist.
Replikation von System-Alerts (standardmäßig deaktiviert): Alerts über die Node-Hardware (Host-CPU und -Speicher, Streamer-Prozess und Transcoder, Netzwerk- und GPU-Auslastung, Worker-Threads und das DVB-Frontend — Codes 16–23 und 40–45) sind standardmäßig lokal; aktivieren Sie dies, damit sie ebenfalls über die Domain repliziert werden. Storage-Alerts (Codes 24–25) bleiben immer lokal.
Stream-Schwellenwerte: Timeout bei fehlenden Daten (Standard 15 s), minimal zulässige Bitrate (Prüfung standardmäßig deaktiviert), Schwellenwert für Continuity-Counter-Fehler über ein 10-s-Fenster (Warn- und Fehlerpegel).
Node-Ressourcen-Schwellenwerte — Paare „Warnung / Fehler“ in Prozent für Host-CPU und -Speicher, den Streamer-Prozess und Transcoder, die Auslastung von Netzwerkschnittstelle und GPU sowie die Füllung des DVR-Storage. Die Host-Schwellenwerte sind höher angesetzt als die des Streamer-Prozesses und der Transcoder, damit eine einzelne Komponente früher warnt, als die gesamte Maschine gesättigt wird. Der Wert 0 deaktiviert den entsprechenden Pegel.
DVB-Frontend-Schwellenwerte — Signalpegel, SNR/Qualität, Bitfehlerrate und unkorrigierte Blöcke; werden auf einen Adapter angewendet, der das Signal erfasst hat (Lock).
DVR-Aufnahme-Schwellenwerte — die Anzahl aufeinanderfolgender fehlgeschlagener Schreibvorgänge, der Multiplikator für ein Aufnahme-Stocken, der Anteil der Archiv-Lücken und die Lese-/Schreibzeit der Chunks auf die Festplatte.
Katalog der Alert-Codes¶
Der Code ist die numerische Art des Vorfalls, praktisch für Gruppierung und Lokalisierung. Die Spalte „Replikation“ gibt an, ob der Alert über die Domain repliziert wird (bei aktivierter Replikation) oder für den Node lokal bleibt.
Streams: Zustand und Arbeitszyklus (Quelle — Stream)
Code |
Ereignis |
Replikation |
|---|---|---|
1 |
ein Input oder Output ist in den Fehlerzustand übergegangen |
domänenweit |
2 |
nicht behebbarer Arbeitszyklus-Fehler, manueller Reset erforderlich (erfordert Administrator-Eingriff) |
domänenweit |
3 |
ein laufender Stream liefert länger als das Timeout keine Daten |
domänenweit |
4 |
die Stream-Bitrate bleibt unter dem Minimum |
domänenweit |
13 |
der Stream ist pausiert: kein nutzbarer Input mehr vorhanden (erfordert Administrator-Eingriff) |
domänenweit |
14 |
ein Input oder Output hat sich selbst geparkt und erholt sich beim Wiederholen nicht (erfordert Administrator-Eingriff) |
domänenweit |
27 |
der Stream läuft auf dem Backup-Input — eine Umschaltung ist erfolgt |
domänenweit |
39 |
hohe CPU-Auslastung durch den Worker-Thread des Streams |
domänenweit |
Transportstrom-Konformität (TR 101 290-Analyzer) (Quelle — Stream; alle domänenweit repliziert)
Code |
Ereignis |
|---|---|
5 |
wiederholte PCR-Diskontinuitäten (TR 101 290, 2.3) |
6 |
PCR-Wiederholintervall größer als 40 ms (2.3a) |
7 |
PAT-Wiederholintervall größer als 500 ms (1.3) |
8 |
PMT-Wiederholintervall größer als 500 ms (1.5) |
9 |
PTS-Wiederholintervall größer als 700 ms (2.5) |
10 |
PCR-Genauigkeit schlechter als 500 ns (2.4) |
11 |
T-STD-Puffer-Über- oder -Unterlauf beim Video (3.3) |
12 |
PCR-Drift größer als 30 ppm (historisch: der Alert wird nicht mehr ausgelöst, die Drift wird als Metrik angezeigt — Fortlaufende Messungen) |
15 |
Continuity-Counter-Fehler über dem Schwellenwert innerhalb eines kurzen Fensters (1.4) |
46 |
CRC-Fehler in PSI-Tabellen (2.2) |
47 |
das transport_error_indicator-Flag ist gesetzt (2.1) |
48 |
Wiederholintervall der SI-Tabelle überschritten (SDT / EIT / TDT / NIT) |
49 |
Gesamturteil: der Stream entspricht nicht TR 101 290 |
Ein Teil der Analyzer-Codes erscheint nur bei aktivierten Analyseoptionen (Tiefenanalyse, Analyse von PTS-Diskontinuitäten, Analyse des T-STD-Puffers) und gilt nur für Streams mit konstanter Bitrate; das Gesamturteil (49) wird nur bei zuverlässig konstanter Bitrate gefällt. Näheres im Abschnitt Analysator.
Node-Ressourcen und -Hardware (Quelle — System)
Code |
Ereignis |
|---|---|
16 |
Host-CPU-Auslastung über dem Schwellenwert |
17 |
Host-Speichernutzung über dem Schwellenwert |
18 |
CPU des Streamer-Prozesses über dem Schwellenwert |
19 |
Speicher des Streamer-Prozesses über dem Schwellenwert |
20 |
Gesamt-CPU der Transcoder über dem Schwellenwert |
21 |
Gesamtspeicher der Transcoder über dem Schwellenwert |
22 |
Auslastung der Netzwerkschnittstelle über dem Schwellenwert (pro Schnittstelle) |
23 |
GPU-Auslastung über dem Schwellenwert (pro Gerät) |
24 |
DVR-Storage-Füllung über dem Schwellenwert (pro Storage) |
25 |
das Dateisystem des DVR-Storage ist nicht verfügbar (erfordert Administrator-Eingriff) |
40 |
hohe CPU-Auslastung durch den Worker-Thread des DVB-Adapters |
41 |
das DVB-Frontend hat das Signal (lock) verloren |
42 |
DVB-Signalpegel unter dem Schwellenwert |
43 |
SNR/Qualität des DVB-Signals unter dem Schwellenwert |
44 |
DVB-Bitfehlerrate (BER) über dem Schwellenwert |
45 |
unkorrigierte DVB-Blöcke über dem Schwellenwert |
Alle Alerts dieser Gruppe sind standardmäßig lokal. Die Codes 16–23 und 40–45 können mit dem Schalter für die Replikation von System-Alerts über die Domain repliziert werden; die Codes 24–25 bleiben immer lokal. Die Schwellenwert-Alerts des DVB-Frontends (42–45) werden nur auf einem Adapter ausgewertet, der das Signal erfasst hat; der Code 41 wird beim Verlust des Locks ausgelöst. BER (44) ist standardmäßig deaktiviert, da die Rohskala vom Empfänger abhängt (siehe DVB-Empfänger).
Meshwork und Lebenszyklus (Quelle — Netzwerk/System; lokal)
Code |
Ereignis |
|---|---|
26 |
ein Netzwerk-Node ist verstummt — bestätigt die Verbindung nicht mehr |
28 |
der Streamer-Prozess hat den Start abgeschlossen (kurzlebige Benachrichtigung) |
37 |
zwei Nodes mit demselben Namen in einer Domain (erfordert Administrator-Eingriff) |
DVR-Aufnahme-Gesundheit (Quelle — Stream; lokal)
Code |
Ereignis |
|---|---|
29 |
DVR-Segment- oder Index-Schreibvorgänge schlagen fehl — das Archiv wird nicht geschrieben |
30 |
die DVR-Aufnahme ist ins Stocken geraten: Input ist vorhanden, aber ein neues Segment wird lange nicht gespeichert |
31 |
das DVR-Archiv ist beeinträchtigt — Lücken in der jüngsten Abdeckung |
32 |
der Index des DVR-Archivs ist beschädigt (erfordert Administrator-Eingriff) |
50 |
hohe Lese-/Schreibzeit von DVR-Chunks auf die Festplatte |
Konfiguration, Transcoder, OTT und Zertifikate (Quelle — System/Stream)
Code |
Ereignis |
Replikation |
|---|---|---|
33 |
die Hauptkonfiguration konnte beim Start nicht geladen werden, der Dienst startete mit der Ersatzkonfiguration (erfordert Administrator-Eingriff) |
domänenweit |
34 |
im low-latency HLS/DASH-Modus wurden Audiospuren in einem nicht unterstützten Codec verworfen (unterstützt werden AAC und AC-3) |
domänenweit |
35 |
das HTTPS-Zertifikat konnte über den integrierten ACME-Client nicht ausgestellt oder erneuert werden |
domänenweit |
36 |
ein konfigurierter Transcoder konnte beim Start nicht geladen werden — keine ausführbare Datei oder kein Gerät (erfordert Administrator-Eingriff) |
domänenweit |
38 |
der Stream erfordert einen Transcoder (Software, NVIDIA oder Intel VPL), der auf diesem Node nicht verfügbar ist (erfordert Administrator-Eingriff) |
lokal |
Conditional-Access-Modul (CI/CAM, EN 50221) (Quelle — System; lokal)
Code |
Ereignis |
|---|---|
51 |
das CAM-Modul wurde entfernt (erfordert Administrator-Eingriff) |
52 |
kein Abonnement: das Modul meldet, dass das Programm nicht bezahlt ist |
53 |
CI/CA-Fehler — ein nicht behebbarer Kanal- oder Conditional-Access-Fehler |
Alerts anzeigen und beheben¶
Der Admin-Bereich hat einen Benachrichtigungsabschnitt mit einer Liste von Alerts. Er kann nach Satz (nur aktive / nur behobene / alle), nach Schweregrad, nach Quelltyp und -kennung, nach Code, nach Domain und nach Zeit gefiltert werden, außerdem kann nach Nachrichtentext gesucht werden. Standardmäßig werden sowohl aktive als auch kürzlich behobene Einträge angezeigt (das Übergangsprotokoll), daher kann die Gesamtzahl der Zeilen die Zahl der aktiven Vorfälle übersteigen — für den aktuellen aktiven Satz wählen Sie den Modus „nur aktive“.
Sie müssen den Zustand nicht manuell abfragen: der Admin-Bereich empfängt Änderungen am aktiven Satz in Echtzeit und aktualisiert die Liste selbst, sobald ein Alert ausgelöst, aktualisiert oder behoben wird.
Pegelbasierte Alerts werden automatisch behoben, wenn die Bedingung verschwindet. Haftende Alerts, die einen Administrator-Eingriff erfordern (zum Beispiel ein Fehler beim Laden der Konfiguration, Nichtverfügbarkeit des Storage, ein harter Arbeitszyklus-Fehler), werden nicht von selbst behoben: nach Beseitigung der Ursache wird ein solcher Vorfall manuell behoben (bestätigt). Das Beheben wirkt auf dem Node, der den Alert ausgelöst hat: wenn Sie im Netzwerk einen fremden (domänenweit replizierten) Vorfall sehen, müssen Sie ihn auf dem Quell-Node beheben (er ist in der Zeile angegeben).
Domänenweite Replikation von Benachrichtigungen¶
Bei aktivierter Replikation und festgelegter Domain zeigt jeder Node einen zusammengefassten aktiven Satz für die gesamte Domain: die eigenen Alerts des Nodes plus die Alerts der Peers derselben Domain. Jede Zeile gibt den Quell-Node an, sodass ersichtlich ist, auf welchem Node genau das Problem aufgetreten ist.
Domänenweit repliziert: Stream-Alerts und Transportstrom-Konformitäts-Alerts, Umschaltung auf den Backup-Input, Lade-Fehler von Konfiguration und Transcoder, OTT-Audio-Verwerfung, ACME-Zertifikatsfehler.
Bleiben lokal: Ressourcen-Alerts über Hardware und Storage, „Node verstummt“, Kollision von Node-Namen, Benachrichtigung über den Dienststart, Alerts zur DVR-Aufnahme-Gesundheit und Alerts des Conditional-Access-Moduls. System-Hardware-Alerts (Codes 16–23 und 40–45) können mit dem Schalter für die Replikation von System-Alerts auf Replikation umgestellt werden.
Den Alert „Netzwerk-Node verstummt“ löst jeder Node selbstständig über den Peer aus, der aufgehört hat zu antworten — daher lösen die Peers eines einzelnen ausgefallenen Nodes einen solchen Alert unabhängig voneinander aus.
Externe Alert-Zustellung¶
Neben der Liste im Browser können Alerts an einen externen Befehl, in einen Telegram-Chat und per E-Mail (SMTP) zugestellt werden. Jeder Kanal ist unabhängig und standardmäßig deaktiviert und führt die Zustellung auf einem eigenen Hintergrund-Thread durch, sodass ein langsamer oder nicht erreichbarer Empfänger die anderen Kanäle und den Dienst selbst nicht aufhält.
Jeder Kanal hat einen Mindest-Schweregrad für die Zustellung (standardmäßig Warnung): jeder auf dem Node sichtbare Alert (eigener oder domänenweit replizierter) ab diesem Pegel wird zugestellt, und zwar sowohl beim Auslösen als auch beim Beheben. Die Verbindungsparameter jedes Kanals sind im Abschnitt Weboberfläche beschrieben.
Typische Probleme¶
Alerts der Peers sind nicht sichtbar. Prüfen Sie, dass auf den Nodes die domänenweite Replikation aktiviert und eine gemeinsame Domain festgelegt ist. System-Hardware-Alerts sind standardmäßig lokal — aktivieren Sie die Replikation von System-Alerts, wenn Sie diese ebenfalls domänenweit sehen möchten.
Ein haftender Alert verschwindet nicht, nachdem die Ursache beseitigt wurde. Beheben Sie ihn manuell auf dem Quell-Node.
