PowerShell i logi, czyli wszystko, co musisz wiedzieć o pracy z Dziennikiem Zdarzeń

Każdego dnia podczas pracy twój komputer wykonuje setki rozmaitych zadań, o których nie zawsze informuje, wysyłając odpowiednie powiadomienie na ekranie.Czy zastanawiałeś się kiedyś jak sprawdzić, co dokładnie dzieje się w systemie? Otóż okazuje się, że każdy komputer prowadzi coś na kształt cyfrowego dziennika, w którym zapisuje wszystko, co się wydarzyło. Jak taki dziennik zdarzeń otworzyć, odczytać i nie pogubić się w tym wszystkim? Za chwilę wszystkiego się dowiesz. 

Czym jest dziennik zdarzeń i logi?

Zanim jednak przejdziemy do sedna zagadnienia i zagłębimy się w odnajdywanie i odczytywanie konkretnych zdarzeń, w pierwszej kolejności warto przyjrzeć się samym wpisom. Każdy wpis (inaczej log) jest pewnego rodzaju cyfrowym komunikatem, który zawiera informacje o zaistniałym zdarzeniu. Zdarzenia mogą występować w obrębie systemu operacyjnego, jak i w zainstalowanym oprogramowaniu, a także być generowane przez inne dodatkowe urządzenia dołączone do twojego komputera.

W większości przypadków zdarzenia podzielone są na kategorie i zapisywane chronologicznie do oddzielnych plików, wspólnie tworząc tzw. Dziennik zdarzeń (Event Log). Pliki logów z reguły zapisywane i przechowywane są lokalnie na komputerze. W nieco bardziej zaawansowanym scenariuszu logi przesyłane są do serwerów z wyspecjalizowanym oprogramowaniem SIEM (Security Information and Event Management), które dokonuje analizy oraz archiwizacji dzienników. Cały ten proces utrwalania zdarzeń w systemie komputerowym nazywa się rejestrowaniem i jest on niezwykle istotny z punktu widzenia monitorowania oraz debugowania działania systemu. Ponieważ wiele osób korzysta z systemu (przykładowo w organizacji) ,dziennik zdarzeń jest również cennym źródłem dotyczącym aktywności użytkowników.

Budowa

W zależności od systemu operacyjnego, konkretnego urządzenia czy danej aplikacji wygląd poszczególnych, generowanych komunikatów może się różnić, jednak zwykle da się wyróżnić pewne cechy wspólne. 

Indeks (Index) – liczba porządkowa, przypisywana w kolejności rosnącej;

Znacznik czasowy (Time lub Timestamp) – specjalny znacznik dodawany do dokumentu cyfrowego (w naszym przypadku logu) zwykle świadczący o jego powstaniu. W większości przypadków składa się z daty oraz czasu;

Poziom (Level lub EntryType) – kwalifikacja istotności zdarzenia, w systemie Windows wyróżniamy 5 poziomów ważności, o czym będzie nieco dalej;

Źródło (Source) – nazwa programu, procesu lub użytkownika, którego działanie doprowadziło do powstania wpisu;

Identyfikator zdarzenia (Event ID) – każde zdarzenie posiada unikalny identyfikator w celu jednoznacznej identyfikacji;

Wiadomość (Message) – krótka wiadomość tekstowa, częściowo wyjaśniająca przyczynę wpisu.

💡Warto wiedzieć

W świecie IT szeroko stosowanym standardem rejestrowania jest Syslog, zdefiniowany w dokumencie Internet Engineering Task Force (IETF) RFC 5424. Standard ten udostępnia dedykowany, standaryzowany podsystem do generowania, filtrowania, rejestrowania i analizowania komunikatów dziennika. Dzięki czemu twórcy oprogramowania nie muszą już martwić się o projektowanie i kodowanie własnego systemu rejestrowania zdarzeń.

Dziennik zdarzeń

W większości przypadków pliki logów to po prostu pliki tekstowe, których analiza może niekiedy doprowadzić do bólu głowy. Z tego też powodu do pomocy wykorzystuje się różnego rodzaju narzędzia. W systemie Windows do tego celu służy między innymi Dziennik zdarzeń (Event Viewer). Jest to wbudowana aplikacja posiadająca interfejs graficzny, która umożliwia nie tylko podgląd, ale również zarządzanie oraz konfigurację wszystkich dzienników zdarzeń. W celu uruchomienia wystarczy w menu start wyszukać dziennik zdarzeń lub skorzystać ze skrótu klawiszowego Win+R, a następnie w oknie wpisać eventvwr.

Ilustracja 1. Poglądowy wygląd okna dziennika zdarzeń.

