3 Monitorowanie plików dziennika

Przegląd

Zabbix może być używany do scentralizowanego monitorowania i analizy plików dziennika z obsługą lub bez obsługi rotacji logów.

Powiadomienia mogą służyć do ostrzegania użytkowników, gdy plik dziennika zawiera określone ciągi znaków lub wzorce ciągów.

Aby monitorować plik dziennika, musisz mieć:

• uruchomiony agent Zabbix na hoście
• skonfigurowaną pozycję monitorowania logów

Konfiguracja

Zweryfikuj parametry agenta

Upewnij się, że w pliku konfiguracyjnym agenta:

• parametr Hostname odpowiada nazwie hosta w frontend.
• serwery w parametrze ServerActive są określone do przetwarzania aktywnych kontroli.

Konfiguracja pozycja

Skonfiguruj pozycję do monitorowania logów.

Wszystkie wymagane pola wejściowe są oznaczone czerwoną gwiazdką.

W przypadku pozycji monitorujących logi należy wprowadzić:

Ważne uwagi

• Serwer i agent przechowują ślad rozmiaru monitorowanego logu oraz czasu ostatniej modyfikacji (dla logrt) w dwóch licznikach. Dodatkowo:
  • Agent wewnętrznie używa także numerów inode (w UNIX/GNU/Linux), indeksów plików (w Microsoft Windows) oraz sum MD5 pierwszych 512 bajtów pliku logu, aby poprawić decyzje, gdy pliki logów są skracane i rotowane.
  • W systemach UNIX/GNU/Linux zakłada się, że systemy plików, na których są przechowywane pliki logów, zwracają numery inode, które można wykorzystać do śledzenia plików.
  • W systemie Microsoft Windows agent Zabbix określa typ systemu plików, na którym znajdują się pliki logów, i używa:
    • W systemach plików NTFS 64-bitowych indeksów plików.
    • W systemach plików ReFS (tylko od Microsoft Windows Server 2012) 128-bitowych identyfikatorów plików.
    • W systemach plików, w których indeksy plików się zmieniają (np. FAT32, exFAT), używany jest algorytm awaryjny, aby przyjąć rozsądne podejście w niepewnych warunkach, gdy rotacja pliku logu powoduje wiele plików logów z tym samym czasem ostatniej modyfikacji.
  • Numery inode, indeksy plików i sumy MD5 są wewnętrznie zbierane przez agenta Zabbix. Nie są przesyłane do serwera Zabbix i są tracone po zatrzymaniu agenta Zabbix.
  • Nie modyfikuj czasu ostatniej modyfikacji pliku logu (na przykład za pomocą touch) i nie zastępuj monitorowanego pliku logu przez skopiowanie pliku z powrotem pod jego oryginalną nazwę (tworzy to nowy inode). W obu przypadkach Zabbix może potraktować plik jako inny plik i odczytać go ponownie od początku, co może spowodować duplikaty alertów.
  • Jeśli dla elementu logrt[] istnieje kilka pasujących plików logów, a agent Zabbix śledzi najnowszy z nich i ten najnowszy plik logu zostanie usunięty, w dzienniku zostanie zapisany komunikat ostrzegawczy "there are no files matching "<regexp mask>" in "<directory>". Agent Zabbix ignoruje pliki logów z czasem modyfikacji mniejszym niż najnowszy czas modyfikacji widziany przez agenta dla sprawdzanego elementu logrt[].
