In einer Produktionsumgebung ist nicht jedes Ereignis gleich wichtig. Dass ein Backend in Wartung ist, dass alle Backends down sind, dass die Cluster-IP auf einen anderen Node wechselt, dass das Zertifikat innerhalb von 30 Tagen abläuft oder dass die Request-Rate-Schwelle überschritten wird, erfordert unterschiedliche operative Reaktionen. Wenn all dies zu einem einheitlichen E-Mail-Alarm wird, erlebt das Team schnell Alarmmüdigkeit.
In klassischen Ansätzen ist die Benachrichtigung meist auf E-Mail und Syslog beschränkt. Operationsteams möchten jedoch verschiedene Ereignisse über verschiedene Kanäle erhalten: kritisches Failover per SMS, routinemäßige Warnungen per UI, Sicherheitsereignisse per SNMP oder Syslog, Management-Übersichten per E-Mail. Ohne Kanaltrennung erhält entweder jeder alles oder kritische Ereignisse werden übersehen.
Auch die Ruhezeitenverwaltung ist wichtig. Um 03:00 Uhr das gesamte Team für eine Warnung von geringer Bedeutung zu wecken, ist unnötig; aber ein echter Ausfall oder ein Cluster-IP-Wechsel sollte dennoch sichtbar sein. Ruhezeit sollte nicht bedeuten, dass das Ereignis vollständig verschwindet, sondern dass es über den richtigen Kanal und zur richtigen Zeit behandelt wird.
Ereignisse wie Pool down, Backend down, Cluster-IP-Swap und Zone-Schließung mit demselben Text zu berichten, erschwert die Ursachenanalyse. Der Operator versucht zunächst zu entschlüsseln, was der Alarm bedeutet, und ergreift dann eine Maßnahme. Diese Verzögerung wirkt sich gerade auf hochfrequentierten Plattformen direkt auf die Servicequalität aus.
Das TR7 Benachrichtigungssystem differenziert Ereignisse mit Alarm-Lifecycle, 30+ vordefinierten Statusschlüsseln, Multi-Channel, mehreren Sprachen, Ruhezeiten und Per-Pool-Schwellenverwaltung; es übermittelt sie an die richtige Person, über den richtigen Kanal, mit dem richtigen Kontext.
TR7 verwaltet Benachrichtigungen nicht als einmalige Nachrichten, sondern als Alarmobjekte mit einem Lebenszyklus und kanalbasierten Aktionen.
Aktive Alarme werden anhand des alarmKey gehalten, mit updateAlarm aktualisiert und mit endAlarm geschlossen. So wird dasselbe Ereignis nicht immer wieder als neuer Alarm erzeugt; der Beginn, die Aktualisierung und der Abschluss des Ereignisses werden verfolgt.
Alarm- und Benachrichtigungsstatus können an andere Nodes im Cluster übertragen werden. So kann das Operationsteam nicht nur die Ereignisse des Nodes sehen, mit dem es verbunden ist, sondern auch den kritischen Zustand des gesamten Clusters.
Der Pool-Status wird mit den Werten UNKNOWN, OK, WARN, DISABLED, ERR und EVALUATING klassifiziert. Dieses Modell reduziert Wartungs-, Warn-, Fehler- und Evaluierungszustände nicht auf denselben flachen Alarmtext.
Cluster-IP-Zustände werden mit verschiedenen Signalen wie Interface-Erreichbarkeit, IP-Kollision, IP-Übergang und Zwei-Node-Verhalten bewertet. Failover-Ereignisse werden dem Operationsteam mit klarerem Kontext übermittelt.
Das Benachrichtigungssystem bietet Alarm-Lifecycle, Pool-Schwellen, Multi-Channel, mehrere Sprachen, Ruhezeiten, Zertifikatswarnung und archivierbare Ereignishistorie.
Der Flow aus updateAlarm, endAlarm und getAlarms verfolgt aktive Alarme über ihren Lebenszyklus. Wenn derselbe alarmKey erneut eintrifft, wird das Ereignis aktualisiert; es wird nicht als völlig neuer Alarm dupliziert. Mit Feldern wie staticPayload, ifAbsent und dontNotify lässt sich das Ereignisverhalten kontrollierter steuern. Diese Struktur reduziert Alarmrauschen und macht die Ereignishistorie aussagekräftiger.
Für jeden Pool können Schwellen für serviceStatus, poolStatus, Bandbreite, Request-Rate, aktuelle Session und neue Verbindung definiert werden. Innerhalb derselben Struktur können Kanalpräferenzen für E-Mail, SMS, WhatsApp, BiP, SNMP und UI festgelegt werden. So kann ein kritischer Service mit einer aggressiveren Alarmrichtlinie und ein Service von geringer Bedeutung mit einer ruhigeren Richtlinie überwacht werden. Das Benachrichtigungsverhalten wird nicht einheitlich plattformweit angewendet.
TR7 bietet ein Benachrichtigungsmodell, das mehrere Kanäle wie E-Mail, SMS, WhatsApp, BiP, SNMP, Syslog und UI unterstützt. Kritische Infrastrukturereignisse können per SMS oder SNMP an Netzwerkmanagementsysteme, Management-Übersichten per E-Mail und Routinezustände über die UI übermittelt werden. Dasselbe Ereignis kann mit unterschiedlicher Priorität an verschiedene Kanäle gesendet werden. Diese Flexibilität reduziert die Abhängigkeit von einem externen Alarmmanager.
Der NotificationTranslator kann Benachrichtigungstexte mit dictionary-basierter Übersetzungslogik in verschiedenen Sprachen erzeugen. Ein Operationsteam kann Benachrichtigungen in seiner Sprache erhalten, ein internationales Team in einer anderen. Es ist möglich, dasselbe Ereignis verschiedenen Benutzern in unterschiedlichen Sprachen zu übermitteln. Dies reduziert das Risiko von Fehlinterpretationen in mehrsprachigen, länderübergreifenden Betrieben.
30+ Statusschlüssel wie poolDisabled, allBeDown, noBeGiven, beDown, beStateUnknown, beMaint, poolDown, poolInterfaceAbsent, zoneClosed, clusterIpBoth, clusterIpPossibleCollide, clusterIpSwitched und clusterIpNone können verwendet werden. Diese Schlüssel machen den Alarmtext aussagekräftiger. Der Operator erhält nicht nur die Meldung "Service gestört"; er sieht auch die Art des Problems. Die Reaktionszeit verkürzt sich.
Mit silentAtNight können bestimmte Benachrichtigungen in den Nachtstunden stummgeschaltet werden. Das bedeutet nicht, dass das Ereignis vollständig verschwindet; es kann in der UI weiterhin sichtbar bleiben oder in die morgendliche Übersicht aufgenommen werden. Für kritische Ereignisse kann durch eine separate Kanalrichtlinie sichergestellt werden, dass wirklich wichtige Alarme dennoch übermittelt werden. Während Alarmmüdigkeit reduziert wird, bleibt die operative Sichtbarkeit erhalten.
Mit dem Feld notifyDaysBeforeCertificateExpiry kann eine bestimmte Anzahl von Tagen vor dem Zertifikatsablaufdatum eine Warnung erzeugt werden. Beispielsweise kann 30 Tage vorher eine E-Mail- oder UI-Benachrichtigung gesendet werden. So bleibt die Zertifikatserneuerung nicht bis zum letzten Tag liegen. Versäumnisse, die einen TLS-Ausfall verursachen könnten, werden frühzeitig erkannt.
Mitglieder einer Contact Group können mit E-Mail-Adressen, SMS-Nummern und Benutzertyp-Informationen definiert werden. Benachrichtigungen können an einen einzelnen Benutzer, eine Teamgruppe oder einen Benutzertyp geleitet werden. Dieses Modell erleichtert es, Bereitschaftsteam, SOC, SRE oder Management-Gruppen separat zu adressieren. Personenwechsel können verwaltet werden, ohne die Kanalrichtlinie zu stören.
SMTP-Host, -Port, -Authentifizierung, -Benutzername, -Passwort, TLS-Sicherheit, Zertifikatsvalidierung, Sender Name, Sender Address, cc, bcc, Attachment und HTML-Nachrichteneinstellungen können konfiguriert werden. Der E-Mail-Verbindungs-Timeout kann auf etwa 10 Sekunden gehalten werden. Diese Struktur erleichtert die Integration mit dem bestehenden Mail-Relay oder der SMTP-Infrastruktur der Organisation. E-Mail-Benachrichtigungen können an Marken- und Sicherheitsrichtlinien angepasst werden.
Alarm- und Notification-Logs können unter separaten Namen archiviert werden. Mit Zip-Komprimierung und hoher Komprimierungsstufe können vergangene Ereignisse für Audit und Untersuchung aufbewahrt werden. In PCI-, Änderungsmanagement- oder Post-Incident-Analyseprozessen kann die Benachrichtigungshistorie als Beweis verwendet werden. Sie kann mit externen Archivierungsprozessen zusammenarbeiten, ohne dass die lokale Sichtbarkeit verloren geht.
Das Feld NotificationType unterscheidet mit Klassen wie A, N und I zwischen Alarm, Notification und Info. Diese Unterscheidung ist wichtig für die Kritikalität des Ereignisses und die Art seiner Darstellung gegenüber dem Benutzer. Nicht jede Info-Nachricht verhält sich wie ein Alarm; und nicht jeder Alarm geht als gewöhnliche Benachrichtigung verloren. Das UI- und Externe-Kanal-Verhalten kann sich aus dieser Klassifizierung speisen.
Das Feld pairId von BasicNotification kann verwendet werden, um Benachrichtigungen derselben Ereignisgruppe zu verknüpfen. Beispielsweise können das Öffnen, Aktualisieren und Schließen eines Alarms innerhalb derselben Ereignisfamilie verfolgt werden. Dies erleichtert es, die Ereigniskette auf der SIEM- oder Audit-Seite zusammen zu sehen. Statt einzelner Nachrichten kann der gesamte Ereignisprozess analysiert werden.
Das Benachrichtigungssystem wird zusammen mit Statuswerten, Lognamen, Komprimierung, SMTP-Sicherheit und der Cluster-IP-State-Machine betrieben.
Die Pool-Statuswerte werden als UNKNOWN=-1, OK=0, WARN=1, DISABLED=2, ERR=3 und EVALUATING=4 klassifiziert. Dieses numerische Modell bietet eine konsistente Basis für die Alarmbewertung und die UI-Darstellung. Zustände werden nicht nur als Text, sondern als entscheidbare Werte behandelt.
Alarm-Logs können unter dem Namen basic-alarms, Benachrichtigungs-Logs unter dem Namen basic-notifications gehalten werden. Diese Trennung ermöglicht die getrennte Untersuchung des Ereignis-Lebenszyklus und der an den Benutzer übermittelten Benachrichtigungen. Operations- und Audit-Prozesse können verschiedene Logtypen nach ihrem jeweiligen Bedarf lesen.
Alarm- und Benachrichtigungsarchive können im Zip-Format und mit hoher Komprimierungsstufe gehalten werden. Dies reduziert die Kosten der Langzeitaufbewahrung. Für Audit wird ein einfacherer Zugriff auf vergangene Benachrichtigungsdatensätze ermöglicht.
Unter `_lb.*` befinden sich 30+ vordefinierte Statusschlüssel. Diese Schlüssel werden verwendet, um Pool-, Backend-, Interface-, Zone- und Cluster-IP-Verhalten granularer zu erklären. Benachrichtigungstext und Entscheidungslogik werden durch diese Schlüssel angereichert.
Beim E-Mail-Versand kann der Verbindungs-Timeout auf 10000 ms konfiguriert werden. Das Verhalten von TLS-Sicherheit und Zertifikatsvalidierung wird vom Benutzer gesteuert. Dies ermöglicht eine Mail-Relay-Integration gemäß den Sicherheitsanforderungen der Organisation.
Cluster-IP-Zustände werden mit einer separaten State-Machine interpretiert. Zustände wie IP-Unerreichbarkeit, Interface-Status, mögliche Kollision oder Node-Übergang können in zusammengeführte Cluster-IP-State-Werte umgewandelt werden. Failover-Alarme werden mit diesem Kontext genauer erzeugt.
Wenn ein Backend-down-Ereignis von geringer Bedeutung um 02:00 Uhr auftritt, kann silentAtNight den E-Mail-Versand stoppen. Das Ereignis bleibt in der UI aktiv und kann in die morgendliche Übersicht aufgenommen werden. So werden unnötige nächtliche Alarme reduziert, ohne dass das Ereignis vollständig verschwindet.
Das Operationsteam kann den Wert notifyDaysBeforeCertificateExpiry auf 30 Tage einstellen. Bei nahendem Zertifikatsablauf erzeugt das System eine E-Mail- oder UI-Benachrichtigung. Das Risiko einer Last-Minute-Erneuerung, die einen TLS-Ausfall verursachen könnte, wird reduziert.
Wenn die Cluster-IP auf einen anderen Node wechselt, kann ein clusterIpSwitched-Ereignis erzeugt werden. Dieses Ereignis kann dem Operationsteam per SMS, SNMP oder UI übermittelt werden. Wenn ein Failover eintritt, wird das Team nicht nach dem Ereignis, sondern im Moment des Ereignisses informiert.
Wenn die Schwelle für Request-Rate, Bandbreite, Session oder neue Verbindung überschritten wird, kann eine SNMP-Benachrichtigung erzeugt werden. Das Netzwerkmanagementsystem nimmt dieses Ereignis in sein eigenes Alarm-Dashboard auf. Sicherheits- und Netzwerkoperationsteams sehen dieselbe Schwelle in einem gemeinsamen Überwachungs-Flow.
Alarm- und Notification-Logs können als komprimiertes Archiv aufbewahrt werden. Während eines Audits kann gezeigt werden, welches Ereignis wann aufgetreten ist, welcher Kanal verwendet wurde und ob der Alarm geschlossen wurde. Die Benachrichtigungshistorie wird zu einem operativen Beweis.
Während ein Team denselben Alarm in seiner Sprache per E-Mail erhält, kann ein internationales Operationsteam die Nachricht in einer anderen Sprache erhalten. Der NotificationTranslator erzeugt den Ereignistext entsprechend der Sprache des Benutzers. In mehrsprachigen, länderübergreifenden Betrieben wird das Risiko einer Fehlinterpretation des Alarms reduziert.
Alarm-Lifecycle, 30+ Statusschlüssel, Multi-Channel und Ruhezeiten. Lassen Sie es uns in einer Live-Einrichtung in Ihrer eigenen Umgebung zeigen.