1 Auslöser-basierte Ereigniskorrelation

Übersicht

Die Auslöser-basierte Ereigniskorrelation ermöglicht es, separate Probleme zu korrelieren, die von einem Auslöser gemeldet werden.

Während ein OK-Ereignis im Allgemeinen alle Problemereignisse schließen kann, die von einem Auslöser erstellt wurden, gibt es Fälle, in denen ein detaillierterer Ansatz erforderlich ist. Zum Beispiel möchten Sie bei der Überwachung von Protokolldateien möglicherweise bestimmte Probleme in einer Protokolldatei erkennen und diese einzeln statt alle zusammen schließen.

Dies ist bei Auslösern der Fall, deren Parameter PROBLEM event generation mode auf Multiple gesetzt ist. Solche Auslöser werden normalerweise für die Protokollüberwachung, Trap-Verarbeitung usw. verwendet.

In Zabbix ist es möglich, Problemereignisse auf Grundlage von Tags in Beziehung zu setzen. Tags werden verwendet, um Werte zu extrahieren und eine Identifikation für Problemereignisse zu erstellen. Dadurch können Probleme auch einzeln auf Grundlage eines übereinstimmenden Tags geschlossen werden.

Mit anderen Worten: Derselbe Auslöser kann separate Ereignisse erzeugen, die durch das Ereignis-Tag identifiziert werden. Daher können Problemereignisse einzeln identifiziert und separat auf Grundlage der Identifikation durch das Ereignis-Tag geschlossen werden.

Funktionsweise

Bei der Log-Überwachung können Sie auf Zeilen wie diese stoßen:

Zeile1: Dienst 1 gestoppt
Zeile2: Dienst 2 gestoppt
Zeile3: Dienst 1 wurde neu gestartet
Zeile4: Dienst 2 wurde neu gestartet

Die Idee der Ereigniskorrelation besteht darin, das Problemereignis aus Zeile1 mit der Behebung aus Zeile3 und das Problemereignis aus Zeile2 mit der Behebung aus Zeile4 abzugleichen und diese Probleme nacheinander zu schließen:

Zeile1: Dienst 1 gestoppt
Zeile3: Dienst 1 wurde neu gestartet #Problem aus Zeile 1 geschlossen

Zeile2: Dienst 2 gestoppt
Zeile4: Dienst 2 wurde neu gestartet #Problem aus Zeile 2 geschlossen

Dazu müssen Sie diese zusammengehörigen Ereignisse zum Beispiel mit „Dienst 1“ und „Dienst 2“ taggen. Das kann durch Anwenden eines regulären Ausdrucks auf die Log-Zeile erfolgen, um den Tag-Wert zu extrahieren. Wenn dann Ereignisse erstellt werden, werden sie entsprechend mit „Dienst 1“ und „Dienst 2“ getaggt, und das Problem kann mit der Behebung abgeglichen werden.

Konfiguration

Datenpunkt

Zunächst sollten Sie einen Datenpunkt einrichten, der eine Protokolldatei überwacht, zum Beispiel:

log[/var/log/syslog]

Nachdem der Datenpunkt eingerichtet wurde, warten Sie eine Minute, bis die Konfigurationsänderungen übernommen wurden, und gehen Sie dann zu Letzte Daten, um sicherzustellen, dass der Datenpunkt begonnen hat, Daten zu sammeln.

Trigger

Mit dem funktionierenden Datenpunkt müssen Sie den Auslöser konfigurieren. Es ist wichtig zu entscheiden, welche Einträge in der Protokolldatei beachtet werden sollen. Das folgende Auslöserausdrucksbeispiel sucht beispielsweise nach einer Zeichenfolge wie 'Stopping', um potenzielle Probleme zu signalisieren:

find(/My host/log[/var/log/syslog],,"regexp","Stopping")=1 

Definieren Sie dann einen Wiederherstellungsausdruck. Der folgende Wiederherstellungsausdruck löst alle Probleme auf, wenn eine Protokollzeile mit der Zeichenfolge "Starting" gefunden wird:

find(/My host/log[/var/log/syslog],,"regexp","Starting")=1 

Da wir das nicht möchten, ist es wichtig, irgendwie sicherzustellen, dass die entsprechenden Root-Probleme geschlossen werden und nicht nur alle Probleme. Dabei kann Tagging helfen.

Probleme und Wiederherstellungen können durch Angabe eines Tags in der Auslöserkonfiguration miteinander abgeglichen werden. Die folgenden Einstellungen müssen vorgenommen werden:

• Problem event generation mode: Multiple
• OK event closes: All problems if tag values match
• Geben Sie den Namen des Tags für den Ereignisabgleich ein

• konfigurieren Sie die Tags, um Tag-Werte aus Protokollzeilen zu extrahieren

Wenn die Konfiguration erfolgreich ist, können Sie Problemereignisse sehen, die nach Anwendung getaggt und ihrer Behebung in Monitoring > Problems zugeordnet sind.

• Indizierte Makros verweisen immer auf das Feld Expression der Auslöserkonfiguration, nicht auf die Recovery expression. Zum Beispiel wird in einem Wiederherstellungsereignis {ITEM.VALUE1} zum neuesten Wert des ersten Datenpunkts im Problemausdruck zum Zeitpunkt der Wiederherstellung aufgelöst. Wenn der Wiederherstellungsausdruck auf einem anderen Datenpunkt basiert und sich der Wert des Datenpunkts aus dem Problemausdruck bis zum Zeitpunkt der Wiederherstellung ändert, erhalten die Ereignisse unterschiedliche Tags und werden nicht korreliert.

• Wenn zwei Anwendungen Fehler- und Wiederherstellungsmeldungen in dieselbe Protokolldatei schreiben, kann ein Benutzer beschließen, zwei service-Tags im selben Auslöser mit unterschiedlichen Tag-Werten zu verwenden, indem separate reguläre Ausdrücke in den Tag-Werten genutzt werden, um die Namen von beispielsweise Dienst A und Dienst B aus dem Makro {ITEM.VALUE} zu extrahieren (z. B. wenn sich die Nachrichtenformate unterscheiden). Dies funktioniert jedoch möglicherweise nicht wie geplant, wenn keine Übereinstimmung mit den regulären Ausdrücken vorliegt. Nicht übereinstimmende Regexps führen zu leeren Tag-Werten, und ein einzelner leerer Tag-Wert sowohl in Problem- als auch in OK-Ereignissen reicht aus, um sie zu korrelieren. Daher kann eine Wiederherstellungsmeldung von Dienst A versehentlich eine Fehlermeldung von Dienst B schließen.

• Tatsächliche Tags und Tag-Werte werden erst sichtbar, wenn ein Auslöser auslöst. Wenn der verwendete reguläre Ausdruck ungültig ist, wird er stillschweigend durch die Zeichenfolge *UNKNOWN* ersetzt. Wenn das erste Problemereignis mit einem *UNKNOWN*-Tag-Wert verpasst wird, können nachfolgende OK-Ereignisse mit demselben *UNKNOWN*-Tag-Wert erscheinen, die Problemereignisse schließen, die sie nicht hätten schließen sollen.

• Wenn ein Benutzer das Makro {ITEM.VALUE} ohne Makrofunktionen als Tag-Wert verwendet, gilt die Begrenzung auf 255 Zeichen. Wenn Protokollmeldungen lang sind und die ersten 255 Zeichen nicht spezifisch sind, kann dies ebenfalls zu ähnlichen Ereignis-Tags für nicht zusammenhängende Probleme führen.