Dziennik zdarzeń, jak większość przystawek do konsoli MMC (Microsoft Management Console) składa się z trzech części. Drzewo katalogów po lewej, panel akcji po prawej oraz panel informacyjny po środku, w którym to można przeglądać wpisy z dziennika. Sam dziennik posiada strukturę hierarchiczną i jest podzielony na różne kategorie oraz poziomy. Analizując katalog Windows Logs, który skupia główne logi systemu, możemy wyróżnić pięć podstawowych typów rejestrowanych zdarzeń:

Każda kategoria ma dodatkowe podkategorie, które pomagają klasyfikować różne zdarzenia. W ramach każdej podkategorii wydarzenia zorganizowane są w formie rekordów, które zawierają szczegółowe informacje na temat konkretnego wydarzenia. Po wejściu do Podglądu zdarzeń i wybraniu opcji Utwórz widok niestandardowy możesz wyszukiwać określone zdarzenia, filtrować według kategorii, poziomu ważności, słów kluczowych lub źródła oraz eksportować dzienniki do dalszej analizy. Proces ten pozwala administratorom systemu oraz technikom pomocy identyfikować i rozwiązywać problemy, a także monitorować i oceniać ogólną wydajność systemu.

Ilustracja 2. Poglądowy wygląd okna Tworzenie widoku niestandardowego.

Dodatkowo w celu kategoryzowania zdarzeń na podstawie ich ważności i wpływu na system zastosowano podział na poziomy istotności. W systemie Windows rozróżnia się następujące poziomy:

Te poziomy zdarzeń pozwalają administratorom na klasyfikowanie i monitorowanie różnych aspektów działania systemu, a także na diagnozowanie problemów i reagowanie na nie w odpowiedni sposób. Dzięki nim możliwe jest skuteczne zarządzanie zdarzeniami w systemie Windows.

PowerShell i dziennik zdarzeń

Chociaż dziennik zdarzeń jest nieocenionym narzędziem jeżeli chodzi o pracę z logami to czasami, w niektorych specyficznych aspektach może się okazać nieco oporny. Wtedy z pomocą może przyjść PowerShell i specjalne cmdlety, które wykonają za nas całą pracę. Get-EventLog oraz Get-WinEvnet bo o nich tutaj mowa to dwa podstawowe polecenia służące do obsługi dziennika zdarzeń. Zobaczmy kilka przykładów działania w praktyce:

PS C:\Users\Admin> Get-EventLog -LogName System -Newest 10

   Index Time          EntryType   Source                 InstanceID Message
   ----- ----          ---------   ------                 ---------- -------
   43843 Apr 16 20:37  Information Service Control Man…   1073748864 The start type of the Usługa inteligentnego trans…
   43842 Apr 16 20:34  Information Service Control Man…   1073748864 The start type of the Usługa inteligentnego trans…
   43841 Apr 16 20:27  Information Microsoft-Windows-K…          566 The description for Event ID '566' in Source 'Mic…
   43840 Apr 16 19:36  Information Microsoft-Windows-T…          158 The time provider 'VMICTimeProvider' has indicate…
   43839 Apr 16 19:18  Information Microsoft-Windows-T…          158 The time provider 'VMICTimeProvider' has indicate…
   43838 Apr 16 19:01  Information Microsoft-Windows-T…          158 The time provider 'VMICTimeProvider' has indicate…
   43837 Apr 16 18:55  Information Service Control Man…   1073748864 The start type of the Usługa inteligentnego trans…
   43836 Apr 16 18:54  Information Microsoft-Windows-K…          566 The description for Event ID '566' in Source 'Mic…
   43835 Apr 16 18:53  Information Service Control Man…   1073748864 The start type of the Usługa inteligentnego trans…
   43834 Apr 16 18:44  Information Microsoft-Windows-T…          158 The time provider 'VMICTimeProvider' has indicate…

Cmdlet Get-EventLog wyświetla wpisy z dziennika zdarzeń. Zanim jednak to nastąpi konieczne jest określenie konkretnego dziennika. W omawianym przypadku bedzie to dziennik System. W celu zwrócenia 10 najnowszych wpisów posłużymy się parametrem  -Newest z wartością 10.

Jedną z zalet korzystania z PowerShella jest możliwość odpytania zdalanych maszyn o ich dzienniki zdarzeń (chociaż Event Viewer również daje taką możliwość). W kolejnym przykładzie przyjrzymy się właśnie takiemu scenariuszowi, a mówiąc dokładniej postaramy się wyświetlić 5 ostatnich błędów z dziennika Aplikacje na zdalnym serwerze.

