Welche Auswirkungen hat das Überschreiten von 4 GB in einem Windows-Ereignisprotokoll?

Ich habe diese Microsoft-KB gefunden, die die empfohlenen Einstellungsmaxima für das Ereignisprotokoll für Betriebssysteme bis Windows 2008 / Vista abdeckt , die ein Maximum von 4 GB empfehlen, und habe einige andere vage Hinweise gesehen, dass ein Ereignisprotokoll mit mehr als 4 GB nicht mindestens empfohlen wird 2008 R2, aber ich frage mich, was eigentlich passiert, wenn ein Ereignisprotokoll diese Größe überschreitet?

Ich habe dies auf einem Testserver (2012 R2) überschritten und habe nichts von einer hohen Speichernutzung usw. bemerkt. Wir kümmern uns nicht um Betriebssysteme vor 2008 R2, sondern möchten ein großes Protokoll, da wir Ereignisse von vielen Computern über sammeln Windows Event Forwarding und möchten alle Ereignisse an einem Ort haben.

Abgesehen von der schrecklichen Leistung und den lächerlichen Wartezeiten, in denen Sie ein 4-GB-Protokoll laden müssen, und zum Teufel, wird es sein, wenn Sie jemals so eine monströse Sache durchsuchen müssen, nicht viel. Ich glaube, das größte, das ich in meiner Umgebung gesehen habe, waren 10 GB, und obwohl ich es aufgegeben habe, darauf zu warten, um es zu laden, schien es nichts zu schaden.

Die Vorsicht bei 4 GB für Server 2008 beruht auf der 32-Bit-Beschränkung, die bei 4 GB häufig auftritt. Auf einem 64-Bit-System sollte es in Ordnung sein, es auf bis zu 16 TB (oder 64, abhängig davon) anwachsen zu lassen, obwohl ich nicht weiß, dass irgendjemand in die Nähe dieses Grenzwerts gelangt ist.

Wenn Sie es noch nicht getan haben, werden Sie natürlich feststellen, dass die Verwendung sehr großer Protokolldateien einfach unpraktisch ist - das letzte Mal, als ich versuchte, eine einfache 100-GB-Protokolldatei (Text) zu laden, konnte sie nicht einmal ohne geöffnet werden Wenn Sie die Anwendung zum Absturz bringen und sie öffnen, werden Sie dieses Problem vermutlich schon lange vor 100 GB haben.

Der weitaus bessere Ansatz besteht darin, die Dateigröße auf ein vernünftiges Maß zu beschränken und sie von Zeit zu Zeit mithilfe eines Skripts zu löschen. Ich verwende das Folgende in meiner Umgebung, kombiniert mit einer Größenbeschränkung von 1 GB in unserem Sicherheitsprotokoll. Einige (naja, die meisten) unserer Server generieren mehr als 3 GB Sicherheitsereignisse pro Tag, und wir möchten nicht den gesamten Speicherplatz für riesige Protokolldateien verschwenden, die ich vor dem Durchkämmen beenden werde. Deshalb kopiert mein Skript den Protokollinhalt nach einen anderen Ordner und löscht dann das Ereignisprotokoll, in das erneut geschrieben werden soll. Und da der Ordner, in den ich sie kopiere, gesichert ist, können wir in dem schrecklichen Ereignis, das wir brauchen, immer zu den Protokollen zurückkehren.

#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

Die andere Antwort deckt die Gründe dafür ab - für moderne Systeme, bei denen die Ladezeiten in der Benutzeroberfläche der Ereignisanzeige meist etwas erträglich sind. Das Kopieren des aktuellen Protokolls an einen Speicherort, der gesichert und anschließend gelöscht wird, ist ebenfalls gut.

Für das Parsen großer Protokolldateien, die ohnehin generiert werden, gibt es zwei gute Optionen:

1) Analysieren Sie das Protokoll schneller, als die aktuelle GUI verwalten kann, oder 2) Teilen Sie das Protokoll in separate Dateien auf.

Ich bin mir sicher, dass es einige leicht verfügbare Dienstprogramme für 2) gibt, also konzentriere ich mich auf 1).

Erstens hat Powershell ein exzellentes Cmdlet für diese Funktionalität namens 'get-winevent'. Die schnellste Leistung, die ich gesehen habe, ist die Verwendung von Hash-Tabellen. Im folgenden Beispiel werden alle Ereignisse im Sicherheitsprotokoll abgerufen, die sich auf einen bestimmten Benutzer vom letzten Tag beziehen:

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

$ userevt ist jetzt eine Sammlung von Ereignissen. Abhängig von der Anzahl der Übereinstimmungen können Sie diese an die Formatliste weiterleiten, um auf einfache Weise eine kleine Anzahl von Ereignissen zu lesen. Gehen Sie für eine Medium-Nummer genauso vor, leiten Sie die Ausgabe jedoch in eine Datei um:

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

Beginnen Sie bei einer großen Anzahl mit der Filterung (sagen wir, Sie möchten, dass der Anrufercomputer ein Sperrereignis für den oben erfassten Benutzer auslöst):

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

Dies zeigt ein einzeiliges Ergebnis für jedes Sperrereignis. Die oben genannten Vorgänge dauern im Allgemeinen 1 bis 4 Minuten für ein 4 GB-Protokoll für 2008 R2.

Zweitens können Sie mit der rechten Maustaste auf eine bestimmte Protokolldatei im linken Bereich der Ereignisanzeige klicken und "Protokolldatei speichern unter" auswählen, insbesondere für alle 2003-Computer, die möglicherweise verwaltet werden müssen.

Wenn Sie die Ereignisanzeige auf dem lokalen Computer ausführen, können Sie eine EVT-Datei speichern, die von get-winevent analysiert werden kann.

Alternativ können Sie eine Text- oder CSV-Datei speichern (ich finde CSV einfacher), die von entsprechenden Befehlszeilenprogrammen wie grep oder findstr oder bestimmten Programmen wie notepad ++ analysiert werden kann.

Beispiel aus der Praxis: Dies geschah mit Sicherheitsprotokollen, die auf eine Größe von 12 GB erhöht wurden, um eine Aufbewahrungsdauer von 6 Monaten pro Compliance-Anforderung zu ermöglichen.

Bis zum 3. Monat konnten wir uns nicht bei den Servern 2008r2 und 2012r2 anmelden. Die Anmeldung würde beim Begrüßungsbildschirm hängen bleiben. Wir haben versucht, den Serverspeicher auf 20 GB zu erhöhen, um die großen Dateien aufzunehmen, die geöffnet werden, und der Server war immer noch wütend. Wir haben uns letztendlich dafür entschieden, die Empfehlung der Verwaltungs-Engine von 1 GB zu befolgen und sie so anzupassen, dass alte Dateien beim vollständigen Überschreiben archiviert werden.

Wir haben dieses Skript, um alte Dateien zu bereinigen, die älter als 180 Tage sind, wenn wir es brauchen, aber wir können wahrscheinlich nur die Dateien an Ort und Stelle halten.

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