Korelacja zdarzeń oparta na wyzwalaczach

Omówienie

Korelacja zdarzeń oparta na wyzwalaczach umożliwia korelowanie oddzielnych problemów zgłaszanych przez jeden wyzwalacz.

Chociaż ogólnie zdarzenie OK może zamknąć wszystkie zdarzenia problemowe 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 naraz.

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

W Zabbiksie możliwe jest powiązanie zdarzeń problemowych na podstawie tagowania. Tagi służą do wyodrębniania wartości i tworzenia identyfikacji dla zdarzeń problemowych. Wykorzystując to, problemy można również zamykać indywidualnie na podstawie dopasowanego tagu.

Innymi słowy, ten sam wyzwalacz może tworzyć oddzielne zdarzenia identyfikowane przez tag zdarzenia. Dzięki temu zdarzenia problemowe mogą być identyfikowane pojedynczo i zamykane oddzielnie na podstawie identyfikacji przez tag zdarzenia.

Jak to działa

W monitorowaniu logów możesz napotkać wiersze podobne do tych:

Wiersz 1: Usługa 1 zatrzymana
Wiersz 2: Usługa 2 zatrzymana
Wiersz 3: Usługa 1 została uruchomiona ponownie
Wiersz 4: Usługa 2 została uruchomiona ponownie

Ideą korelacji zdarzeń jest możliwość dopasowania zdarzenia problemu z Wiersza 1 do rozwiązania z Wiersza 3 oraz zdarzenia problemu z Wiersza 2 do rozwiązania z Wiersza 4, a następnie zamykania tych problemów jeden po drugim:

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

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

Aby to zrobić, musisz oznaczyć te powiązane zdarzenia na przykład jako "Usługa 1" i "Usługa 2". Można to zrobić, stosując wyrażenie regularne do wiersza logu, aby wyodrębnić wartość znacznika. Następnie, gdy zdarzenia są tworzone, otrzymują odpowiednio znaczniki "Usługa 1" i "Usługa 2", a problem może zostać dopasowany do rozwiązania.

Konfiguracja

Pozycja

Na początek możesz chcieć skonfigurować pozycję, która monitoruje plik dziennika, na przykład:

log[/var/log/syslog]

Po skonfigurowaniu pozycji poczekaj minutę, aż zmiany konfiguracji zostaną uwzględnione, a następnie przejdź do Latest data, aby upewnić się, że pozycja zaczęła zbierać dane.

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żda linia zawierająca ciąg "Stopping" jest uznawana za problem, ustaw także Tryb generowania zdarzeń Problem w konfiguracji wyzwalacza na 'Multiple'.

Następnie zdefiniuj wyrażenie odzyskiwania. Poniższe 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 odpowiadające im 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:

  • Tryb generowania zdarzeń Problem: Multiple
  • Zdarzenie OK zamyka: Wszystkie problemy, jeśli wartości tagów są zgodne
  • Wprowadź nazwę tagu do dopasowywania zdarzeń

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

Jeśli konfiguracja przebiegnie pomyślnie, w Monitoring > Problemy 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ą być tworzone dla niepowiązanych problemów, przejrzyj proszę przypadki opisane poniżej!

  • Zindeksowane makra zawsze odnoszą się do pola Expression w konfiguracji wyzwalacza, a nie do pola 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 odzyskiwania. Jeśli wyrażenie odzyskiwania opiera się na innej pozycji, a wartość pozycji z wyrażenia problemu zmieni się do czasu odzyskiwania, zdarzenia otrzymają różne tagi i nie zostaną skorelowane.

  • Gdy dwie aplikacje zapisują 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ą). Jednak może to 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 o błędzie z usługi B.

  • Rzeczywiste tagi i wartości tagów stają się widoczne dopiero po wyzwoleniu wyzwalacza. Jeśli użyte wyrażenie regularne jest nieprawidłowe, zostanie ono bez komunikatu 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 zawiera informacji rozróżniających, może to również skutkować podobnymi tagami zdarzeń dla niepowiązanych problemów.