• Agent rozpoczyna odczyt pliku logu od miejsca, w którym zakończył poprzednio.
• Liczba już przeanalizowanych bajtów (licznik rozmiaru) oraz czas ostatniej modyfikacji (licznik czasu) są przechowywane w bazie danych Zabbix i są wysyłane do agenta, aby upewnić się, że agent rozpocznie odczyt pliku logu od tego miejsca w przypadkach, gdy agent został właśnie uruchomiony lub otrzymał elementy, które wcześniej były wyłączone lub nieobsługiwane. Jednak jeśli agent otrzymał od serwera niezerowy licznik rozmiaru, ale element logrt[] lub logrt.count[] nie może znaleźć pasujących plików, licznik rozmiaru jest resetowany do 0, aby analizować od początku, jeśli pliki pojawią się później.
• Gdy tylko plik logu stanie się mniejszy niż licznik rozmiaru logu znany agentowi, licznik jest resetowany do zera, a agent rozpoczyna odczyt pliku logu od początku, uwzględniając licznik czasu.
• Jeśli w katalogu znajduje się kilka pasujących plików z tym samym czasem ostatniej modyfikacji, agent próbuje poprawnie przeanalizować wszystkie pliki logów z tym samym czasem modyfikacji i uniknąć pominięcia danych lub ich podwójnej analizy, choć nie można tego zagwarantować we wszystkich sytuacjach. Agent nie zakłada żadnego konkretnego schematu rotacji plików logów ani go nie wykrywa. W przypadku wielu plików logów z tym samym czasem ostatniej modyfikacji agent przetworzy je w kolejności leksykograficznie malejącej. Dlatego w niektórych schematach rotacji pliki logów będą analizowane i raportowane w ich oryginalnej kolejności. W innych schematach rotacji oryginalna kolejność plików logów nie będzie zachowana, co może prowadzić do raportowania dopasowanych rekordów pliku logu w zmienionej kolejności (problem nie występuje, jeśli pliki logów mają różne czasy ostatniej modyfikacji).
• Agent Zabbix przetwarza nowe rekordy pliku logu raz na Update interval sekund.
• Agent Zabbix nie wysyła więcej niż maxlines pliku logu na sekundę. Limit ten zapobiega przeciążeniu zasobów sieciowych i CPU oraz zastępuje wartość domyślną podaną przez parametr MaxLinesPerSecond w pliku konfiguracyjnym agenta.
• Aby znaleźć wymagany ciąg, Zabbix przetworzy 10 razy więcej nowych linii niż ustawiono w MaxLinesPerSecond. Tak więc na przykład, jeśli element log[] lub logrt[] ma Update interval równy 1 sekundzie, domyślnie agent przeanalizuje nie więcej niż 200 rekordów pliku logu i wyśle nie więcej niż 20 pasujących rekordów do serwera Zabbix w jednym sprawdzeniu. Zwiększając MaxLinesPerSecond w pliku konfiguracyjnym agenta lub ustawiając parametr maxlines w kluczu elementu, można zwiększyć limit do 10000 przeanalizowanych rekordów pliku logu i 1000 pasujących rekordów wysłanych do serwera Zabbix w jednym sprawdzeniu. Jeśli Update interval jest ustawiony na 2 sekundy, limity dla jednego sprawdzenia będą ustawione 2 razy wyżej niż przy Update interval równym 1 sekundzie.
• Dodatkowo wartości log i log.count są zawsze ograniczone do 50% rozmiaru bufora wysyłania agenta, nawet jeśli nie ma w nim wartości innych niż log. Aby wartości maxlines mogły zostać wysłane w jednym połączeniu (a nie w kilku), parametr BufferSize agenta musi wynosić co najmniej maxlines x 2. Agent Zabbix może przesyłać dane podczas zbierania logów i dzięki temu zwalniać bufor, natomiast agent Zabbix 2 zatrzyma zbieranie logów do czasu przesłania danych i zwolnienia bufora, co odbywa się asynchronicznie.
• W przypadku braku elementów log cały rozmiar bufora agenta jest używany dla wartości innych niż log. Gdy pojawiają się wartości log, zastępują one starsze wartości inne niż log w razie potrzeby, aż do wyznaczonych 50%.
• Dla rekordów pliku logu dłuższych niż 256kB tylko pierwsze 256kB są dopasowywane do wyrażenia regularnego, a reszta rekordu jest ignorowana. Jednak jeśli agent Zabbix zostanie zatrzymany podczas obsługi długiego rekordu, wewnętrzny stan agenta zostaje utracony i długi rekord może zostać przeanalizowany ponownie i inaczej po ponownym uruchomieniu agenta.
• Szczególna uwaga dotycząca separatorów ścieżek "\": jeśli file_format ma wartość "file\.log", to nie powinien istnieć katalog "file", ponieważ nie można jednoznacznie określić, czy "." jest znakiem poprzedzonym znakiem ucieczki, czy jest pierwszym symbolem nazwy pliku.
• Wyrażenia regularne dla logrt są obsługiwane tylko w nazwie pliku, dopasowywanie wyrażeniem regularnym dla katalogu nie jest obsługiwane.
• Na platformach UNIX element logrt[] staje się NOTSUPPORTED, jeśli katalog, w którym oczekuje się plików logów, nie istnieje.
• W systemie Microsoft Windows, jeśli katalog nie istnieje, element nie stanie się NOTSUPPORTED (na przykład, jeśli katalog jest błędnie wpisany w kluczu elementu).
• Brak plików logów dla elementu logrt[] nie powoduje stanu NOTSUPPORTED. Błędy odczytu plików logów dla elementu logrt[] są zapisywane jako ostrzeżenia w pliku logu agenta Zabbix, ale nie powodują stanu NOTSUPPORTED.
• Plik logu agenta Zabbix może być pomocny w ustaleniu, dlaczego element log[] lub logrt[] stał się NOTSUPPORTED. Zabbix może monitorować własny plik logu agenta, z wyjątkiem sytuacji, gdy ustawiono DebugLevel=4 lub DebugLevel=5.
• Wyszukiwanie znaku zapytania za pomocą wyrażenia regularnego, np. \?, może dawać wyniki fałszywie dodatnie, jeśli plik tekstowy zawiera symbole NUL, ponieważ są one zastępowane przez "?" przez Zabbix, aby kontynuować przetwarzanie linii aż do znaku nowej linii.

