Graylog: jak sprawdzić kompletność logów i retencję

Podczas awarii logi z serwera, aplikacji i urządzenia sieciowego powinny pozwolić odtworzyć tę samą historię. Nie uda się to, gdy jedno źródło przestało wysyłać zdarzenia, drugie ma przesunięty czas, a potrzebne wpisy zostały już usunięte. Dlatego wdrożenie Graylog warto zakończyć próbami, które pokażą, co faktycznie trafia do systemu i jak długo można to przeszukiwać.

Najpierw ustal, na jakie pytania mają odpowiadać logi

Wybierz kilka sytuacji, które administrator ma umieć rozpoznać: nieudane logowanie do usługi, restart procesu, połączenie odrzucone przez zaporę, błąd aplikacji. Dla każdej wskaż źródło zdarzenia i osobę, która potrafi ocenić jego treść. Od razu widać, czy plan obejmuje potrzebne dane.

Przygotuj listę źródeł: nazwa urządzenia lub usługi, rodzaj logu, sposób wysyłania, oczekiwany okres przechowywania i osoba odpowiedzialna za konfigurację. Sam adres IP nie wystarczy. Pod jednym adresem może działać kilka usług, a po zmianie infrastruktury ten sam adres trafia do innego urządzenia.

Którędy wiadomość dociera do wyszukiwarki i gdzie może zginąć

W Graylogu wiadomość przechodzi kilka etapów. Na każdym z nich może się zatrzymać albo zostać odrzucona:

• Źródło i sieć. Urządzenie nie wysyła zdarzenia, kolejka nadawcy się przepełnia, zapora blokuje port albo wiadomość ginie po drodze, co jest typowe dla UDP.
• Input (wejście). Odbiera wiadomości w danym protokole. To, że działa, nie znaczy jeszcze, że konkretna aplikacja wysyła na nie potrzebne zdarzenia.
• Journal. Odebrane wiadomości trafiają najpierw na dysk serwera Graylog. Journal ma limit rozmiaru i wieku (w pliku server.conf; domyślnie 5 GB i 12 godzin, sprawdź własną konfigurację). Gdy indeksowanie stoi, journal rośnie, a po osiągnięciu limitu Graylog usuwa najstarsze nieprzetworzone wiadomości.
• Przetwarzanie. Ekstraktory, reguły pipeline i parsery. Błąd parsera może zostawić tekst w systemie, ale odebrać mu użyteczne pola.
• Indeksowanie w OpenSearch. Wiadomość może zostać odrzucona, na przykład gdy pole ma w indeksie typ liczbowy, a przychodzi tekst. Takie przypadki Graylog zapisuje jako błędy indeksowania (Indexer Failures). Po drodze wiadomość może też utknąć, gdy w OpenSearch skończy się miejsce na dysku.

Dodatkowo strumienie (streams) kierują wiadomości według reguł, a zestaw indeksów (index set) określa, gdzie i jak długo będą przechowywane. Strumień, zestaw indeksów i wejście trzeba więc sprawdzać razem. Wiadomość, która jest „w Graylogu”, ale nie ma jej w wyszukiwarce, najczęściej utknęła na jednym z dwóch ostatnich etapów.

Jak sprawdzić kompletność logów?

Wygeneruj u źródła znaną serię zdarzeń i porównaj ją z tym, co znajdziesz w Graylogu. Porównuj identyfikatory, a nie samą liczbę wyników. Brak jednego wpisu i duplikat innego dadzą pozornie poprawną sumę.

Użyj źródła testowego albo uzgodnionego okna, w którym można bezpiecznie wysłać neutralne komunikaty. Nie generuj sztucznych błędów na produkcyjnej aplikacji. Każda wiadomość powinna mieć unikalny identyfikator próby i numer kolejny, na przykład TEST-LOG-A oraz 001–100 (sto to tylko przykład). Na hoście z Linuksem wystarczy pętla z poleceniem logger:

for i in $(seq -w 1 100); do
  logger -n graylog.example.local -P 1514 -T -t symbit-test "TEST-LOG-A $i"
done

