Jakie są konsekwencje przekroczenia 4 GB w dzienniku zdarzeń systemu Windows?

Znalazłem ten KB KB, który obejmuje zalecane maksymalne ustawienia dziennika zdarzeń dla systemów operacyjnych do Windows 2008 / Vista , który zaleca maksymalnie 4 GB, i widziałem inne niejasne odniesienia, że ​​dziennik zdarzeń większy niż 4 GB nie jest zalecany przynajmniej 2008 R2, ale zastanawiam się, co się właściwie stanie, jeśli dziennik zdarzeń przekroczy ten rozmiar?

Przekroczyłem to na serwerze testowym (2012 R2) i nie zauważyłem niczego takiego jak wysokie zużycie pamięci itp. Nie dbamy o systemy operacyjne przed 2008 R2, ale chcemy dużego dziennika, ponieważ zbieramy zdarzenia z wielu maszyn za pośrednictwem Przekazywanie zdarzeń Windows i chcesz mieć wszystkie zdarzenia w jednym miejscu.

Poza straszną wydajnością i niedorzecznymi czasami oczekiwania, gdy trzeba załadować dziennik 4 GB i do diabła, będzie, jeśli kiedykolwiek będzie trzeba przeszukiwać tak potworne rzeczy, niewiele. Myślę, że największy, jaki widziałem w moich środowiskach, to 10 GB i chociaż zrezygnowałem z czekania na załadowanie, nie wydawało się to nic szkodzić.

Uwaga 4 GB dla Server 2008 wynika z tego 32-bitowego limitu, który często występuje przy 4 GB. W systemie 64-bitowym powinieneś pozwolić, aby osiągnął 16 TB (lub 64, zależnie), chociaż nie wiem, czy ktokolwiek zbliżył się do testowania tego limitu.

Oczywiście, jeśli jeszcze tego nie zrobiłeś, odkryjesz, że bardzo duże pliki dziennika są po prostu niepraktyczne w użyciu - ostatnim razem, gdy próbowałem załadować prosty plik dziennika 100 GB (tekstowy), nie można go nawet otworzyć bez zawieszenie aplikacji otwierającej ją i podejrzewam, że trafisz na ten problem na długo przed 100 GB.

O wiele lepszym rozwiązaniem jest ograniczenie rozmiaru pliku do rozsądnego poziomu i użycie skryptu, aby go wyczyścić od czasu do czasu. Używam poniżej w moim środowisku, w połączeniu z limitem wielkości 1 GB w naszym dzienniku bezpieczeństwa. Niektóre (cóż, większość) naszych serwerów generuje ponad 3 GB zdarzeń bezpieczeństwa dziennie i nie chcemy marnować całego miejsca na ogromne pliki dziennika, z których zrezygnuję przed przeszukaniem, więc mój skrypt kopiuje zawartość dziennika do innym folderze, a następnie usuwa dziennik zdarzeń, aby zapisać go ponownie. A ponieważ kopia zapasowa folderu, do którego je kopiuję, zawsze możemy wrócić do dzienników w okropnym wydarzeniu, którego potrzebujemy.

#Adapted from: http://blogs.technet.com/b/heyscriptingguy/archive/2009/04/08/how-can-i-check-the-size-of-my-event-log-and-then-backup-and-archive-it-if-it-is-more-than-half-full.aspx

Param($logName = "security",$backupFolder = "C:\backupLogs")

Function Get-EventLog([string]$logName)
{
 $log = Get-WmiObject -Class Win32_NTEventLogFile -filter "LogFileName = '$logName'"
 If($log.FileSize / $log.MaxFileSize -ge .9)
  {
   "Log is at least 90% full. Backing up now."
   Backup-EventLog($log)
  } #end if
 Else 
 { 
   "Not backed up: $logName is only " + ($log.FileSize / $log.MaxFileSize).tostring("N2") +  " percent full" 
 } #end else
} #end Get-EventLog

Function Backup-EventLog($log)
{
 $folder = Join-Path -Path $BackUpFolder -ChildPath (Get-Date).ToString("MMddyy_hhmm")
 If(-not(Test-Path $folder)) 
   { 
     New-Item -path $folder -itemtype Directory -force | out-Null
   }
  $rtn = $log.BackupEventLog("$folder\$logName.evt").ReturnValue
  If($rtn -eq 0)
    {
     $log.ClearEventLog() | out-null
    } #end if
 ELSE 
   {
    "$logName could not be cleared. Backup ended with $($rtn)" 
  }
} #end Backup-EventLog