Wyodrębnianie pasującej części wyrażenia regularnego

Czasami chcemy wyodrębnić z pliku docelowego tylko interesującą wartość zamiast zwracać cały wiersz, gdy zostanie znalezione dopasowanie wyrażenia regularnego.

Pozycje typu log mają możliwość wyodrębniania żądanych wartości z dopasowanych wierszy. Jest to realizowane za pomocą dodatkowego parametru output w pozycjach log i logrt.

Użycie parametru output pozwala wskazać "grupę przechwytującą" dopasowania, która może nas interesować.

Na przykład

log[/path/to/the/file,"large result buffer allocation.*Entries: ([0-9]+)",,,,\1]

powinno umożliwić zwrócenie liczby wpisów znalezionych w zawartości:

Fr Feb 07 2014 11:07:36.6690 */ Thread Id 1400 (GLEWF) large result
buffer allocation - /Length: 437136/Entries: 5948/Client Ver: >=10/RPC
ID: 41726453/User: AUser/Form: CFG:ServiceLevelAgreement

Zwrócona zostanie tylko liczba, ponieważ \1 odnosi się do pierwszej i jedynej grupy przechwytującej: ([0-9]+).

A dzięki możliwości wyodrębniania i zwracania liczby, wartość ta może być użyta do definiowania wyzwalaczy.

Używanie parametru maxdelay

Parametr maxdelay w pozycjach logów pozwala ignorować niektóre starsze wiersze z plików logów, aby w ramach maxdelay sekund analizowane były najnowsze wiersze.