Adres i port zamień na własne. Opcja -T wysyła wiadomości przez TCP, a port musi odpowiadać wejściu Syslog TCP utworzonemu w Graylogu.

Po wysłaniu ustaw w wyszukiwarce zakres czasu obejmujący całą próbę z zapasem na opóźnienie i wyszukaj frazę „TEST-LOG-A”, ograniczając wyniki do właściwego źródła. Wyeksportuj wyniki albo przepisz numery i porównaj je z wysłaną listą. Jeśli lokalny log nie potwierdza, że powstały wszystkie wiadomości, nie przypisuj braków od razu Graylogowi.

Próba, którą można powtórzyć

Progi ustal przed próbą razem z właścicielem usługi. Podane niżej wartości są przykładem.

• Kompletność. N to liczba unikalnych zdarzeń potwierdzonych u źródła, U to liczba tych samych identyfikatorów znalezionych w Graylogu. Wynik to U/N × 100%. Przy N = 100 i U = 98 wychodzi 98%, a dwa brakujące identyfikatory trzeba wyjaśnić. Dodatkowe kopie policz osobno.
• Opóźnienie. Mierz od wysłania zdarzenia na hoście testowym do chwili, gdy wpis da się znaleźć w wyszukiwarce. Porównywanie zegarów dwóch różnych urządzeń zniekształci wynik (więcej w sekcji o czasie). Jeśli sprawdzasz co 5 sekund, pomiar ma do 5 sekund niepewności. Warunek w rodzaju „każdy wpis widoczny w 60 sekund” uzgodnij z właścicielem usługi.
• Poprawność treści. Wybierz po jednym zdarzeniu każdego potrzebnego typu i sprawdź w Graylogu nazwę hosta, nazwę aplikacji, poziom zdarzenia i komunikat. Warunek zaliczenia: da się jednoznacznie wskazać źródło i odczytać informację potrzebną do diagnostyki.

Wynik 100% z jednej serii opisuje tylko tę próbę. Powtórz ją przy typowym obciążeniu, a jeśli odporność na przerwy jest wymagana, także po kontrolowanej przerwie. Zapisz wersje komponentów, czas próby i ustawienia wyszukiwania, żeby po zmianie konfiguracji móc uczciwie porównać wyniki.

Czy TCP rozwiązuje problem utraty logów?

Nie. TCP potwierdza dostarczenie na poziomie transportu, ale to jeszcze nie znaczy, że wiadomość została zapisana i da się ją znaleźć. Po drodze są jeszcze kolejka nadawcy, journal, przetwarzanie i indeksowanie.

Jeśli urządzenie obsługuje wyłącznie UDP, zapisz to w projekcie. UDP nie potwierdza dostarczenia, więc przy przeciążeniu sieci lub serwera część wiadomości zniknie bez śladu. Dla źródeł, w których historia zdarzeń ma duże znaczenie, wybierz wysyłkę z buforowaniem na dysku i ponawianiem, na przykład agenta zbierającego logi (Filebeat) albo rsyslog z kolejką dyskową. TLS szyfruje transmisję, ale o kompletności nic nie mówi.

Próbę przerwy wykonaj na wydzielonym źródle testowym. Wstrzymaj na uzgodniony czas jego połączenie z Graylogiem, wygeneruj oznaczoną serię i przywróć połączenie. Porównaj identyfikatory i zmierz, po jakim czasie dochodzą zaległe wpisy. Wynik zestaw z pojemnością kolejki nadawcy i tolerowaną długością przerwy. Do takiego testu nie wyłączaj wspólnego wejścia produkcyjnego.

Czas zdarzenia musi dać się porównać między urządzeniami

Zdarzenie powinno nieść czas ze strefą. RFC 5424 to przewiduje: znacznik zawiera przesunięcie względem UTC. Starszy format z RFC 3164, wciąż częsty w urządzeniach sieciowych, nie ma ani roku, ani strefy, więc odbiorca musi ją przyjąć na podstawie ustawień. To typowa przyczyna przesunięcia o godzinę. Część wejść Syslog pozwala ustawić strefę dla wiadomości, które jej nie mają, więc sprawdź opcje inputu.

