Benachrichtigungen (Alerter)

Der Alerter ist ein integrierter Benachrichtigungsdienst. Er überwacht den Zustand von Streams, der Knoten-Hardware, des DVB-Empfangs und der DVR-Aufnahme und löst Alarme (Vorfälle) aus, wenn etwas die festgelegten Grenzen überschreitet. Die Liste aktiver Alarme ist im Admin-Bereich sichtbar, und in einem Netzwerk mit aktivierter domänenweiter Replikation zeigt jeder Knoten einen zusammengefassten Alarmsatz für die gesamte Domäne.

Der Alerter funktioniert auch auf einem einzelnen Knoten — Meshwork wird nur für die Replikation von Alarmen über die Domäne benötigt.

Wie ein Alarm 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 Alarm 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, Knoten, Storage), einen Quellknoten (wer den Alarm ausgelöst hat) und einen menschenlesbaren Objektnamen.

• Der Schweregrad ist einem Vorfall nicht für immer zugeordnet. Solange der Vorfall offen ist, bewertet der Dienst ihn zusammen mit den übrigen Prüfungen neu (etwa alle 5 Sekunden) und versetzt ihn bei einer Änderung in den Zustand „aktualisiert“ — mit derselben Kennung, daher erscheint keine zweite Zeile in der Liste, sondern die Liste wird neu sortiert. An externe Empfänger wird eine solche Änderung nicht gesendet: Eine Neubewertung soll nicht zu einer E-Mail oder einer Chat-Nachricht werden.

• Die meisten Alarme sind pegelbasiert: Der Dienst bewertet die Bedingung periodisch neu und löst den Alarm selbst aus oder behebt ihn. Ein Teil der Alarme, die einen Administrator-Eingriff erfordern, ist haftend: Eine kurzzeitige Erholung behebt sie nicht. Manche werden erst dann von selbst behoben, wenn die Ursache tatsächlich beseitigt ist, andere bleiben bis zur manuellen Behebung bestehen (siehe Alarme anzeigen und beheben).

Die Liste aktiver Alarme wird im Speicher gehalten und beim Neustart des Dienstes geleert.

Steuerung auf Streamebene. Jeder Stream hat einen Schalter, der seine Alarme vollständig stummschaltet (zusammen mit den Alarmen seiner Eingänge und Ausgänge), sowie eine Alarmverzögerung: Eine Quelle, die sich innerhalb der eingestellten Zeit erholt, löst keinen Alarm aus — das glättet kurzzeitiges Flackern. Dieselbe Verzögerung schluckt auch einen kurzen Ausfall des Haupteingangs: Hat der Stream es geschafft, vor ihrem Ablauf auf eine Reserve zu wechseln, gibt es überhaupt keinen Alarm über einen Eingangsfehler. Über die Umschaltung berichtet der Alarm über den Betrieb auf der Reserve (Code 27), den dieselbe Verzögerung aufschiebt. Die Schwelle für fehlende Daten eines Streams wird gesondert gezählt und von der Verzögerung nicht zurückgehalten, sie kann daher auch früher ansprechen.

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). Ein abgeschalteter Alerter verstummt vollständig. Der Knoten löst keine eigenen Alarme aus und sendet nichts an externe Ziele — weder eigene Alarme noch die von benachbarten Knoten domänenweit replizierten.

• Domänenweite Replikation (standardmäßig aktiviert): Ein Knoten teilt seine Alarme mit Knoten derselben Domäne und empfängt deren Alarme; jeder Knoten zeigt einen zusammengefassten Satz. Nur wirksam, wenn eine Domäne festgelegt ist. Eine super-node nimmt in einer zusätzlichen Domäne Alarme nur von den Nachbarn aus ihrer Liste an und löst über andere Knoten dieser Domäne keinen Alarm mit Code 26 aus — deren Zustand ist auf der Netzwerkkarte sichtbar.

• Replikation von System-Alarmen (standardmäßig deaktiviert): Alarme über die Knoten-Hardware (Host-CPU und -Speicher, Streamer-Prozess und Transcoder, Netzwerk- und GPU-Auslastung, Belegung des GPU-Videospeichers, Worker-Threads und das DVB-Frontend — Codes 16–23, 40–45 und 64) sind standardmäßig lokal; aktivieren Sie dies, damit sie ebenfalls über die Domäne repliziert werden. Storage-Alarme (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).