Domyślnie pozycje do monitorowania logów przetwarzają wszystkie nowe wiersze pojawiające się w plikach logów. Istnieją jednak aplikacje, które w niektórych sytuacjach zaczynają zapisywać ogromną liczbę komunikatów do swoich plików logów. Na przykład, jeśli baza danych lub serwer DNS jest niedostępny, takie aplikacje zalewają pliki logów tysiącami niemal identycznych komunikatów o błędach, aż do przywrócenia normalnego działania. Domyślnie wszystkie te komunikaty będą sumiennie analizowane, a pasujące wiersze będą wysyłane do serwera zgodnie z konfiguracją w pozycjach log i logrt.

Wbudowana ochrona przed przeciążeniem składa się z konfigurowalnego parametru maxlines (chroni serwer przed zbyt dużą liczbą przychodzących pasujących wierszy logów) oraz limitu 10*'maxlines' (chroni CPU i I/O hosta przed przeciążeniem przez agent w jednym sprawdzeniu). Mimo to istnieją 2 problemy związane z wbudowaną ochroną. Po pierwsze, do serwera zgłaszana jest duża liczba potencjalnie mało informacyjnych komunikatów, które zajmują miejsce w bazie danych. Po drugie, z powodu ograniczonej liczby wierszy analizowanych na sekundę agent może przez wiele godzin pozostawać w tyle za najnowszymi rekordami logów. Najprawdopodobniej wolisz zostać wcześniej poinformowany o bieżącej sytuacji w plikach logów, zamiast przez wiele godzin przeglądać stare rekordy.

Rozwiązaniem obu problemów jest użycie parametru maxdelay. Jeśli zostanie określone maxdelay > 0, podczas każdego sprawdzenia mierzona jest liczba przetworzonych bajtów, liczba pozostałych bajtów oraz czas przetwarzania. Na podstawie tych wartości agent oblicza szacowane opóźnienie - ile sekund zajęłoby przeanalizowanie wszystkich pozostałych rekordów w pliku logu.

Jeśli opóźnienie nie przekracza maxdelay, agent kontynuuje analizę pliku logu jak zwykle.

Jeśli opóźnienie jest większe niż maxdelay, agent pomija fragment pliku logu, "przeskakując" nad nim do nowej szacowanej pozycji, tak aby pozostałe wiersze mogły zostać przeanalizowane w ciągu maxdelay sekund.

Należy zauważyć, że agent nawet nie odczytuje pominiętych wierszy do bufora, lecz oblicza przybliżoną pozycję, do której ma przeskoczyć w pliku.

Fakt pomijania wierszy pliku logu jest zapisywany w pliku logu agenta w następujący sposób:

14287:20160602:174344.206 item:"logrt["/home/zabbix32/test[0-9].log",ERROR,,1000,,,120.0]"
logfile:"/home/zabbix32/test1.log" skipping 679858 bytes
(from byte 75653115 to byte 76332973) to meet maxdelay

Wartość „to byte” jest przybliżona, ponieważ po „przeskoczeniu” agent dostosowuje pozycję w pliku do początku wiersza logu, który może znajdować się dalej w pliku lub wcześniej.

W zależności od tego, jak szybko rośnie log w porównaniu z szybkością jego analizowania, możesz nie zobaczyć żadnych „przeskoków”, rzadkie lub częste „przeskoki”, duże lub małe „przeskoki”, a nawet niewielki „przeskok” przy każdym sprawdzeniu. Wahania obciążenia systemu i opóźnienia sieciowe również wpływają na obliczanie opóźnienia, a tym samym na „przeskakiwanie” do przodu, aby nadążyć za parametrem maxdelay.

Nie zaleca się ustawiania maxdelay < update interval (może to skutkować częstymi małymi „przeskokami”).

Uwagi dotyczące obsługi rotacji plików dziennika copytruncate

logrt z opcją copytruncate zakłada, że różne pliki dziennika mają różne rekordy (co najmniej ich znaczniki czasu są różne), dlatego sumy MD5 początkowych bloków (do pierwszych 512 bajtów) będą różne. Dwa pliki z takimi samymi sumami MD5 początkowych bloków oznaczają, że jeden z nich jest oryginałem, a drugi - kopią.

