raport z logów

Raport z logów to podsumowanie zapisów dziennika w formie ułatwiającej ich analizę.

Od surowego dziennika do czytelnego zestawienia

Raport z logów powstaje przez filtrowanie, grupowanie i uporządkowanie w czasie zapisów, które w oryginale liczą dziesiątki tysięcy pozycji. W Windows źródłem jest Podgląd zdarzeń uruchamiany poleceniem eventvwr.msc, a właściwa praca odbywa się w PowerShellu: Get-WinEvent -FilterHashtable @{LogName='System'; StartTime=(Get-Date).AddDays(-7)} zwraca tydzień wpisów, które można potem posortować i wyeksportować przez Export-Csv. Wariant wiersza poleceń to wevtutil, przydatny na maszynach bez interfejsu graficznego.

W systemach z systemd odpowiednikiem jest journalctl. Polecenie journalctl -p err -b -1 pokazuje wyłącznie błędy z poprzedniego uruchomienia — dokładnie to, czego szuka się po nagłym restarcie.

Które identyfikatory zdarzeń naprawdę coś znaczą

Wartość raportu bierze się z umiejętności odsiania szumu. Zdarzenie 41 ze źródła Kernel-Power oznacza, że system nie został zamknięty poprawnie — wskazuje na zanik zasilania, przegrzanie albo niestabilny zasilacz, ale samo w sobie nie mówi która z tych przyczyn zadziałała. Identyfikator 1001 z BugCheck niesie kod niebieskiego ekranu, 7 i 51 z podsystemu dysku sygnalizują błędy odczytu sektorów, a wpisy WHEA-Logger opisują błędy sprzętowe zgłoszone przez procesor lub magistralę PCIe.

Sensowny raport zestawia te zdarzenia ze sobą w osi czasu. Seria błędów dysku poprzedzająca każdy niebieski ekran wskazuje na nośnik, natomiast wpisy WHEA pojawiające się wyłącznie pod obciążeniem częściej oznaczają problem z zasilaniem albo pamięcią.

Pułapki, przez które raport wprowadza w błąd

Dzienniki Windows mają domyślnie ograniczony rozmiar i po jego przekroczeniu nadpisują najstarsze wpisy. Jeżeli komputer restartuje się kilka razy dziennie, ślad sprzed tygodnia zwyczajnie już nie istnieje — dlatego przy nawracającej usterce pierwszą czynnością powinno być zwiększenie limitu, a nie analiza. Druga pułapka to strefa czasowa: pliki EVTX przechowują znaczniki czasu w UTC, a Podgląd zdarzeń przelicza je na czas lokalny, więc porównywanie eksportu z logiem aplikacji potrafi dać przesunięcie o godzinę lub dwie.

Trzecia rzecz to fałszywe tropy. Ostrzeżenia o usługach uruchamianych z opóźnieniem czy błędy DistributedCOM zapełniają dziennik na każdej sprawnej maszynie i nie mają nic wspólnego z awarią, którą się bada.

Analiza dziennika jako pierwszy krok diagnozy

Przy zgłoszeniach typu „komputer sam się wyłącza” albo „program raz na kilka dni znika z ekranu” zaczynamy właśnie od dzienników, bo pozwalają odróżnić usterkę sprzętową od konfliktu oprogramowania jeszcze przed rozkręceniem obudowy. Zestawienie zdarzeń zderzamy potem z odczytami SMART nośnika i testem pamięci, a przy serwerach z bazą SQL dokładamy dziennik samej instancji, gdzie widać zerwane sesje i przekroczone limity. Diagnoza laptopa przy odbiorze nic nie kosztuje, więc klient poznaje przyczynę zanim zdecyduje o zakresie naprawy.