• Reserve-Eingänge und Resynchronisation (seit Version 2.0.2.420; die Blöcke „Eingangs-Resync (Codes 58, 59, 61)“ und „Backup-Eingänge (Code 65)“ auf dem Bildschirm Alarmierung): der Alarm über eine defekte Reserve (Code 65) und die Frist, nach der ein nicht mehr geprüfter Reserve-Eingang aus seiner Liste fällt; die Schwellenwerte der Codes 58, 59 und 61 (der Schwellenwert für 61 ist standardmäßig aus) und die Zahl ruhiger Stunden, bis sie behoben werden (Katalog der Alarmcodes).

• Haltezeit des CC-Fehler-Alarms (Code 15, seit Version 2.0.2.417). Der Alarm wird erst ausgelöst oder auf einen höheren Pegel gesetzt, wenn die Verluste 30 Sekunden lang andauern; kurze Pausen zwischen den Verlusten setzen die Zählung nicht zurück. Behoben wird er nach 60 Sekunden ohne Verluste. Der Fehlerpegel bleibt bestehen, bis die Anzahl der Fehler im Fenster unter die Hälfte des Fehler-Schwellenwerts fällt. Ein einzelnes verlorenes Paket erzeugt deshalb keinen Alarm, und eine Quelle, die ständig Pakete verliert, erzeugt einen stabilen Alarm statt einer Folge von Auslösungen und Behebungen. Die Zeiten werden auf dem Bildschirm Alarmierung oder mit den Schlüsseln stream-cc-raise-sec und stream-cc-clear-sec im Abschnitt alerter der Konfigurationsdatei festgelegt (Die Einstellungsdatei pss.json): von 0 bis 3600 Sekunden; 0 bedeutet sofort, wie in früheren Versionen. Die Prüfung nach TR 101 290 (1.4 und Gesamturteil, Code 49) ändert sich nicht.

• Knoten-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. Die Schwellenwerte für die Belegung des Videospeichers von NVIDIA-GPUs (Code 64) sind die Zeile „GPU-Videospeicher“, standardmäßig 85 % und 95 % (Schlüssel gpu-mem-warning-pct und gpu-mem-error-pct im Abschnitt alerter der Konfigurationsdatei, Die Einstellungsdatei pss.json).

• Haltezeit der System-Alarme (seit Version 2.0.2.416). Ein Alarm zu den Ressourcen des Knotens (Codes 16–24, 40 und 64) wird erst ausgelöst oder auf einen höheren Pegel gesetzt, wenn der Wert 30 Sekunden lang jenseits des Schwellenwerts bleibt. Herabgestuft oder behoben wird er, wenn der Wert 60 Sekunden lang unter dem Schwellenwert bleibt. Eine Last, die von Messung zu Messung über den Schwellenwert springt, erzeugt deshalb keine Alarme, die binnen Sekunden erscheinen und wieder verschwinden. Die Zeiten werden auf dem Bildschirm Alarmierung oder mit den Schlüsseln system-alert-raise-sec und system-alert-clear-sec im Abschnitt alerter der Konfigurationsdatei festgelegt: von 0 bis 3600 Sekunden; 0 bedeutet sofort, wie in früheren Versionen.

• 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 Alarmcodes

Der Code ist die numerische Art des Vorfalls, praktisch für Gruppierung und Lokalisierung. Die Spalte „Replikation“ gibt an, ob der Alarm über die Domäne repliziert wird (bei aktivierter Replikation) oder für den Knoten 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 gestoppt und wartet auf einen Administrator-Eingriff: kein nutzbarer Input mehr vorhanden (keine Inputs oder alle pausiert)	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 Reserve-Input — eine Umschaltung ist erfolgt	domänenweit
39	hohe CPU-Auslastung durch den Worker-Thread des Streams	domänenweit
58	ein PCR-Sprung der Quelle über das Diskontinuitätsfenster hinaus hat die Ausgabe unterbrochen — das Angesammelte wurde verworfen	domänenweit
59	die Ausgabe wurde auf die Echtzeit neu synchronisiert: Die Zuführung hält die eingestellte Verzögerung nicht durch	domänenweit
60	einem laufenden Stream ist kein zuführender Eingang mehr geblieben	domänenweit
61	ein PCR-Sprung der Quelle über das Diskontinuitätsfenster hinaus ging ohne Verluste ab	domänenweit
62	ein separates CI-Modul, an das der Eingang den Stream übergibt, ist nicht erreichbar oder liefert keine Pakete mehr zurück: Der Eingang gibt den Stream ohne Entschlüsselung weiter	domänenweit
65	während der Stream über einen Eingang läuft, sind seine anderen Eingänge im Fehlerzustand — die Reserve ist defekt (seit Version 2.0.2.420)	domänenweit