Get-EventLog -LogName Application –EntryType Error -ComputerName D01 –Newest 5 | Select MachineName, TimeGenerated, Source, Message 

Ilustracja 3. Wyświetlenie 5 ostatnich błędów na komputerze zdalnym z dziennika aplikacje

Cmdlet Get-EventLog podobnie jak to miało miejsce poprzednio, wykorzystuje parametr -LogName do określenia konkretnego dziennika zdarzeń, w tym wypadku będzie to Applicaction. Parametr –EntryType wskazuje na rodzaj wpisu i w prezentowanym przykładzie jest to Error (błąd). Kolejny parametr -ComputerName wykorzystuje ciąg znaków, aby wprowadzić nazwę zdalnego komputera lub listy komputerów, z których mają być pobierane wpisy dziennika zdarzeń. Natomiast dzięki zastosowaniu –Newest wyświetlamy tylko określoną liczbę najnowszych wpisów. Aby wynik był nieco bardziej przejrzysty przekazujemy wszystko do cmdletu Select-Object i wybieramy tylko interesujące nas zestaw danych. Mówiąc nieco dokładniej bedzie to: MachineName (nazwa komputera), TimeGenerated (czas wygenerowania zdarzenia), Source (źródło zdarzenia) oraz Message (tekst wiadomości).

Jeżeli chodzi o drugi z cmdletów to działa on bardzo podobnie. Jest to młodszy i potężniejszy brat Get-EventLog. Przez zastosowanie innej architektury posiada dostęp do znacznie większej liczby logów oraz rozbudowanej możliwości filtrowania. W omawianym przypadku przyjrzymy się wykorzystaniu tablicy mieszającej i spróbujemy odnaleźć czas ostatniego zamknięcia komputera.

PS C:\Users\Admin> Get-WinEvent -FilterHashtable @{LogName='System'; ID='6008'} -MaxEvents 1

   ProviderName: EventLog

TimeCreated                     Id LevelDisplayName Message
-----------                     -- ---------------- -------
17/03/2025 10:11:57           6008 Error            The previous system shutdown at 22:04:41 on ‎16.‎03.‎2025 was unexpected.

Cmdlet Get-WinEvent podobnie jak to miało miejsce wcześniej odpowiedzialny jest za wyświeltanie wpisów z dziennika zdarzeń. Jendkaże dla odmiany w tym wypadku skorzystamy z parametru –FilterHashTable, który określa zapytanie w formacie tabeli mieszającej w celu wybrania zdarzeń z jednego lub więcej dzienników. W naszym przypadku podajemy szukane wartości: LogName (nazwę dziennika logów) oraz ID konkretnego zdarzenia.

Więcej na temat metod filtrowania logów znajdziesz w artykule: PowerShell i 4 metody filtrowania dziennika zdarzeń

💡Warto wiedzieć

W systemie Windows identyfikatory zdarzeń (Event IDs) są używane do identyfikowania różnych rodzajów zdarzeń i błędów, co jest pomocne przy diagnozowaniu problemów systemowych. Istnieje wiele różnych ID zdarzeń, a te najistotniejsze zależą od kontekstu i rodzaju systemu oraz jego zastosowań. Niemniej jednak, istnieje kilka powszechnie znanych i ważnych ID zdarzeń, które są często omawiane przez administratorów systemów. Oto kilka z nich:

1102 Dziennik inspekcji został wyczyszczony
4616 Czas systemowy został zmieniony
4624 Udane logowanie do konta
4625 Nieudane logowanie do konta
4634 Konto zostało wylogowane
4657 Zmieniono wartość rejestru
4697 Podjęto próbę zainstalowania usługi
4719 Zmieniono zasady audytu systemu
4720 Utworzono konto użytkownika
4723 Podjęto próbę zmiany hasła do konta

Kiedy NIE używać Get-EventLog

Choć Get-EventLog wydaje się wygodnym i intuicyjnym narzędziem, jego możliwości są dość ograniczone i w wielu sytuacjach nie będzie najlepszym wyborem. W praktycznym środowisku administracyjnym warto świadomie ocenić, czy ten cmdlet spełnia wymagania zadania. Zobaczmy, teraz kiedy może okazać się niewystarczający:

Gdy pracujesz na nowszych systemach Windows i potrzebujesz dostępu do wszystkich dzienników

Get-EventLog obsługuje wyłącznie klasyczne dzienniki oparte na formacie Event Log API (Application, System, Security).
Nie odczytuje:

• dzienników opartych na Event Tracing for Windows (ETW),
• wielu logów aplikacyjnych i diagnostycznych,
• logów usług takich jak Windows Defender, PowerShell, TerminalServices czy DHCP-Client.

