Trigger-basierte Ereigniskorrelation

Übersicht

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

Während ein OK-Ereignis im Allgemeinen alle von einem Auslöser erstellten Problemereignisse schließen kann, gibt es Fälle, in denen ein detaillierterer Ansatz erforderlich ist. Wenn Sie beispielsweise Protokolldateien überwachen, möchten Sie möglicherweise bestimmte Probleme in einer Protokolldatei erkennen und sie einzeln statt gemeinsam schließen.

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

In Zabbix ist es möglich, Problemereignisse auf Grundlage von Tagging miteinander in Beziehung zu setzen. Tags werden verwendet, um Werte zu extrahieren und eine Identifizierung für Problemereignisse zu erstellen. Mit diesem Vorteil können Probleme auch einzeln auf Grundlage des ü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 Identifizierung durch das Ereignis-Tag geschlossen werden.

Funktionsweise

Bei der Protokollüberwachung können Ihnen Zeilen wie die folgenden begegnen:

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 zu verknüpfen 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 beispielsweise mit "Dienst 1" und "Dienst 2" kennzeichnen. Dies kann durch Anwenden eines regulären Ausdrucks auf die Protokollzeile 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 der Behebung zugeordnet werden.

Konfiguration

Datenpunkt

Zunächst möchten Sie möglicherweise einen Datenpunkt einrichten, der eine Protokolldatei überwacht, zum Beispiel:

log[/var/log/syslog]

Nachdem der Datenpunkt eingerichtet ist, warten Sie eine Minute, bis die Konfigurationsänderungen übernommen wurden, und gehen Sie dann zu Latest data, um sicherzustellen, dass der Datenpunkt mit der Datenerfassung begonnen hat.

Auslöser

Wenn der Datenpunkt funktioniert, 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 gefunden wird, die die Zeichenfolge "Starting" enthält:

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. Hier 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 unter Monitoring > Problems Problemereignisse sehen, die nach Anwendung getaggt und ihrer Wiederherstellung zugeordnet sind.

• Indizierte Makros beziehen sich 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 Problem-Ausdruck zum Zeitpunkt der Wiederherstellung aufgelöst. Wenn der Wiederherstellungsausdruck auf einem anderen Datenpunkt basiert und sich der Wert des Datenpunkts im Problem-Ausdruck bis zur Wiederherstellung ändert, erhalten die Ereignisse unterschiedliche Tags und werden nicht korreliert.

• Wenn zwei Anwendungen Fehler- und Wiederherstellungsnachrichten in dieselbe Protokolldatei schreiben, kann ein Benutzer zwei service-Tags im selben Auslöser mit unterschiedlichen Tag-Werten 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 reguläre Ausdrücke 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 Wiederherstellungsnachricht 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 eine 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.