Seit Version 2.0.2.420 ist ein Alarm mit Code 1 immer kritisch: Er bedeutet, dass der Stream seine Quelle oder seine Auslieferung verloren hat. Ein ausgefallener Ausgang erhält ihn immer — hinter einem Ausgang steht keine Reserve. Ein ausgefallener Eingang erhält ihn nur, wenn der Stream gerade über ihn läuft oder noch kein aktiver Eingang vorhanden ist. Eingänge, die ausgefallen sind, während der Stream über einen anderen Eingang läuft, erhalten keinen eigenen Alarm mit Code 1: Sobald der Stream einen anderen Eingang übernommen hat, werden ihre Zeilen aufgehoben, und die defekte Reserve beschreibt ein einziger Alarm mit Code 65 pro Stream. So färbt eine defekte Reserve einen gesunden Stream nicht kritisch. Vor Version 2.0.2.420 hielt jeder solche Eingang eine eigene Zeile mit Code 1 und der Stufe „Fehler“, und ein externes Ziel erhielt ihre Aktualisierung von „kritisch“ auf „Fehler“; jetzt erhält es die Aufhebung der Zeile mit Code 1 und das Auslösen von Code 65. Der Grund, aus dem der Stream einen Eingang verlassen hat, bleibt in der Oberfläche als Historie sichtbar (Quellenredundanz).

Ein Alarm mit Code 65 (Stufe „Warnung“) listet die defekten Eingänge des Streams in der Reihenfolge der Reservierung auf, jeden mit seinem letzten Fehler: höchstens fünf, danach, wie viele es noch sind. Das sind sowohl ein ausgefallener Haupteingang, während der Stream über eine Reserve läuft, als auch ein Reserve-Eingang, der bei einem Umschaltversuch nicht hochgekommen ist. Der Alarm wird nach der Alarmverzögerung des Streams ausgelöst und erst, wenn der Stream bereits stabil über ein und denselben Eingang läuft; eine geänderte Liste überschreibt die Meldung erst, wenn sie mindestens eine Minute bestanden hat (oder die Alarmverzögerung des Streams, falls diese länger ist). Solange der Stream über keinen Eingang läuft, ändert sich der Alarm nicht: Die Störung beschreiben die Codes 60 und 1. Der Alarm wird aufgehoben, wenn keine defekten Eingänge mehr übrig sind — der Eingang hat sich erholt oder wurde pausiert, der Stream ist zu ihm zurückgekehrt —, sowie beim Stoppen, Pausieren oder Löschen des Streams. Ein Reserve-Eingang, der in der Reihenfolge unter dem aktiven steht, wird während des Streambetriebs nicht mehr geprüft; deshalb fällt er einen Tag nach seinem letzten Fehler aus der Liste. Die Frist legt der Schlüssel stream-backup-input-max-age-min des Abschnitts alerter der Einstellungsdatei fest (in Minuten, Standard 1440, 0 — nie nach Frist ausblenden), auf dem Bildschirm Alarmierung das Feld „Fehler eines Backup-Eingangs vergessen nach, min“; der Schlüssel stream-backup-input-alert schaltet den Alarm ab (standardmäßig an), auf dem Bildschirm der Schalter „Bei fehlerhaften Backup-Eingängen warnen“. Ein Eingang über dem aktiven wird ständig geprüft und bleibt in der Liste, bis er sich erholt.

Code 60 beschreibt den Stream als Ganzes und nicht einen einzelnen Punkt: Er hält an, solange bei einem laufenden Stream kein einziger Eingang Daten liefert, und übersteht beliebig viele Umschaltungen auf die Reserve. Code 1 dagegen ist stets an einen bestimmten Eingang oder Ausgang gebunden und zerfällt bei einem Stream mit Reservierung deshalb in mehrere kurzlebige Vorfälle. Die Bedingung muss fünfzehn Sekunden anhalten, daher lösen der Start des Knotens und das Anwenden von Einstellungen, bei denen die Eingänge für einen Augenblick keine Daten liefern, Code 60 nicht aus. Nicht darunter fallen ein pausierter Stream und ein Stream, der stehen geblieben ist und auf einen Administrator-Eingriff wartet: Diesen Zustand beschreiben die Codes 13 und 14.

