Korelacja zdarzeń oparta na wyzwalaczach

Przegląd

Korelacja zdarzeń oparta na wyzwalaczach pozwala korelować oddzielne problemy zgłaszane przez jeden wyzwalacz.

Chociaż zasadniczo zdarzenie OK może zamknąć wszystkie zdarzenia problemów utworzone przez jeden wyzwalacz, istnieją przypadki, w których potrzebne jest bardziej szczegółowe podejście. Na przykład podczas monitorowania plików dziennika możesz chcieć wykrywać określone problemy w pliku dziennika i zamykać je indywidualnie, a nie wszystkie jednocześnie.

Dotyczy to wyzwalaczy, dla których parametr PROBLEM event generation mode jest ustawiony na Multiple. Takie wyzwalacze są zwykle używane do monitorowania logów, przetwarzania trapów itp.

W Zabbix możliwe jest powiązanie zdarzeń problemów na podstawie tagów. Tagi są używane do wyodrębniania wartości i tworzenia identyfikacji dla zdarzeń problemów. Dzięki temu problemy mogą być również zamykane indywidualnie na podstawie pasującego tagu.

Innymi słowy, ten sam wyzwalacz może tworzyć oddzielne zdarzenia identyfikowane przez tag zdarzenia. Dlatego zdarzenia problemów mogą być identyfikowane pojedynczo i zamykane oddzielnie na podstawie identyfikacji przez tag zdarzenia.

Jak to działa

Podczas monitorowania logów możesz napotkać wiersze podobne do tych:

Wiersz1: Usługa 1 została zatrzymana
Wiersz2: Usługa 2 została zatrzymana
Wiersz3: Usługa 1 została uruchomiona ponownie
Wiersz4: Usługa 2 została uruchomiona ponownie

Ideą korelacji zdarzeń jest możliwość dopasowania zdarzenia problemowego z Wiersza1 do rozwiązania z Wiersza3 oraz zdarzenia problemowego z Wiersza2 do rozwiązania z Wiersza4 i zamykania tych problemów jeden po drugim:

Wiersz1: Usługa 1 została zatrzymana
Wiersz3: Usługa 1 została uruchomiona ponownie #problem z Wiersza 1 zamknięty

Wiersz2: Usługa 2 została zatrzymana
Wiersz4: Usługa 2 została uruchomiona ponownie #problem z Wiersza 2 zamknięty

Aby to zrobić, musisz oznaczyć te powiązane zdarzenia tagami, na przykład „Usługa 1” i „Usługa 2”. Można to zrobić, stosując wyrażenie regularne do wiersza logu w celu wyodrębnienia wartości tagu. Następnie, gdy zdarzenia są tworzone, otrzymują odpowiednio tagi „Usługa 1” i „Usługa 2”, a problem może zostać dopasowany do rozwiązania.

Konfiguracja

Pozycja

Na początek możesz skonfigurować pozycję monitorującą plik dziennika, na przykład:

log[/var/log/syslog]

Po skonfigurowaniu pozycji odczekaj minutę, aż zmiany konfiguracji zostaną zastosowane, a następnie przejdź do Najnowsze dane, aby upewnić się, że pozycja rozpoczęła zbieranie danych.

Trigger

Przy działającej pozycji musisz skonfigurować wyzwalacz. Ważne jest, aby zdecydować, które wpisy w pliku dziennika są warte uwagi. Na przykład następujące wyrażenie wyzwalacza będzie wyszukiwać ciąg taki jak 'Stopping', aby sygnalizować potencjalne problemy:

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

Aby upewnić się, że każdy wiersz zawierający ciąg "Stopping" jest uznawany za problem, ustaw także Problem event generation mode w konfiguracji wyzwalacza na 'Multiple'.

Następnie zdefiniuj wyrażenie odzyskiwania. Następujące wyrażenie odzyskiwania rozwiąże wszystkie problemy, jeśli zostanie znaleziona linia dziennika zawierająca ciąg "Starting":

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

Ponieważ nie chcemy tego, ważne jest, aby w jakiś sposób upewnić się, że odpowiednie problemy źródłowe są zamykane, a nie tylko wszystkie problemy. W tym może pomóc tagowanie.

Problemy i rozwiązania można dopasować, określając tag w konfiguracji wyzwalacza. Należy wprowadzić następujące ustawienia:

  • Problem event generation mode: Multiple
  • OK event closes: All problems if tag values match
  • Wprowadź nazwę tagu do dopasowywania zdarzeń

  • skonfiguruj tagi, aby wyodrębniać wartości tagów z wierszy dziennika

Jeśli konfiguracja przebiegnie pomyślnie, w Monitoring > Problems będzie można zobaczyć zdarzenia problemów oznaczone według aplikacji i dopasowane do ich rozwiązania.

Ponieważ możliwa jest nieprawidłowa konfiguracja, a podobne tagi zdarzeń mogą zostać utworzone dla niepowiązanych problemów, przejrzyj przypadki opisane poniżej!

  • Zindeksowane makra zawsze odnoszą się do pola Expression w konfiguracji wyzwalacza, a nie do Recovery expression. Na przykład w zdarzeniu odzyskiwania {ITEM.VALUE1} zostanie rozwiązane do najnowszej wartości pierwszej pozycji w wyrażeniu problemu w momencie odzyskania. Jeśli wyrażenie odzyskiwania opiera się na innej pozycji, a wartość pozycji z wyrażenia problemu zmieni się do czasu odzyskania, zdarzenia otrzymają różne tagi i nie zostaną skorelowane.

  • W przypadku dwóch aplikacji zapisujących komunikaty o błędach i odzyskaniu do tego samego pliku dziennika użytkownik może zdecydować się na użycie dwóch tagów service w tym samym wyzwalaczu z różnymi wartościami tagów, stosując oddzielne wyrażenia regularne w wartościach tagów, aby wyodrębnić nazwy, powiedzmy, usługi A i usługi B z makra {ITEM.VALUE} (np. gdy formaty komunikatów się różnią). Może to jednak nie zadziałać zgodnie z planem, jeśli nie będzie dopasowania do wyrażeń regularnych. Niedopasowane wyrażenia regularne spowodują puste wartości tagów, a pojedyncza pusta wartość tagu zarówno w zdarzeniach problemu, jak i OK wystarczy do ich skorelowania. W rezultacie komunikat odzyskiwania z usługi A może przypadkowo zamknąć komunikat błędu z usługi B.

  • Rzeczywiste tagi i wartości tagów stają się widoczne dopiero po zadziałaniu wyzwalacza. Jeśli użyte wyrażenie regularne jest nieprawidłowe, zostanie ono po cichu zastąpione ciągiem *UNKNOWN*. Jeśli początkowe zdarzenie problemu z wartością tagu *UNKNOWN* zostanie pominięte, mogą pojawić się kolejne zdarzenia OK z tą samą wartością tagu *UNKNOWN*, które mogą zamknąć zdarzenia problemów, których nie powinny były zamknąć.

  • Jeśli użytkownik używa makra {ITEM.VALUE} bez funkcji makr jako wartości tagu, obowiązuje ograniczenie do 255 znaków. Gdy komunikaty dziennika są długie, a pierwsze 255 znaków nie jest specyficzne, może to również skutkować podobnymi tagami zdarzeń dla niepowiązanych problemów.