Get-WinEvent – logi systemowe z filtrowaniem

Get-WinEvent to nowocześniejsze polecenie PowerShell do odczytu logów systemowych z filtrowaniem, wydajniejsze niż starsze Get-EventLog.

Czym jest Get-WinEvent i do czego służą logi systemowe z filtrowaniem

Get-WinEvent to polecenie programu PowerShell przeznaczone do odczytywania zdarzeń zapisanych w dziennikach systemu Windows. Pozwala analizować informacje o uruchamianiu i zatrzymywaniu usług, błędach sterowników, problemach aplikacji, zmianach konfiguracji, zdarzeniach związanych z bezpieczeństwem oraz wielu innych procesach zachodzących w systemie. Sam log nie jest zwykłym plikiem tekstowym, lecz uporządkowanym zapisem zdarzenia zawierającym między innymi nazwę dziennika, źródło, identyfikator zdarzenia, poziom ważności, czas wystąpienia i opis przekazany przez system lub konkretny program.

Najważniejszą cechą tego polecenia jest możliwość ograniczenia wyników już na etapie odczytu. Zamiast pobierać tysiące wpisów i dopiero później przeszukiwać je ręcznie, można wskazać interesujący dziennik, przedział czasu, poziom zdarzenia, identyfikator albo źródło. Takie podejście ułatwia ustalenie, co wydarzyło się przed awarią, po aktualizacji, po nieoczekiwanym restarcie lub w chwili utraty dostępu do urządzenia. Filtrowanie ma znaczenie również praktyczne, ponieważ zmniejsza ilość danych zwracanych przez konsolę i pozwala skupić uwagę na zdarzeniach związanych z konkretnym objawem.

Przykładowe odczytanie kilku ostatnich zdarzeń z dziennika systemowego może wyglądać następująco:

Get-WinEvent -LogName System -MaxEvents 20

Wynik można następnie zawęzić według właściwości zdarzenia. Przydatne jest między innymi filtrowanie przez Where-Object, jednak w przypadku większych dzienników korzystniejsze bywa użycie parametru -FilterHashtable, ponieważ warunki są przekazywane do mechanizmu odczytu wcześniej. Przykładowa konstrukcja może ograniczać wyszukiwanie do wpisów z dziennika systemowego, pochodzących od określonego dostawcy i występujących od wskazanego momentu:

$od = (Get-Date).AddHours(-6)
Get-WinEvent -FilterHashtable @{
    LogName      = 'System'
    ProviderName = 'Service Control Manager'
    StartTime    = $od
}

Kontekst techniczny i porównanie sposobów analizy zdarzeń

W środowisku Windows zdarzenia są rozdzielane na różne dzienniki, między innymi System, Application i Security. Mogą być dostępne także dzienniki utworzone przez sterowniki, składniki systemowe oraz zainstalowane programy. Odczyt nie powinien zaczynać się od przypadkowego przeglądania wszystkiego. Najpierw warto powiązać objaw z obszarem, w którym prawdopodobnie powstał problem. Błąd uruchamiania usługi będzie zwykle analizowany w dzienniku systemowym, awaria konkretnej aplikacji może trafić do dziennika aplikacji, a nieudane logowanie wymaga sprawdzenia zdarzeń bezpieczeństwa, o ile dostęp do tego dziennika jest przyznany.

Get-WinEvent zastąpiło w wielu zadaniach starsze polecenie Get-EventLog. Różnica nie polega wyłącznie na nazwie. Nowsze polecenie obsługuje szerszy model zdarzeń systemu Windows, w tym dzienniki oparte na mechanizmie Windows Event Log oraz dostawców wykorzystujących kanały diagnostyczne. Dzięki temu może być używane przy analizie bardziej zróżnicowanych źródeł. Nie oznacza to jednak, że każde zdarzenie wyjaśni przyczynę problemu. Wpis często opisuje skutek albo etap procesu, a właściwa interpretacja wymaga zestawienia go z godziną wystąpienia, innymi zdarzeniami oraz zachowaniem komputera.

Do podstawowych filtrów należą między innymi:

• LogName – nazwa dziennika, który ma zostać odczytany;
• ProviderName – składnik lub dostawca zapisujący zdarzenie;
• Id – identyfikator określonego typu zdarzenia;
• Level – poziom, na przykład informacyjny, ostrzegawczy albo wskazujący błąd;
• StartTime i EndTime – początek oraz koniec analizowanego przedziału;
• Keywords – dodatkowe klasyfikacje stosowane przez system.

Przydatne jest również formatowanie wyniku. Polecenie Format-List pozwala wyświetlić pełniejszy opis pojedynczego zdarzenia, natomiast Select-Object może pozostawić tylko najważniejsze pola, takie jak czas, identyfikator i treść komunikatu. Do dalszej analizy można przekierować dane do pliku tekstowego lub tabeli, pamiętając, że eksport powinien zachować kontekst: nazwę dziennika, źródło, czas i identyfikator wpisu. Samo skopiowanie skróconego komunikatu często utrudnia późniejszą ocenę.

Typowe problemy, błędy i pułapki przy pracy z logami