Die Codes 58, 59 und 61 bedeuten eine Empfehlung zu den Synchronisationseinstellungen des Eingangs und keinen Bericht über eine einmalige Störung: Der Knoten zählt solche Ereignisse in einem gleitenden Fenster von einer Stunde und löst einen Vorfall aus, sobald es mehr als der Schwellenwert werden. Unterschieden sind sie nach dem Preis für den Empfänger. Code 58 ist ein PCR-Sprung der Quelle, der Inhalt gekostet hat: Der Synchronisationspuffer wurde verworfen, die Ausgabe unterbrochen; die Meldung nennt, wie viel des angesammelten Streams der letzte solche Fall verworfen hat. Code 61 ist derselbe Bruch der Quell-Zeitachse, nur verlustfrei durchgeführt. Seit Version 2.0.2.420 hat Code 61 die Stufe „Information“ (zuvor „Warnung“; mit dem Standard-Schwellenwert der externen Ziele gelangt er nicht dorthin) und ist standardmäßig aus: Seinen Schwellenwert legt ein eigener Schlüssel stream-sync-absorbed-count des Abschnitts alerter fest (von 0 bis 256, 0 — aus), und der Schlüssel stream-sync-gap-count gilt jetzt nur für Code 58. Ereignisse werden auch bei abgeschaltetem Alarm gezählt, daher bewertet das Einschalten sofort die angesammelte Historie. Code 59 betrifft die Quelle überhaupt nicht: Der Synchronisationspuffer lief leer, das heißt, die Zuführung hält die eingestellte Verzögerung nicht durch. Abhilfe schafft ein größerer Puffer (Synchronisation), bei einem Transcoder-Eingang zusätzlich die Glättung der Bitrate am übergeordneten Stream. Alle drei sind haftend: Ein erneutes Verbinden des Eingangs behebt sie nicht. Der Vorfall behebt sich selbst, sobald eine der Synchronisationseinstellungen des Eingangs oder des Streams geändert wird (die geänderte Einstellung wird neu bewertet), oder wenn die Zahl der Ereignisse zwei Stundenfenster in Folge unter dem Schwellenwert bleibt. Die Zahl der Fenster legt der Schlüssel stream-sync-quiet-clear-windows des Abschnitts alerter fest (von 1 bis 24, Standard 2); vor Version 2.0.2.420 waren sechs Stunden ohne ein einziges Ereignis nötig, und eine Quelle mit ein bis zwei Brüchen pro Stunde hielt die Zeile endlos. Seit Version 2.0.2.420 wird auch die Zeile des Eingangs aufgehoben, von dem der Stream auf einen anderen Eingang umgeschaltet hat, sowie die Zeile eines pausierten Streams. Ein gestoppter Stream behält den Vorfall: Die Empfehlung bleibt bestehen.

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

Knoten-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
63	das DVB-Frontend hält den Lock, der Multiplex wird aber nicht empfangen: Die PAT lässt sich 20 Sekunden lang nicht auswerten, drei Neuabstimmungen in Folge
64	Belegung des Videospeichers einer NVIDIA-GPU über dem Schwellenwert (pro Gerät)

Alle Alarme dieser Gruppe sind standardmäßig lokal. Die Codes 16–23, 40–45 und 64 können mit dem Schalter für die Replikation von System-Alarmen über die Domäne repliziert werden; die Codes 24–25 und 63 bleiben immer lokal. Die Schwellenwert-Alarme 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). Der Code 63 wird nur bei einem Adapter ausgelöst, an den Streams angeschlossen sind, und die Signalwerte können dabei im Normalbereich bleiben. Nach der dritten Neuabstimmung wiederholt der Adapter den Versuch alle fünf Minuten; der Alarm wird behoben, sobald sich die PAT auswerten lässt.

Code 23 überwacht die GPU-Auslastung, Code 64 dagegen, wie viel Videospeicher der Karte belegt ist. Eine Karte mit vollem Videospeicher kann keinen neuen Transcoder-Kanal starten, obwohl ihre Auslastung dabei normal aussehen kann. Code 64 wird nur für NVIDIA-Karten ausgelöst, die die Speicherbelegung melden; für Intel-GPUs gibt es ihn nicht. Meldet eine Karte die Belegung nicht mehr, wird der Alarm behoben. Ein Knoten einer früheren Version (vor 2.0.2.416) zeigt einen über die Domäne replizierten Alarm mit Code 64 ohne Namen an, bis er aktualisiert wird.