logrt z opcją copytruncate dokłada starań, aby poprawnie przetwarzać kopie plików dziennika bez zgłaszania duplikatów. Nie zaleca się jednak takich sytuacji, jak tworzenie wielu kopii pliku dziennika z tym samym znacznikiem czasu, rotacja pliku dziennika częściej niż interwał aktualizacji pozycji logrt\[\] oraz częste ponowne uruchamianie agent. Agent stara się obsługiwać wszystkie te sytuacje w rozsądny sposób, ale nie można zagwarantować dobrych wyników w każdych okolicznościach.

Uwagi dotyczące trwałych plików dla pozycji log*[]

Cel plików trwałych

Gdy agent Zabbix jest uruchamiany, otrzymuje listę aktywnych kontroli z serwera Zabbix lub proxy. W przypadku metryk log*[] otrzymuje przetworzony rozmiar logu oraz czas modyfikacji, aby ustalić, od którego miejsca rozpocząć monitorowanie pliku logu. W zależności od rzeczywistego rozmiaru pliku logu i czasu modyfikacji zgłoszonych przez system plików agent decyduje, czy kontynuować monitorowanie pliku logu od przetworzonego rozmiaru logu, czy przeanalizować plik logu ponownie od początku.

Działający agent utrzymuje większy zestaw atrybutów do śledzenia wszystkich monitorowanych plików logu pomiędzy kontrolami. Ten stan przechowywany w pamięci jest tracony po zatrzymaniu agenta.

Nowy opcjonalny parametr persistent_dir określa katalog do przechowywania tego stanu pozycji log[], log.count[], logrt[] lub logrt.count[] w pliku. Stan pozycji log jest przywracany z pliku trwałego po ponownym uruchomieniu agenta Zabbix.

Głównym przypadkiem użycia jest monitorowanie pliku logu znajdującego się na lustrzanym systemie plików. Do pewnego momentu plik logu jest zapisywany na obu lustrach. Następnie lustra są rozdzielane. Na aktywnej kopii plik logu nadal rośnie, otrzymując nowe rekordy. Agent Zabbix analizuje go i wysyła przetworzony rozmiar logu oraz czas modyfikacji do serwera. Na pasywnej kopii plik logu pozostaje bez zmian, daleko za aktywną kopią. Później system operacyjny i agent Zabbix są uruchamiane ponownie z pasywnej kopii. Przetworzony rozmiar logu i czas modyfikacji, które agent Zabbix otrzymuje z serwera, mogą nie być prawidłowe dla sytuacji na pasywnej kopii. Aby kontynuować monitorowanie pliku logu od miejsca, w którym agent zakończył pracę w momencie rozdzielenia lustra systemu plików, agent przywraca swój stan z pliku trwałego.

Działanie agent z plikami trwałymi

Przy uruchomieniu agent Zabbix nie wie nic o plikach trwałych. Dopiero po otrzymaniu listy aktywnych kontroli od serwer Zabbix (proxy) agent widzi, że niektóre pozycje logów powinny być obsługiwane przez pliki trwałe w określonych katalogach.

Podczas działania agent pliki trwałe są otwierane do zapisu (za pomocą fopen(filename, "w")) i nadpisywane najnowszymi danymi. Prawdopodobieństwo utraty danych pliku trwałego, jeśli nadpisywanie i rozdzielenie kopii lustrzanej systemu plików nastąpią w tym samym czasie, jest bardzo małe; nie jest wymagane żadne specjalne postępowanie. Zapisywanie do pliku trwałego NIE jest poprzedzane wymuszonym synchronizowaniem z nośnikiem danych (fsync() nie jest wywoływane).

Nadpisywanie najnowszymi danymi odbywa się po pomyślnym zgłoszeniu pasującego rekordu pliku logu lub metadanych (przetworzony rozmiar logu i czas modyfikacji) do serwer Zabbix. Może to następować nawet przy każdym sprawdzeniu pozycji, jeśli plik logu nadal się zmienia.

