Wenn jedes Ereignis sich wie derselbe Alarm verhält, geht das kritische Signal im Rauschen unter.
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.
Unser Ansatz
TR7 verwaltet Benachrichtigungen nicht als einmalige Nachrichten, sondern als Alarmobjekte mit einem Lebenszyklus und kanalbasierten Aktionen.
Die Alarm-State-Machine verfolgt den Lebenszyklus des Ereignisses
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.
Cluster-Synchronisation macht den Alarm auf allen Nodes sichtbar
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.
Die Pool-Status-Evaluation teilt die Service-Gesundheit in sechs Klassen ein
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.
Die Cluster-IP-State-Machine verfolgt das Failover-Verhalten detailliert
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.
Fähigkeiten
Das Benachrichtigungssystem bietet Alarm-Lifecycle, Pool-Schwellen, Multi-Channel, mehrere Sprachen, Ruhezeiten, Zertifikatswarnung und archivierbare Ereignishistorie.
Der Alarm-Lifecycle verwaltet Beginn, Aktualisierung und Abschluss desselben Ereignisses
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.
Alarme erreichen den Kanal, auf den der Ingenieur wirklich schaut
E-Mail und SNMP sind die Orte, an denen Alarme ignoriert werden. Darüber hinaus liefert TR7 an WhatsApp und BiP als vollwertige Kanäle, neben SMS, Syslog und ausgehenden Webhooks nach Jira, Slack, Teams oder ServiceNow. Der Kanal wird je Pool und je Schweregrad gewählt, sodass eine Schwellenüberschreitung um 03:40 dort ankommt, wo jemand hinsieht, statt in einem Postfach, das erst morgens geöffnet wird.
Die Per-Pool-Notify-Konfiguration ermöglicht service-basierte Schwellen- und Kanalauswahl
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.
Mehrere Benachrichtigungskanäle bieten verschiedenen Operationsteams passende Aktionen
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.
Die Multi-Language-Template-Engine erzeugt die Benachrichtigung in der Sprache des Benutzers
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.
Mehr als dreißig Pool- und Cluster-Statusschlüssel liefern eine detaillierte Ursache
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.
silentAtNight steuert das Kanalverhalten in Ruhezeiten
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.
Bei nahendem Zertifikatsablauf kann eine automatische Warnung erzeugt werden
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.
Das Contact-Group-Modell ermöglicht benutzer- und teambasierte Verteilung
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.
Die SMTP-Konfiguration passt sich an die Unternehmens-E-Mail-Infrastruktur an
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.
Das Log-Archiv hält die Alarm- und Benachrichtigungshistorie in einem komprimierten Archiv
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.
NotificationType unterscheidet, ob das Ereignis Alarm, Benachrichtigung oder Info ist
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.
Pair-ID-Grouping verfolgt dieselbe Ereignisfamilie zusammen
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.
Operative Tiefe
Das Benachrichtigungssystem wird zusammen mit Statuswerten, Lognamen, Komprimierung, SMTP-Sicherheit und der Cluster-IP-State-Machine betrieben.
Pool-Statuswerte
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- und Notification-Logs
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.
Log-Komprimierung
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.
Katalog vordefinierter Statusschlüssel
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.
SMTP-Verbindungsverhalten
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-State-Machine
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.
In welchen Szenarien es verwendet wird
Ein nächtliches Backend-down-Ereignis still, aber sichtbar verwalten
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.
Automatische Erneuerungswarnung vor Zertifikatsablauf
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.
Ein Cluster-IP-Failover-Ereignis über einen kritischen Kanal übermitteln
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.
WAAP- oder Verkehrsschwellenüberschreitung an das Netzwerkmanagementsystem übergeben
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.
Benachrichtigungshistorie für ein PCI-Audit archivieren
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.
Einem mehrsprachigen Operationsteam Alarme in verschiedenen Sprachen senden
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.
Häufig gestellte Fragen
Welche Benachrichtigungskanäle werden unterstützt?
Wie funktioniert die Ruhezeit? Verschwindet das Ereignis vollständig?
Was bedeuten die 30+ Pool-Statusschlüssel?
Wie funktioniert der Alarm-Lifecycle?
Können Benachrichtigungen in verschiedenen Sprachen gesendet werden?
Welche Optionen gibt es für die SMTP- und E-Mail-Konfiguration?
Zentralisieren Sie das Ereignismanagement mit dem richtigen Kanal und Kontext
Alarm-Lifecycle, 30+ Statusschlüssel, Multi-Channel und Ruhezeiten. Lassen Sie es uns in einer Live-Einrichtung in Ihrer eigenen Umgebung zeigen.