Meshwork und Lebenszyklus (Quelle — Netzwerk/System; lokal)

Code	Ereignis
26	ein Netzwerkknoten ist verstummt — bestätigt die Verbindung nicht mehr
28	der Streamer-Prozess hat den Start abgeschlossen (kurzlebige Benachrichtigung)
37	zwei Knoten mit demselben Namen in einer Domäne (erfordert Administrator-Eingriff)

Seit Version 2.0.2.417 wird der Alarm mit Code 26 erst ausgelöst, wenn der Knoten länger als eine Minute schweigt, obwohl er auf der Netzwerkkarte schon nach 15 Sekunden als nicht erreichbar markiert wird. Ein kurzer Neustart eines Nachbarn löst daher keinen Alarm aus. Die Verzögerung legt das Feld „Node-down-Alarm nach, s“ im Block „Meshwork-Kontakt (erweitert)“ der Servereinstellungen fest (Server-Einstellungen), in der Einstellungsdatei der Parameter cluster-node-down-sec im Abschnitt cluster (Die Einstellungsdatei pss.json): standardmäßig 60 Sekunden, von 0 bis 3600; kürzer als 15 Sekunden ist sie nie.

Ein Knoten, der absichtlich gestoppt oder neu gestartet wird (Stoppen oder Neustarten des Dienstes, Aktion „Jetzt neu starten“ im Admin-Bereich, Wiederherstellen der Konfiguration, Aktualisieren der Lizenz), teilt dies zuerst seinen Nachbarn mit. Die Nachbarn lösen 5 Minuten lang keinen Alarm mit Code 26 für ihn aus, und in der Knotentabelle wird er als „Neustart (N s)“ geführt (Knoten); ist der Knoten bis dahin nicht zurückgekehrt, wird der Alarm wie gewohnt ausgelöst. Die Frist legt das Feld „Karenz bei geplantem Stopp, s“ desselben Blocks fest, in der Einstellungsdatei der Parameter cluster-leave-grace-sec desselben Abschnitts: standardmäßig 300 Sekunden, von 0 bis 86400. Die Mitteilung erhalten die Nachbarn, zu denen der Knoten selbst eine Verbindung aufbaut; ein Nachbar, der sich nur mit ihm verbindet (zum Beispiel ein Knoten hinter NAT), erhält sie nicht, und für ihn gilt die übliche Verzögerung. Knoten mit Versionen vor 2.0.2.417 berücksichtigen die Mitteilung nicht. Ab Version 2.0.2.420 warnt ein Knoten nur Nachbarn der Version 2.0.2.417 und neuer (sowie solche, deren Version noch unbekannt ist), und zwar alle gleichzeitig; daher dauert das Stoppen des Dienstes in einem Netz mit älteren Knoten etwa 3 Sekunden weniger. Ein Stopp des Dienstes wegen der Lizenz (abgelaufen, nicht echt oder abgelehnt) warnt die Nachbarn nicht vor.

Der Alarm mit Code 26 hält sich die ganze Zeit, in der der Knoten als nicht erreichbar geführt wird — bis zu einer Woche (Netzwerkkarte). Er wird von selbst behoben, wenn der Knoten wieder in Verbindung tritt, und verschwindet zusammen mit der Zeile des Knotens, wenn ein nicht erreichbarer Knoten manuell entfernt wurde.