Brak specjalnych działań podczas zamykania agent.

Po otrzymaniu listy aktywnych kontroli agent oznacza przestarzałe trwałe pliki do usunięcia. Trwały plik staje się przestarzały, jeśli:

1. Odpowiednia pozycja logu nie jest już monitorowana.
2. Pozycja logu zostaje ponownie skonfigurowana z inną lokalizacją persistent_dir niż wcześniej.

Usunięcie jest wykonywane z opóźnieniem 24 godzin, ponieważ pliki logów w stanie NOTSUPPORTED nie są uwzględniane na liście aktywnych kontroli, ale mogą później stać się SUPPORTED, a ich trwałe pliki będą wtedy przydatne.

Jeśli agent zostanie zatrzymany przed upływem 24 godzin, przestarzałe pliki nie zostaną usunięte, ponieważ agent Zabbix nie otrzymuje już od serwer Zabbix informacji o ich lokalizacji.

Nazewnictwo i lokalizacja plików trwałych

Zabbix agent rozróżnia aktywne kontrole na podstawie ich kluczy. Na przykład logrt[/home/zabbix/test.log] i logrt[/home/zabbix/test.log,] są różnymi pozycjami. Zmodyfikowanie pozycji logrt[/home/zabbix/test.log,,,10] w frontend na logrt[/home/zabbix/test.log,,,20] spowoduje usunięcie pozycji logrt[/home/zabbix/test.log,,,10] z listy aktywnych kontroli agenta i utworzenie pozycji logrt[/home/zabbix/test.log,,,20] (niektóre atrybuty są przenoszone podczas modyfikacji w frontend/serwer, ale nie w agencie).

Nazwa pliku jest tworzona z sumy MD5 klucza pozycji z dołączoną długością klucza pozycji, aby zmniejszyć prawdopodobieństwo kolizji. Na przykład stan pozycji logrt[/home/zabbix50/test.log,,,,,,,,/home/zabbix50/agent_private] będzie przechowywany w pliku trwałym c963ade4008054813bbc0a650bb8e09266.

Wiele pozycji log może używać tej samej wartości persistent_dir.

persistent_dir jest określany z uwzględnieniem konkretnego układu systemu plików, punktów montowania i opcji montowania oraz konfiguracji mirroringu pamięci masowej - plik trwały powinien znajdować się na tym samym zmirroringowanym systemie plików co monitorowany plik log.

Jeśli katalog persistent_dir nie może zostać utworzony lub nie istnieje, albo uprawnienia dostępu dla Zabbix agent nie pozwalają na tworzenie/zapis/odczyt/usuwanie plików, pozycja log staje się NOTSUPPORTED.

Jeśli prawa dostępu do plików trwałej pamięci masowej zostaną usunięte podczas działania agenta lub wystąpią inne błędy (np. brak miejsca na dysku), błędy są zapisywane w pliku dziennika agenta, ale pozycja logu nie przechodzi w stan NOTSUPPORTED.

Obciążenie I/O

Trwały plik pozycja jest aktualizowany po pomyślnym wysłaniu każdej partii danych (zawierającej dane pozycji) do serwer. Na przykład domyślna wartość BufferSize wynosi 100. Jeśli pozycja logu znalazła 70 pasujących rekordów, to pierwsze 50 rekordów zostanie wysłanych w jednej partii, trwały plik zostanie zaktualizowany, a następnie pozostałe 20 rekordów zostanie wysłanych (być może z pewnym opóźnieniem, gdy zostanie zgromadzonych więcej danych) w drugiej partii, po czym trwały plik zostanie ponownie zaktualizowany.

Akcje w przypadku awarii komunikacji między agentem a serwerem