Jeżeli musisz analizować logi spoza podstawowych kanałów — używaj Get-WinEvent.

Gdy kluczowa jest wydajność lub filtrowanie po stronie źródła

Get-EventLog zawsze pobiera pełne wpisy i dopiero później pozwala na filtrowanie. Przy dużych zbiorach logów (dziesiątki tysięcy rekordów) może oznaczać to:

• większe zużycie pamięci,
• wolniejsze działanie,
• niepotrzebny transfer danych przy odczycie zdalnym.

Get-WinEvent -FilterHashtable filtruje na poziomie systemu logów, dostarczając tylko potrzebne rekordy.

Gdy zależy Ci na analizie czasu zdarzeń

Get-EventLog nie umożliwia precyzyjnego filtrowania po czasie przy użyciu natywnych parametrów. W przypadku zadań takich jak:

• pobieranie logów z ostatnich X minut,
• analiza zdarzeń w konkretnym zakresie dat,
• korelacja zdarzeń w złożonych scenariuszach,

zdecydowanie lepszym wyborem będzie Get-WinEvent.

Gdy pracujesz z dużą liczbą komputerów zdalnych

Przy odczycie z wielu hostów Get-EventLog jest wyraźnie mniej stabilny i mniej wydajny niż Get-WinEvent. Czasami może wystąpić:

• timeout przy większych logach,
• problemy z serwisem Event Log Service,
• dłuższy czas odpowiedzi.

Get-WinEvent obsługuje bardziej nowoczesny mechanizm komunikacji, co zapewnia wyższą niezawodność.

Gdy chcesz budować automatyzację lub zaawansowane pipeline’y

Get-EventLog oferuje uproszczony zestaw właściwości w porównaniu do Get-WinEvent, co dla automatyzacji może oznaczać mniejszą kontrolę nad:

• EventRecordId,
• pełnymi metadanymi zdarzenia,
• kanałem i poziomem zdarzenia,
• strukturą komunikatu.

Jeżeli tworzysz skrypty mające działać niezawodnie w różnych środowiskach, warto od razu korzystać z Get-WinEvent.

Zajętość dzienników zdarzeń w systemie Windows odnosi się do ilości miejsca zajmowanego przez zapisywane logi systemowe, aplikacyjne oraz zabezpieczeń. Warto monitorować poziom ich zapełnienia, ponieważ przepełnione dzienniki mogą prowadzić do nadpisywania starszych wpisów, co skutkuje utratą cennych danych diagnostycznych i śledczych. Regularna kontrola pozwala na wczesne wykrywanie nieprawidłowości, takich jak błędy systemowe, próby nieautoryzowanego dostępu czy awarie aplikacji. Dzięki temu administratorzy mogą szybciej reagować na problemy i zwiększyć bezpieczeństwo oraz stabilność środowiska IT. W kolejnym przykładzie zademonstruję jak w prosty sposób można monitorować zajętość dzienników:

PS C:\Users\Admin> Get-WinEvent -ListLog Application, System, Setup | Select-Object LogName, Logtype, LogMode, RecordCount, @{Name="Zajętość"; Expression={"{0,6:P0}" -f ($_.FileSize/$_.MaximumSizeInBytes)}} | ft

LogName            LogType  LogMode RecordCount Zajętość
-------            -------  ------- ----------- --------
Application Administrative Circular       15330    55%
System      Administrative Circular       37084   100%
Setup          Operational Circular        2434   100%

W rezultacie wykonane polecenie PowerShella pobiera informacje o dziennikach zdarzeń systemu Windows: Application, System i Setup. Wyświetla ich nazwę, typ, tryb zapisu, liczbę wpisów oraz procentowe zapełnienie (zajętość pliku dziennika względem jego maksymalnego rozmiaru). Dane są pokazane w formie tabeli, co pozwala szybko ocenić stan dzienników i ewentualną potrzebę ich oczyszczenia lub analizy. Zamiast pokazanych w przykładzie dzienników możesz oczywiście zastosować dowolne, dzięki czemu będziesz miał podgląd na interesujące Cię dane.

Jeżeli chodzi o atrybut LogMode odpowiedzialny jest za sposób w jaki zachowa się dziennik zdarzeń w momencie przepełnienia. W zależności od istotności danego dziennika możemy wyróżnić 3 tryby:

Twoje własne logi