# *** ENTRY POINT ***
Get-EventLog -logname $logname

Druga odpowiedź obejmuje uzasadnienie tego - w przypadku nowoczesnych systemów, głównie utrzymując czasy ładowania w graficznym interfejsie przeglądarki zdarzeń w pewnym stopniu znośnym. Dobrze jest również skopiować bieżący dziennik do miejsca, w którym zostanie utworzona kopia zapasowa, a następnie go wyczyścić.

Podczas analizowania dużych plików dziennika, które i tak generowane są, występują dwie dobre opcje:

1) Przetwarzaj dziennik szybciej niż bieżący GUI może zarządzać lub 2) Podziel dziennik na osobne pliki.

Jestem pewien, że istnieją pewne łatwo dostępne narzędzia dla 2), więc skupię się na 1).

Po pierwsze, Powershell ma doskonałe polecenie cmdlet dla tej funkcji o nazwie „get-winevent”. Najszybsza wydajność, jaką widziałem, polega na użyciu tabel skrótów. Oto przykład, w którym wszystkie zdarzenia w dzienniku bezpieczeństwa dotyczące określonego użytkownika od ostatniego dnia:

$timeframe = (get-date) - (new-timespan -day 1)
$userevt = Get-WinEvent -ComputerName <specify> -FilterHashTable @{LogName='Security'; Data='<enter username here>'; StartTime=$timeframe}

$ userevt jest teraz zbiorem wydarzeń. W zależności od liczby dopasowań możesz przepuścić go do listy formatów, aby łatwo odczytać niewielką liczbę zdarzeń. W przypadku średniej liczby zrób to samo, ale przekieruj dane wyjściowe do pliku:

$userevt | format-list > <outputfile>.txt

W przypadku dużej liczby rozpocznij filtrowanie (powiedz, że chcesz, aby komputer wywołujący blokował zdarzenie zablokowane przez użytkownika, którego pozyskaliśmy powyżej):

$userevt | %{if ($_.message -match "Caller Computer .*") {$matches[0]}}

Spowoduje to wyświetlenie wyniku w jednym wierszu dla każdego zdarzenia blokady. Powyższe procesy zwykle trwają 1–4 minuty dla dziennika 4 GB w 2008 R2.

Po drugie, szczególnie w przypadku komputerów z 2003 r., Którymi możesz zarządzać, możesz kliknąć prawym przyciskiem myszy konkretny plik dziennika w lewym okienku w przeglądarce zdarzeń i wybrać opcję „zapisz plik dziennika jako”.

Jeśli korzystasz z przeglądarki zdarzeń na komputerze lokalnym, możesz zapisać plik .evt, który może zostać przeanalizowany przez get-winevent.

Alternatywnie możesz zapisać plik tekstowy lub CSV (uważam, że CSV jest łatwiejszy), który można przeanalizować za pomocą odpowiednich narzędzi wiersza poleceń, takich jak grep lub findstr, lub niektórych programów, takich jak notepad ++.

Przykład ze świata rzeczywistego: mieliśmy do czynienia z powiększeniem dzienników bezpieczeństwa do rozmiaru 12 GB, aby umożliwić przechowywanie przez 6 miesięcy zgodnie z wymogami zgodności.

Do 3 miesiąca nie byliśmy w stanie zalogować się do serwerów 2008r2 i 2012r2. Logowanie utknęłoby na ekranie „Witamy”. Próbowaliśmy zwiększyć pamięć serwera do 20 GB, aby pomieścić duże otwierane pliki, a serwer wciąż był zły. Ostatecznie zdecydowaliśmy się zastosować do zalecenia 1 GB zarządzania silnikiem i dostosować go do archiwizacji starego pliku, gdy jest pełny lub nadpisywany.

Mamy ten skrypt, aby wyczyścić stare pliki starsze niż 180 dni, jeśli są potrzebne, ale prawdopodobnie możemy po prostu utrzymać pliki na miejscu.

get-childitem -Path "C:\Windows\System32\winevt\Logs" |
  where-object {$_.LastWriteTime -lt (get-date).AddDays(-180)} |
  remove-item –whatif

https://www.manageengine.com/products/active-directory-audit/help/getting-started/event-log-size-retention-settings.html