Każda pasująca linia z pozycji log[] i logrt[] oraz wynik każdego sprawdzenia pozycji log.count[] i logrt.count[] wymaga wolnego slotu w wyznaczonej 50% części bufora wysyłania agenta. Elementy bufora są regularnie wysyłane do serwera (lub proxy), a sloty bufora są ponownie zwalniane.

Gdy w wyznaczonej części logów w buforze wysyłania agenta są wolne sloty i komunikacja między agentem a serwerem (lub proxy) zawodzi, wyniki monitorowania logów są gromadzone w buforze wysyłania. Pomaga to ograniczyć skutki krótkotrwałych awarii komunikacji.

Podczas dłuższych awarii komunikacji wszystkie sloty logów zostają zajęte i podejmowane są następujące działania:

• Sprawdzanie pozycji log[] i logrt[] zostaje zatrzymane. Po przywróceniu komunikacji i dostępności wolnych slotów w buforze sprawdzanie jest wznawiane od poprzedniego miejsca. Żadne pasujące linie nie są tracone, są jedynie raportowane później.
• Sprawdzanie log.count[] i logrt.count[] zostaje zatrzymane, jeśli maxdelay = 0 (domyślnie). Zachowanie jest podobne do pozycji log[] i logrt[], jak opisano powyżej. Należy zauważyć, że może to wpływać na wyniki log.count[] i logrt.count[]: na przykład jedno sprawdzenie zlicza 100 pasujących linii w pliku logu, ale ponieważ nie ma wolnych slotów w buforze, sprawdzanie zostaje zatrzymane. Po przywróceniu komunikacji agent zlicza te same 100 pasujących linii, a także 70 nowych pasujących linii. Agent wysyła teraz count = 170, tak jakby zostały znalezione w jednym sprawdzeniu.
• Sprawdzanie log.count[] i logrt.count[] z maxdelay > 0: jeśli podczas sprawdzania nie nastąpił "skok", zachowanie jest podobne do opisanego powyżej. Jeśli nastąpił "skok" o linie pliku logu, pozycja po "skoku" jest zachowywana, a wynik zliczania jest odrzucany. W ten sposób agent próbuje nadążać za rosnącym plikiem logu nawet w przypadku awarii komunikacji.

Obsługa błędów kompilacji i błędów wykonania wyrażeń regularnych

Jeśli wyrażenie regularne używane w pozycji log[], logrt[], log.count[] lub logrt.count[] nie może zostać skompilowane przez bibliotekę PCRE lub PCRE2, pozycja przechodzi do stanu NOTSUPPORTED z komunikatem o błędzie.
Aby kontynuować monitorowanie pozycji logu, należy poprawić wyrażenie regularne.

Jeśli wyrażenie regularne skompiluje się pomyślnie, ale zakończy się niepowodzeniem w czasie wykonywania (dla niektórych lub wszystkich rekordów logu), pozycja logu pozostaje obsługiwana, a monitorowanie jest kontynuowane.
Błąd wykonania jest zapisywany w pliku logu agenta Zabbix (bez rekordu z pliku logu).

Częstotliwość logowania jest ograniczona do jednego błędu wykonania na jedno sprawdzenie, aby umożliwić agentowi Zabbix monitorowanie własnego pliku logu.
Na przykład, jeśli analizowanych jest 10 rekordów, a 3 rekordy kończą się błędem wykonania regexp, w logu agenta zostanie wygenerowany jeden wpis.

Wyjątek: jeśli MaxLinesPerSecond=1 i interwał aktualizacji wynosi 1 (tylko 1 rekord może zostać przeanalizowany na jedno sprawdzenie), błędy wykonania regexp nie są logowane.

zabbix_agentd zapisuje klucz pozycji w przypadku błędu wykonania, a zabbix_agent2 zapisuje identyfikator pozycji, aby ułatwić identyfikację, która pozycja logu ma błędy wykonania.
W przypadku błędów wykonania zaleca się przeprojektowanie wyrażenia regularnego.