No dobrze wiemy już jak wyciągać informacje o konkretnych logach. Jednakże wszystkie dotychczasowe zapisy zdarzeń, które mogłeś zaobserwować, były tworem projektantów systemu Windows lub danej aplikacji. Co, jeżeli chciałbyś dodać swoje własne zdarzenia? Czy jest to możliwe? Okazuje się, że tak i wcale nie jest to jakoś strasznie skomplikowane. Aby tego dokonać, będziemy potrzebowali czterech rzeczy. Po pierwsze PowerShella z uprawnieniami administratora. Następnie należy skorzystać z odpowiedniego cmdletu. W tym wypadku będzie to New-EventLog, który odpowiedzialny jest za utworzenie nowego klasycznego dziennika zdarzeń na komputerze lokalnym lub zdalnym. Może również zarejestrować źródło zdarzeń, które zapisuje dane w nowym dzienniku lub w już istniejącym. Trzecim elementem będzie nazwa naszego nowego dziennika, w omawianym przykładzie posłużę się nazwą „ProwerShellZone”. Kolejnym, a tym samym ostatnim elementem układanki jest określenie źródła zdarzeń zapisywanych w dzienniku. W moim przypadku będzie to „Moje Zdarzenie”. Teraz czas na polecenie, które tworzy nowy tradycyjny dziennik zdarzeń.

PS C:\Windows\System32> New-EventLog -LogName 'PowerShellZone' -Source 'Moje zdarzenie'

Po uruchomieniu polecenia w konsoli PowerShell domyślnie nie pojawiają się żadne dane wyjściowe. Aby upewnić się, że polecenie faktycznie utworzyło nowy dziennik zdarzeń, użyjemy cmdletu Get-EventLog z parametrem -List.

PS C:\Windows\System32> Get-EventLog -List

  Max(K) Retain OverflowAction        Entries Log
  ------ ------ --------------        ------- ---
  20,480      0 OverwriteAsNeeded      15,526 Application
  20,480      0 OverwriteAsNeeded           0 HardwareEvents
     512      7 OverwriteOlder              0 IntelAudioServiceLog
     512      7 OverwriteOlder              0 Internet Explorer
  20,480      0 OverwriteAsNeeded           0 Key Management Service
     128      0 OverwriteAsNeeded         173 OAlerts
     512      7 OverwriteOlder            508 OneApp_IGCC
     512      7 OverwriteOlder              0 PowerShellZone
  20,480      0 OverwriteAsNeeded      32,398 Security
  20,480      0 OverwriteAsNeeded      37,153 System
  15,360      0 OverwriteAsNeeded       7,483 Windows PowerShell

Jak widzisz, dziennik został utworzony. Co prawda posiada on standardowe właściwości tzn. może magazynować maksymalnie 512 KB danych i będzie przechowywał wpisy przez 7 dni, po czym zacznie usuwać starsze zdarzenia. Jednakże na potrzeby szkoleniowe to nam zupełnie wystarczy. Oczywiście nic nie stoi na przeszkodzie, abyś zmienił te wartości. Zanim jednak tego dokonasz, warto byłoby coś do niego zalogować.

W tym wypadku również będziemy potrzebować kilku rzeczy. Pierwszym elementem będzie odpowiedni cmdlet, w tym wypadku najlepszym wyborem będzie Write-EventLog, który służy właśnie do pisania do istniejącego pliku dziennika zdarzeń. W kolejnym kroku należy określić nazwę dziennika oraz nazwę źródła dla zapisywanych zdarzeń. Dane te posiadamy z poprzedniego zadania.  Następnie powinniśmy podać ID zdarzenia, w tym wypadku zwykle zaczyna się od 0 (warto pamiętać, że w PowerShellu prawie zawsze numeracja zaczyna się od zera). Kolejną istotną wartością jest rodzaj informacji, zatem czy będzie to ostrzeżenie, błąd czy zwykła informacja. Dla celów szkoleniowych zostańmy przy informacji. Ostatnim elementem będzie wiadomość, którą chcemy przekazać w naszym wpisie. Całość polecenia prezentuje się następująco:

PS C:\Windows\System32> Write-EventLog -LogName PowerShellZone -Source 'Moje Zdarzenie' -Message “Chyba się udało” -EventId 0 -EntryType Information

Wykonanie polecenia również domyślnie nie zwróci żadnych danych. Jeżeli jednak podejrzymy dziennik zdarzeń PowerShellZone za pomocą cmdletu Get-EventLog z nazwą naszego dziennika. To naszym oczom ukarze się:

PS C:\Windows\System32> Get-Eventlog -LogName PowerShellZone

   Index Time          EntryType   Source                 InstanceID Message
   ----- ----          ---------   ------                 ---------- -------
       1 Apr 18 08:15  Information Moje Zdarzenie                  0 Chyba się udało