Zustand der DVR-Aufnahme (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 und wird nicht neu erstellt — Festplattenfehler (erfordert Administrator-Eingriff); einzelne beschädigte Indexeinträge werden ohne diesen Alarm übersprungen
50	hohe Lese-/Schreibzeit von DVR-Chunks auf die Festplatte

Konfiguration, Transcoder, OTT, Zertifikate und Lizenz (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 Knoten nicht verfügbar ist (erfordert Administrator-Eingriff)	lokal
55	die Lizenz des Knotens läuft ab: eine Warnung zwei Wochen vor dem Ende der Frist, nach deren Eintritt — erfordert Administrator-Eingriff, und der Knoten startet den Dienst neu; der Dienst startet nicht wieder, solange auf dem Knoten keine gültige Lizenz vorliegt	domänenweit
56	die Lizenz des Knotens wurde als nicht echt erkannt (erfordert Administrator-Eingriff): Der Knoten startet den Dienst neu, und der Start wird abgelehnt — der Dienst bleibt gestoppt, bis auf dem Knoten eine echte Lizenz vorliegt und er erneut gestartet wird	domänenweit
57	die Lizenz des Knotens ist echt, gehört aber zu einer Generation, die diese Version nicht mehr annimmt (erfordert Administrator-Eingriff): Die Frist ist nicht abgelaufen und es liegt keine Fälschung vor — Generation 2 wird nur als befristete Testlizenz angenommen, deshalb wird eine unbefristete dieser Generation sofort abgelehnt	domänenweit

Der Alarm mit Code 35 wird bei der nächsten erfolgreichen Ausstellung eines Zertifikats von selbst behoben, außerdem beim Ausschalten der automatischen Ausstellung. Seit Version 2.0.2.417 wird ein Alarm über ein Problem des Knotens selbst (kein HTTPS-Server mit dem Hostnamen, Port der HTTP-01-Prüfung belegt, Fehler des ACME-Kontoschlüssels) behoben, sobald der nächste Ausstellungsversuch diesen Schritt besteht; bisher hielt er sich bis zum Ausschalten der automatischen Ausstellung (HTTPS-Zertifikate).

Entschlüsselung: Conditional-Access-Modul (CI/CAM, EN 50221) und BISS (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
54	die Entschlüsselung gelingt nicht: Ein Programm mit dem gesetzten BISS-Schlüssel oder ein dem CAM zugewiesenes Programm bleibt verschlüsselt

Ein separates CI-Modul, an das der Eingang den Stream übergibt (CI/CAM am Eingang eines Streams), meldet einen Ausfall mit dem Stream-Code 62 und nicht mit den Codes dieser Gruppe. Auf einen Eingang entfällt ein solcher Alarm, auch wenn der Eingang mehrere Slots belegt. Behoben wird er, wenn das Modul wieder 30 Sekunden lang antwortet, wenn das Modul vom Eingang entfernt wird oder wenn der Eingang gelöscht wird. Ein Modul, das antwortet, aber nichts entschlüsselt, löst diesen Alarm nicht aus.

Alarme anzeigen und beheben

Der Admin-Bereich hat einen Benachrichtigungsabschnitt mit einer Liste von Alarmen. Er kann nach Satz (nur aktive / nur behobene / alle), nach Schweregrad, nach Quelltyp und -kennung, nach Code, nach Domäne 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 Alarm ausgelöst, aktualisiert oder behoben wird.

Pegelbasierte Alarme werden automatisch behoben, wenn die Bedingung verschwindet. Haftende Alarme, 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 Knoten, der den Alarm ausgelöst hat: Wenn Sie im Netzwerk einen fremden (domänenweit replizierten) Vorfall sehen, müssen Sie ihn auf dem Quellknoten beheben (er ist in der Zeile angegeben). Verstummt die Quelle, entfernen die Nachbarn ihre Zeilen etwa fünfundvierzig Sekunden nach deren letzter Meldung aus ihrer zusammenfassenden Liste. Das ist keine Behebung des Vorfalls, sondern das Entfernen der Kopie: Bei der Quelle selbst bleibt der Vorfall bestehen, und wenn sich der Knoten wieder meldet, kehren die dort nicht behobenen Zeilen in die Liste zurück. So verschwindet aus der zusammenfassenden Liste auch der Alarm über die abgelaufene Lizenz eines gestoppten Knotens — an der Quelle lässt er sich nicht beheben, weil der Dienst dort nicht läuft.

Einen Vorfall, der immer wieder ausgelöst und behoben wird, löscht der Knoten nicht mehr sofort. Nach drei abgeschlossenen Zyklen „Auslösen — Beheben“, die höchstens zehn Minuten auseinanderliegen, werden die Behebungen zurückgehalten: Die Zeile bleibt im aktiven Satz, und eine einzige echte Behebung geht erst hinaus, nachdem die Bedingung mindestens so lange behoben geblieben ist wie die Serie selbst dauerte (standardmäßig dieselben zehn Minuten). Ein erneutes Auslösen bricht den Countdown ab, und die Serie liest sich als ein durchgehender Vorfall statt als ein Dutzend kurzer. Eine erste oder seltene Erholung wird sofort gelöscht, während eine manuelle Behebung, das Löschen des Streams, das Abschalten der Alarme am Stream und das Abschalten des Dienstes selbst die Haltezeit umgehen. Der Mechanismus ist standardmäßig eingeschaltet und wird vor allem für die externe Zustellung gebraucht: Ohne ihn würde eine flatternde Bedingung den Empfängern ein paar Meldungen pro Zyklus schicken.

Domänenweite Replikation von Benachrichtigungen

Bei aktivierter Replikation und festgelegter Domäne zeigt jeder Knoten einen zusammengefassten aktiven Satz für die gesamte Domäne: die eigenen Alarme des Knotens plus die Alarme der Nachbarn derselben Domäne. Jede Zeile gibt den Quellknoten an, sodass ersichtlich ist, auf welchem Knoten genau das Problem aufgetreten ist.

• Domänenweit repliziert: Stream-Alarme und Transportstrom-Konformitäts-Alarme, Umschaltung auf den Reserve-Input, Ladefehler von Konfiguration und Transcoder, OTT-Audio-Verwerfung, ACME-Zertifikatsfehler, Ablauf der Lizenz, die Erkennung einer Lizenz als nicht echt und eine Lizenz einer Generation, die diese Version nicht mehr annimmt.

• Bleiben lokal: Ressourcenalarme zu Hardware und Storage, „Knoten verstummt“, Kollision von Knotennamen, Benachrichtigung über den Dienststart, Alarme zum Zustand der DVR-Aufnahme, die Anforderung eines auf dem Knoten nicht verfügbaren Transcoders, Alarme des Conditional-Access-Moduls und die fehlgeschlagene Entschlüsselung, der Verlust des Multiplexes bei bestehendem DVB-Lock (Code 63). System-Hardware-Alarme (Codes 16–23 und 40–45) können mit dem Schalter für die Replikation von System-Alarmen auf Replikation umgestellt werden.

Den Alarm „Netzwerkknoten verstummt“ löst jeder Knoten selbstständig über den Nachbarn aus, der aufgehört hat zu antworten, daher lösen die Nachbarn eines einzelnen ausgefallenen Knotens einen solchen Alarm unabhängig voneinander aus.

Externe Alarmzustellung

Neben der Liste im Browser können Alarme 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 Knoten sichtbare Alarm (eigener oder domänenweit replizierter) ab diesem Pegel wird zugestellt, und zwar sowohl beim Auslösen als auch beim Beheben. Der Pegel gilt für den Vorfall als Ganzes: Steigt der Schweregrad erst nach dem Auslösen auf den Pegel, wird das Auslösen im Moment der Erhöhung gemeldet, und die Behebung wird immer gemeldet, wenn das Auslösen gemeldet wurde — Auslösen und Behebung kommen als Paar. Die Verbindungsparameter jedes Kanals sind im Abschnitt Weboberfläche beschrieben. Wie der externe Befehl gestartet wird, was er erhält und wie man ein Skript dafür schreibt, mit fertigen Vorlagen für /bin/sh und Python, steht in Externe Skripte für Alarme.

Unabhängig sind die Kanäle nur voneinander: Alle drei unterliegen dem Hauptschalter des Alerters (Alerter-Einstellungen). Bei abgeschaltetem Dienst geht nichts hinaus — weder zu eigenen Alarmen noch zu den von benachbarten Knoten replizierten, noch zum Beheben eines Vorfalls, über den bereits berichtet wurde.

Typische Probleme

• Alarme der Nachbarn sind nicht sichtbar. Prüfen Sie, dass auf den Knoten die domänenweite Replikation aktiviert und eine gemeinsame Domäne festgelegt ist. System-Hardware-Alarme sind standardmäßig lokal — aktivieren Sie die Replikation von System-Alarmen, wenn Sie diese ebenfalls domänenweit sehen möchten.

• Ein haftender Alarm verschwindet nicht, nachdem die Ursache beseitigt wurde. Beheben Sie ihn manuell auf dem Quellknoten.

• Externe Benachrichtigungen treffen nicht ein, obwohl der Kanal konfiguriert ist und der Schwellenwert passt. Prüfen Sie den Hauptschalter des Alerters auf dem Knoten, von dem Sie die Zustellung erwarten: Ein abgeschalteter Dienst schweigt auch zu fremden, domänenweit replizierten Alarmen, obwohl diese im Admin-Bereich weiterhin sichtbar sind.