Dla pojedynczego zdarzenia zestaw czas z lokalnego logu z polem czasu w Graylogu, sprowadzając oba do UTC. Porównaj go też z czasem odbioru wiadomości zapisanym przez Graylog (pole gl2_receive_timestamp). Sprawdź synchronizację zegara na źródle i na serwerze Graylog, na przykład poleceniem timedatectl. Różnica równa dokładnie godzinie wskazuje na strefę, a narastająca rozbieżność na zegar. To podpowiedzi do diagnostyki, a nie dowód przyczyny.

Przy zmianie czasu z letniego na zimowy jedna godzina w nocy się powtarza, więc dwa identyczne zapisy lokalne mogą oznaczać różne chwile. Przesunięcie względem UTC pozwala je odróżnić. W raporcie z próby podaj też strefę, w której wyświetlasz wyniki.

Jak sprawdzić, ile historii rzeczywiście zostaje?

Okres dostępnej historii porównaj z wymaganiem dla konkretnej grupy logów. W Graylog 7.2 retencję ustawia się w zestawie indeksów (System → Indices, sekcja Rotation and Retention). Domyślną i zalecaną opcją jest Data Tiering, a starsze strategie rotacji są oznaczone jako przestarzałe (Legacy, Deprecated).

W Data Tiering podajesz minimalną i maksymalną liczbę dni przechowywania. Dane są usuwane po upływie maksimum, a różnica między wartościami daje Graylogowi zapas na wybór momentu rotacji indeksów. Jeśli wymagasz 30 dni, ustaw minimum 30 i maksimum nieco większe, na przykład 35. W trybie Legacy retencja liczy indeksy, a nie dni, i tak działo się też w starszych wersjach Graylog.

Retencja w dniach nie reaguje na zajętość dysku. Gdy dysk OpenSearch zapełni się przed upływem okresu, po przekroczeniu progów zajętości (domyślnie 85%, 90% i 95%) OpenSearch najpierw przestaje przydzielać nowe shardy, a w końcu blokuje zapis do indeksów. Wtedy rośnie journal, a po jego zapełnieniu wiadomości giną. Przestrzeń trzeba więc policzyć z góry.

Do próby odczytaj zestaw indeksów przypisany do badanych danych i jego ustawienia. Potem wyszukaj znane zdarzenia kontrolne z różnych dat w zakresie obejmującym cały wymagany okres. Samo odnalezienie najstarszego wpisu nie dowodzi ciągłości historii, bo między nim a danymi bieżącymi mogą być luki.

Na nowym wdrożeniu nie da się potwierdzić kilkumiesięcznej historii w dniu odbioru. Można ocenić konfigurację, przetestować cykl rotacji i usuwania na wydzielonym zestawie indeksów oraz zaplanować późniejszą kontrolę. Nie skracaj retencji logów produkcyjnych, żeby przyspieszyć test, bo usuniesz potrzebne dane.

Do doboru przestrzeni zmierz przyrost rozmiaru zaindeksowanych danych w kolejnych pełnych dobach, osobno dla danych głównych i replik. Wybrany do planowania przyrost w GB/dobę pomnóż przez liczbę dni historii, a do wyniku dodaj miejsce na repliki, journal, przestrzeń roboczą i zapas na skoki ruchu. Ruch wejściowy w GB/dobę to nie to samo co zajętość indeksów na dysku.

Zakres opcji zależy też od edycji Graylog. W Open ustawiasz retencję w dniach na zasadach Data Tiering, ale warm tier (tańsze, wolniejsze miejsce na dane, które nadal da się przeszukiwać) i archiwizacja (zapis starych indeksów do plików przed usunięciem) są funkcjami Enterprise. Przy projekcie opartym na Open dobierz mechanizmy do wymagań, zamiast zakładać funkcje opisane w dokumentacji wersji płatnej.

Dokumentacja i źródła

• Graylog — Inputs
• Graylog — Index Model
• Graylog — Data Tiering
• RFC 5424 — The Syslog Protocol
• RFC 3164 — The BSD Syslog Protocol