Jak widzisz cała operacja przebiegła pomyślnie. Zastanawiasz się pewnie teraz, do czego taka umiejętność może się przydać? Otóż projektując swoje automatyczne rozwiązania, a mam tutaj na myśli skrypty czy funkcje dobrą praktyką jest monitorowanie i raportowanie ich działania. Na przykład możesz utworzyć specjalny dziennik zdarzeń dla swojej aplikacji, która będzie raportować poprawne działanie, natomiast w przypadku niepowodzenia pojawi się wpis o błędzie. Dzięki temu będziesz w stanie łatwo monitorować jej działanie i szybko zdiagnozować i zareagować na potencjalne problemy. 

Przykłady praktyczne

Poniżej zamieściłem kilka przykładów, które pokazują, jak w codziennej pracy administratora można wykorzystać PowerShell do analizy, filtrowania i archiwizowania logów w systemie Windows. Każdy przykład możesz przećwiczyć bez dodatkowej konfiguracji na lokalnym komputerze.

Pobranie ostatnich błędów systemowych

Kiedy użytkownik zgłasza, że „coś nie działa”, pierwszym krokiem jest sprawdzenie, czy system zapisał błędy w dzienniku.

PS C:\Users\Admin> Get-WinEvent -LogName System -MaxEvents 20 | Where-Object {$_.LevelDisplayName -eq 'Error'} | 
Select-Object TimeCreated, Id, LevelDisplayName, ProviderName, Message


TimeCreated      : 07/12/2025 16:56:45
Id               : 20
LevelDisplayName : Error
ProviderName     : Microsoft-Windows-WindowsUpdateClient
Message          : Installation Failure: Windows failed to install the following update with error 0x80073D02: 9NKSQGP7F2NH-5319275A.WhatsAppDesktop.

TimeCreated      : 07/12/2025 16:56:34
Id               : 20
LevelDisplayName : Error
ProviderName     : Microsoft-Windows-WindowsUpdateClient
Message          : Installation Failure: Windows failed to install the following update with error 0x80073D02: 9PC1H9VN18CM-Microsoft.StartExperiencesApp.

Co tu się dzieje?

• Na początekGet-WinEvent z dwoma parametrami -LogName, który określa konkretny dziennik, w tym wypadku System oraz -MaxEvents, dzięki któremu koncentrujemy się na 20 ostatnich zdarzeniach.
• Te ostatnie zdarzenia przekazujemy do Where-Object, które za pomocą filtra {$_.LevelDisplayName -eq 'Error'} wyszukuje tylko te zdarzenia, które mają poziom „Error”.
• NastępnieSelect-Object i wybieramy tylko TimeCreated, Id, LevelDisplayName, ProviderName, Message, czyli pięć właściwości dla lepszej przejrzystości.

Wyszukanie zdarzeń związanych z restartami systemu

Może się zdarzyć, że potrzebujesz ustalić, kiedy komputer był włączany, restartowany lub niespodziewanie wyłączony, możesz przeszukać dziennik System po kluczowych ID:

• 6005 – start usługi logowania (start systemu)
• 6006 – zatrzymanie usługi logowania (shutdown)
• 6008 – nieoczekiwane wyłączenie

PS C:\Users\Admin> Get-WinEvent -FilterHashtable @{LogName='System'; ID=6005,6006,6008} | Select-Object TimeCreated, Id, Message

TimeCreated           Id Message                                                                 
-----------           -- -------                                                                 
06/12/2025 09:58:22 6005 The Event log service was started.                                      
06/12/2025 09:57:27 6006 The Event log service was stopped.                                      
13/11/2025 21:07:58 6005 The Event log service was started.                                      
13/11/2025 21:07:10 6006 The Event log service was stopped.                                      
13/11/2025 21:05:22 6005 The Event log service was started.                                      
13/11/2025 21:04:27 6006 The Event log service was stopped.  

Co tu się dzieje?

• Cmdlet Get-WinEvent z parametrem -FilterHashtable, w którym definiujemy kryteria filtrowania, czyli LogName oraz ID.
• Na zakończenie cmdletSelect-Object i wybieramy TimeCreated, Id, Message.
• W wyniku seria informacji o ostatnim wyłączeniu komputera.

Sprawdzenie błędów aplikacji Outlook, Teams, Office

W wielu firmach najczęściej analizowane są logi aplikacyjne. Kiedy użytkownik zgłasza problemy z Outlookiem, możesz zrobić coś takiego:

PS C:\Users\Admin> Get-WinEvent -FilterHashtable @{LogName='Application'; ProviderName='*Outlook*'} | Select-Object TimeCreated, Id, Message -First 10