Jednym z częstych błędów jest utożsamianie każdego wpisu typu Error z bezpośrednią przyczyną awarii. System może zarejestrować błąd po nieudanej próbie wykonania czynności, która była już skutkiem wcześniejszego problemu. Zdarzenia mogą też pojawiać się podczas normalnego uruchamiania, wyłączania lub aktualizacji. Dlatego pojedynczy identyfikator nie powinien być interpretowany w oderwaniu od chronologii. Znaczenie ma sekwencja: pierwszy nietypowy wpis, powtarzalność, moment pojawienia się objawu oraz zdarzenia następujące bezpośrednio po nim.

Drugą pułapką jest nieprawidłowe zawężenie czasu. Warto uwzględnić nieco szerszy przedział niż sama chwila awarii, ponieważ opóźnione komunikaty mogą zostać zapisane później, a przygotowanie do restartu lub utraty połączenia może rozpocząć się wcześniej. Należy także brać pod uwagę ustawienia czasu, strefę czasową i zmianę zegara systemowego. Gdy analizowany jest problem powtarzający się, pojedynczy krótki odcinek może nie wystarczyć do odróżnienia zdarzenia przypadkowego od regularnego wzorca.

Problemy może sprawiać również brak uprawnień. Niektóre dzienniki, zwłaszcza związane z bezpieczeństwem, wymagają uruchomienia PowerShell z odpowiednim poziomem dostępu. Odczyt może wtedy zakończyć się komunikatem o odmowie dostępu albo zwrócić niepełny obraz sytuacji. Nie powinno się automatycznie przyznawać szerokich uprawnień bez ustalenia, jaki zakres jest potrzebny. Bezpieczniej jest najpierw sprawdzić nazwę dziennika, dostępne kanały i wymagania konkretnego źródła.

Nie każdy komputer przechowuje dowolnie długą historię zdarzeń. Dzienniki mogą mieć ograniczony rozmiar, a starsze wpisy mogą zostać nadpisane. Intensywne czyszczenie logów utrudnia późniejszą diagnostykę, dlatego nie należy usuwać ich przed wykonaniem kopii lub zebraniem potrzebnych informacji. Należy też pamiętać, że treść komunikatu bywa zależna od wersji systemu, zainstalowanych składników i języka interfejsu. Wyszukiwanie wyłącznie po dosłownym tekście jest więc mniej trwałe niż użycie identyfikatora, dostawcy i czasu.

W praktyce mogą pojawić się również błędy składni, niepoprawna nazwa dziennika albo filtr zwracający pusty wynik. Pusty rezultat nie zawsze oznacza brak zdarzeń. Przyczyną może być zbyt wąski przedział czasu, niewłaściwy dostawca, inny kanał niż oczekiwany lub brak uprawnień. Dobrym sposobem weryfikacji jest rozpoczęcie od prostego odczytu kilku ostatnich wpisów, sprawdzenie rzeczywistych nazw pól, a dopiero później rozbudowanie filtra. Przy analizie skryptowej warto jawnie obsługiwać sytuację, w której zdarzeń nie znaleziono, zamiast traktować ją jako dowód, że system działa prawidłowo.

Kiedy trzeba zlecić diagnozę specjalistom - Get-WinEvent – logi systemowe z filtrowaniem

Samodzielna analiza Get-WinEvent może być pomocna, gdy problem jest dobrze określony, występuje powtarzalnie i wiadomo, jaki moment należy sprawdzić. Zgłoszenie do serwisu jest jednak zasadne, gdy komputer samoczynnie się restartuje, zawiesza, traci urządzenia, długo się uruchamia, wyświetla powtarzające się błędy albo po aktualizacji przestaje działać zgodnie z oczekiwaniami. Szczególnej uwagi wymaga sytuacja, w której w logach występują jednocześnie problemy sterownika, błędy systemu plików, ostrzeżenia dotyczące nośnika danych lub nieoczekiwane zamykanie systemu. Wtedy log jest materiałem pomocniczym, a nie pełną diagnozą.

Przed przekazaniem sprzętu warto zanotować dokładny objaw, częstotliwość występowania oraz przybliżony czas zdarzenia. Można również zachować kilka wpisów obejmujących okres przed awarią i po niej, bez modyfikowania oryginalnych dzienników. Tak przygotowane informacje ułatwiają powiązanie komunikatów programowych ze stanem urządzeń, zasilaniem, temperaturą, pamięcią masową i konfiguracją sterowników. W przypadku problemów z poufnymi danymi należy ograniczyć przekazywany materiał do niezbędnego zakresu, ponieważ opisy zdarzeń mogą zawierać nazwy kont, ścieżki katalogów lub informacje o używanych programach.

W Warszawie takie przypadki można przekazać do serwisu komputerowego, gdzie przed rozpoczęciem właściwych prac wykonywana jest darmowa diagnoza laptopa. Pozwala to zestawić wpisy z dzienników z objawami sprzętowymi i zachowaniem systemu, a następnie określić, czy przyczyny należy szukać w konfiguracji Windows, sterownikach, aplikacjach, nośniku danych czy innych podzespołach. Wnioski z logów powinny prowadzić do sprawdzalnej hipotezy i testu, a nie do wymiany elementów wyłącznie na podstawie jednego komunikatu.