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.
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 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 Streamebene. Jeder Stream hat einen Schalter, der seine Alerts vollständig stummschaltet (zusammen mit den Alerts seiner Ein- und Ausgänge), sowie eine Alert-Verzögerung: eine Quelle, die sich innerhalb der eingestellten Zeit erholt, löst keinen Alert 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 Alert über einen Eingangsfehler — über die Umschaltung berichtet der Alert ü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 Node löst keine eigenen Alerts aus und sendet nichts an externe Ziele — weder eigene Alerts noch die von benachbarten Nodes domänenweit replizierten.
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
58	ein PCR-Sprung der Quelle über das Diskontinuitätsfenster hinaus hat die Ausgabe zerrissen — 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

Die Stufe eines Alerts mit Code 1 bestimmen die Folgen des Ausfalls und nicht die bloße Tatsache eines Fehlers. Ein ausgefallener Ausgang ist immer „kritisch“: hinter ihm steht keine Reserve, das ist verlorene Auslieferung. Ein ausgefallener Eingang ist nur dann kritisch, wenn der Stream gerade über ihn läuft oder noch kein aktiver Eingang vorhanden ist; der Ausfall eines Eingangs, den der Stream im Moment nicht nutzt, ist ein Verlust an Redundanz, und einem solchen Alert wird die Stufe „Fehler“ zugewiesen. So stimmt die zusammenfassende Schwere eines Streams mit seinem Zustand überein: eine defekte Reserve färbt einen gesunden Stream nicht kritisch. Und wenn es nichts mehr gibt, worauf umgeschaltet werden könnte, und der Stream steht, liest sich ein Vorfall an einem Eingang, der noch hochzukommen versucht, als „kritisch“ — hinter ihm steht keine Reserve mehr. Bei der Umschaltung auf eine Reserve wird der Vorfall am verlassenen Eingang vollständig aufgehoben: der Eingang wird gestoppt, während der Grund, aus dem der Stream ihn verlassen hat, in der Oberfläche als Historie sichtbar bleibt (Quellenredundanz).

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 — anders als Code 1, der stets an einen bestimmten Eingang oder Ausgang gebunden ist und bei einem Stream mit Reservierung deshalb in mehrere kurzlebige Vorfälle zerfällt. 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. Ein vom Administrator gestoppter oder pausierter Stream fällt nicht darunter — diesen Zustand beschreiben die Codes 13 und 14.

Die Codes 58, 59 und 61 sind eine Empfehlung zu den Synchronisationseinstellungen des Eingangs und kein 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 zerriss; die Meldung nennt, wie viel des angesammelten Stroms der letzte solche Fall verworfen hat. Code 61 ist derselbe Bruch der Quell-Zeitachse, nur verlustfrei durchgeführt. 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 nach sechs Stunden ohne ein einziges Ereignis. 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 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)

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

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, 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 Node nicht verfügbar ist (erfordert Administrator-Eingriff)	lokal
55	die Lizenz des Nodes läuft ab: eine Warnung zwei Wochen vor dem Ende der Frist, nach deren Eintritt — erfordert Administrator-Eingriff, und der Node startet den Dienst neu	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

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

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). 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 Node wieder meldet, kehren die dort nicht behobenen Zeilen in die Liste zurück. So verschwindet aus der zusammenfassenden Liste auch der Alert ü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 wie bisher sofort gelöscht, während eine manuelle Behebung, das Löschen des Streams, das Abschalten der Alerts 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 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, Ablauf der Lizenz und die Erkennung einer Lizenz als nicht echt.
Bleiben lokal: Ressourcen-Alerts über Hardware und Storage, „Node verstummt“, Kollision von Node-Namen, Benachrichtigung über den Dienststart, Alerts zur DVR-Aufnahme-Gesundheit, die Anforderung eines auf dem Node nicht verfügbaren Transcoders, Alerts des Conditional-Access-Moduls und die fehlgeschlagene Entschlüsselung. 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.

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 Alerts noch zu den von benachbarten Nodes replizierten, noch zum Beheben eines Vorfalls, über den bereits berichtet wurde.

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.
Externe Benachrichtigungen treffen nicht ein, obwohl der Kanal konfiguriert ist und der Schwellenwert passt. Prüfen Sie den Hauptschalter des Alerters auf dem Node, von dem Sie die Zustellung erwarten: ein abgeschalteter Dienst schweigt auch zu fremden, domänenweit replizierten Alerts, obwohl diese im Admin-Bereich weiterhin sichtbar sind.