TimeCreated         Id Message                                                                                                                                                  
-----------         -- -------                                                                                                                                                  
06/12/2025 17:35:41 45 Program Outlook załadował następujące dodatki:...   
05/12/2025 17:21:30 45 Program Outlook załadował następujące dodatki:...    
05/12/2025 13:59:30 45 Program Outlook załadował następujące dodatki:...     
05/12/2025 11:59:21 45 Program Outlook załadował następujące dodatki:... 

Co tu się dzieje?

• Podobnie jak poprzednio cmdlt Get-WinEvent i odpowiednio sformowany parametr -FilterHashtablepozwala na przeszukanie odpowiednich wpisów z dziennika zdarzeń.
• Następnie Select-Object i wybór tylko najpotrzebniejszych właściwości, w tym -First 10, czyli ograniczenie do 10 ostatnich wyników.

Eksport zdarzeń do pliku CSV (do analizy lub wysłania do działu IT)

Czasami logi trzeba przekazać dalej lub poddać szczegółowej analizie. Wtedy pomocny może okazać się format CSV.

PS C:\Users\Admin> Get-WinEvent -LogName System -MaxEvents 200 | 
Select-Object TimeCreated, Id, LevelDisplayName, ProviderName, Message |
Export-Csv -Path "C:\Temp\system_logs.csv" -NoTypeInformation -Encoding UTF8

Co tu się dzieje?

• Za pomocą cmdletu Get-WinEvent oraz parametru -MaxEvents z wartością 200 generujemy 200 wpisów z dziennika System.
• Następnie wrzucamy to na Select-Object i wybieramy tylko to, co może okazać się pomocne.
• Na koniec Export-CSV i podajemy ścieżkę do zapisu (parametr -Path), a także pozbywamy się nagłówka (-NoTypeInformation), oraz ustawiamy odpowiednie enkodowanie UTF8.

Wyszukiwanie logów po słowach kluczowych

Czasami należy przeprowadzić analizę na podstawie konkretnej frazy w komunikacie:

PS C:\Users\Admin> Get-WinEvent -LogName Application | Where-Object {$_.Message -match 'timeout'} | Select-Object TimeCreated, Id, Message

TimeCreated           Id Message                                               
-----------           -- -------                                               
07/12/2025 16:59:53 8224 The VSS service is shutting down due to idle timeout. 
06/12/2025 11:01:22 8224 The VSS service is shutting down due to idle timeout. 
05/12/2025 19:11:49 8224 The VSS service is shutting down due to idle timeout. 
05/12/2025 12:07:47 8224 The VSS service is shutting down due to idle timeout. 

Co tu się dzieje?

• Na początek pobieramy zdarzenia z dziennika Application.
• Następnie sprawdzamy gdzie w wiadomości (czyli w Message) znajduje się wyraz timeout.
• Ostatnim elementem jest wybór odpowiednich właściwości.

Archiwizacja całego dziennika zdarzeń

Jednym z zadań administratorów jest archiwizacja dziennika zdarzeń:

PS C:\Users\Admin> wevtutil epl Application "C:\Temp\Application.evtx"

Co tu się dzieje?

• Tym razem skorzystamy ze wbudowanego narzędzia Windowswevtutil, które służy do zarządzania dziennikami zdarzeń z poziomu wiersza poleceń.
• Parametr epl oznacza export log, czyli wyeksportowanie zawartości dziennika do pliku.
• Application wskazuje, że eksportujemy dziennik Aplikacji systemu Windows.
• Następnie podajemy ścieżkę oraz nazwę pliku, do którego zostanie wyeksportowany dziennik. W tym wypadku będzie to"C:\Temp\Application.evtx".

Przechowywanie i Archiwizacja

Wiesz już jak wyświetlać i tworzyć własne wpisy do dziennika zdarzeń. Wiesz również, że w zależności od konkretnych ustawień dzienniki mogą się różnie zachowywać w czasie. Do pełni sukcesu brakuje jeszcze kilku informacji o przechowywaniu i archiwizacji zdarzeń. Dlatego teraz nieco naświetlę ten temat.

W zależności od poziomu istotności logów oraz przyjętej polityki bezpieczeństwa stosowane są różne podejścia do przechowywania i archiwizowania dzienników zdarzeń. Niekiedy logi w ogóle nie są archiwizowane a jedynie przechowywane przez krótki czas (na przykład tydzień). Spotyka się również sytuacje, (choć należą one raczej do rzadkości), że niektóre logi wcale nie są zapisywane. Z drugiej strony są organizację, które na mocy pewnych regulacji prawnych mają obowiązek archiwizować konkretne dzienniki zdarzeń nawet na kilka lat. Dlaczego zatem warto poświęcić trochę pracy i posiadać zarchiwizowane zdarzenia? Przede wszystkim może się to przydać w celu analizy zjawisk z przeszłości. Brak logów uniemożliwia przegląd zjawisk, które miały miejsce w przeszłości. Przykładowo może to być przebieg włamania komputerowego lub wykrycie nadużyć w działaniu administratora czy użytkownika. Dzienniki zdarzeń mogą być również ważnym elementem umożliwiającym stwierdzenie czy nieprawidłowości w pracy systemu mają charakter jednorazowy, czy też występowały już wcześniej.

Oczywiście jak w przypadku większości rzeczy tak i przy przechowywaniu czy archiwizowaniu logów nie wolno przesadzić. Mam tutaj na myśli scenariusz, w którym chciałbyś gromadzić wszystko, co tylko się da. Poza szybkim zapełnianiem przestrzeni dyskowej miałbyś dodatkowo sporo pracy w odpowiedniej analizie tych wszystkich zdarzeń. Dlatego do przechowywania staraj się wybierać tylko te zdarzenia, które mogą mieć istotny wpływ na kluczowe elementy twojego systemu i twojej pracy.

Bezpieczeństwo

Ostatnią kwestią, jaką chciałbym poruszyć w tym artykule, są sprawy bezpieczeństwa, gdyż nawet tak zwyczajny proces, jak rejestrowanie, przechowywanie czy archiwizacja zdarzeń jest narażony na zagrożenia. Szczególnie jeżeli pliki logów wpadną w niepowołane ręce, może dojść do ujawnienia wrażliwych danych dotyczących personelu, jak i infrastruktury organizacji.

Do najczęstszych incydentów z wykorzystaniem dziennika zdarzeń możemy zaliczyć:

• Publicznie dostępne pliki dziennika
• Rejestrowanie poufnych informacji
• Niewystarczające rejestrowanie
• Zdolność do zatruwania wpisów dziennika
• Blokowanie (lub przeciążanie) systemów logowania

Czy jest możliwość zapobiegania tego typu zjawiskom? Oczywiście, stosując odpowiednie zasady, można znacznie ograniczyć ryzyko wystąpienia powyższych incydentów. Do reguł tych możemy zaliczyć:

• Wszystkie wrażliwe lub istotne zdarzenia są rejestrowane i monitorowane pod kątem podejrzanej aktywności.
•  Metoda używana do rejestrowania i przesyłania zdarzeń musi być odporna na fałszowanie, manipulowanie i usuwanie wpisów dziennika.
• Dostęp do dzienników zdarzeń dostępny jest tylko i wyłącznie o wąskiego grona uprawnionych osób takich jak np: zespół ds. bezpieczeństwa.

Prawidłowe zarządzanie rejestrowaniem zdarzeń nie jest łatwą sztuką, szczególnie w rozległych środowiskach. Odpowiednio zaimplementowane pozwala na zwiększenie bezpieczeństwa, wydajności i niezawodności systemu. Ułatwia diagnozę problemów i śledzenie działań użytkowników. Jest to kluczowy element efektywnego administrowania infrastrukturą IT.

Dla chętnych

Za pomocą poznanych cmdletów postaraj się wyświetlić:

• 10 najnowszych ostrzeżeń z dziennika System.
• Wszystkie błędy z dziennika Aplikacje.

• Zaprojektuj swój własny dziennik zdarzeń i rejestruj tam różne zdarzenia.
• Korzystając z narzędzia Dziennik zdarzeń lub PowerShella sprawdź, jak wygląda zajętość poszczególnych dzienników w twoim systemie.

---

To wszystko na dziś!

Jeśli masz ciekawe spostrzeżenia lub doświadczenia w tym temacie – koniecznie podziel się nimi w komentarzach.
A jeśli moje materiały są dla Ciebie pomocne, możesz postawić mi wirtualną kawę.

Dzięki za wsparcie!

Adam Pietrzak

Trener IT | Autor szkoleń | Entuzjasta PowerShella

Administrator systemów i sieci wsparcia działań wojskowych z ponad 10-letnim doświadczeniem. Praktyk w dziedzinie bezpieczeństwa systemu Windows, automatyzacji zadań (PowerShell) oraz rozwiązań chmurowych. Trener i twórca materiałów edukacyjnych (szkolenia, warsztaty, artykuły, podręczniki). Pasjonat dzielenia się wiedzą i wspierania początkujących administratorów IT. Prywatnie – amator aktywnego wypoczynku i rodzinnych podróży.

---