Welche Auswirkungen hat es, wenn ein Windows-Ereignisprotokoll 4 GB überschreitet?

Question 1

Abgesehen von der schrecklichen Leistung und den lächerlichen Wartezeiten, wenn Sie ein 4 GB großes Protokoll laden müssen, und der Hölle, die es sein wird, wenn Sie jemals ein so monströses Ding durchsuchen müssen, gibt es nicht viel. Ich glaube, das größte, das ich in meinen Umgebungen gesehen habe, war 10 GB groß, und obwohl ich es aufgegeben habe, auf das Laden zu warten, schien es nichts zu schaden.

Die 4-GB-Warnung für Server 2008 ist auf die 32-Bit-Grenze zurückzuführen, die häufig bei 4 GB erreicht wird. Auf einem 64-Bit-System sollte es kein Problem sein, die Kapazität auf bis zu 16 TB (oder 64, je nachdem) zu erhöhen, obwohl mir nicht bekannt ist, dass irgendjemand auch nur annähernd diese Grenze getestet hat.

Natürlich werden Sie, falls Sie es nicht bereits getan haben, feststellen, dass die Verwendung sehr großer Protokolldateien einfach unpraktisch ist. Als ich das letzte Mal versucht habe, eine einfache 100 GB große (Text-)Protokolldatei zu laden, konnte sie nicht einmal geöffnet werden, ohne dass die Anwendung beim Öffnen abstürzte. Und ich vermute, dass dieses Problem schon lange vor 100 GB auftreten wird.

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 in meiner Umgebung Folgendes, kombiniert mit einer Größenbeschränkung von 1 GB für unser Sicherheitsprotokoll. Einige (also die meisten) unserer Server generieren über 3 GB an Sicherheitsereignissen pro Tag, und wir möchten diesen ganzen Platz nicht für riesige Protokolldateien verschwenden, die ich beende, bevor ich sie durchgehe. Daher kopiert mein Skript den Protokollinhalt in einen anderen Ordner und löscht dann das Ereignisprotokoll, damit es erneut beschrieben werden kann. Und da der Ordner, in den ich sie kopiere, gesichert ist, können wir im Ernstfall, wenn wir es müssen, immer auf die Protokolle zurückgreifen.

#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

Answer

Abgesehen von der schrecklichen Leistung und den lächerlichen Wartezeiten, wenn Sie ein 4 GB großes Protokoll laden müssen, und der Hölle, die es sein wird, wenn Sie jemals ein so monströses Ding durchsuchen müssen, gibt es nicht viel. Ich glaube, das größte, das ich in meinen Umgebungen gesehen habe, war 10 GB groß, und obwohl ich es aufgegeben habe, auf das Laden zu warten, schien es nichts zu schaden.

Die 4-GB-Warnung für Server 2008 ist auf die 32-Bit-Grenze zurückzuführen, die häufig bei 4 GB erreicht wird. Auf einem 64-Bit-System sollte es kein Problem sein, die Kapazität auf bis zu 16 TB (oder 64, je nachdem) zu erhöhen, obwohl mir nicht bekannt ist, dass irgendjemand auch nur annähernd diese Grenze getestet hat.

Natürlich werden Sie, falls Sie es nicht bereits getan haben, feststellen, dass die Verwendung sehr großer Protokolldateien einfach unpraktisch ist. Als ich das letzte Mal versucht habe, eine einfache 100 GB große (Text-)Protokolldatei zu laden, konnte sie nicht einmal geöffnet werden, ohne dass die Anwendung beim Öffnen abstürzte. Und ich vermute, dass dieses Problem schon lange vor 100 GB auftreten wird.

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 in meiner Umgebung Folgendes, kombiniert mit einer Größenbeschränkung von 1 GB für unser Sicherheitsprotokoll. Einige (also die meisten) unserer Server generieren über 3 GB an Sicherheitsereignissen pro Tag, und wir möchten diesen ganzen Platz nicht für riesige Protokolldateien verschwenden, die ich beende, bevor ich sie durchgehe. Daher kopiert mein Skript den Protokollinhalt in einen anderen Ordner und löscht dann das Ereignisprotokoll, damit es erneut beschrieben werden kann. Und da der Ordner, in den ich sie kopiere, gesichert ist, können wir im Ernstfall, wenn wir es müssen, immer auf die Protokolle zurückgreifen.

#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

Question 2

Die andere Antwort behandelt die Gründe dafür: Bei modernen Systemen sind die Ladezeiten in der GUI der Ereignisanzeige meist einigermaßen erträglich. Es ist auch gut, das aktuelle Protokoll an einen Ort zu kopieren, der gesichert wird, und es dann zu löschen.

Zum Parsen großer Protokolldateien, die ohnehin generiert werden, gibt es zwei gute Optionen:

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

Ich bin sicher, dass es für 2) einige leicht verfügbare Dienstprogramme gibt, daher werde ich mich auf 1) konzentrieren.

Erstens verfügt Powershell über ein hervorragendes Cmdlet für diese Funktion namens „get-winevent“. Die schnellste Leistung, die ich gesehen habe, erfolgt durch die Verwendung von Hash-Tabellen. Hier ist ein Beispiel, das alle Ereignisse im Sicherheitsprotokoll abruft, 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 es an die Formatliste weiterleiten, um eine kleine Anzahl von Ereignissen einfach zu lesen. Für eine mittlere Anzahl machen Sie dasselbe, leiten die Ausgabe jedoch in eine Datei um:

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

Beginnen Sie bei einer großen Zahl mit der Filterung (sagen wir, Sie möchten den Computer des Anrufers für ein Sperrereignis für den Benutzer, den wir oben ermittelt haben):

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

Dadurch wird für jedes Sperrereignis ein einzeiliges Ergebnis angezeigt. Die oben genannten Prozesse dauern für ein 4 GB großes Protokoll unter 2008 R2 im Allgemeinen 1–4 Minuten.

Zweitens können Sie insbesondere bei 2003-Computern, die Sie möglicherweise verwalten müssen, mit der rechten Maustaste auf eine bestimmte Protokolldatei im linken Bereich der Ereignisanzeige klicken und „Protokolldatei speichern unter“ auswählen.

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.

Answer

Die andere Antwort behandelt die Gründe dafür: Bei modernen Systemen sind die Ladezeiten in der GUI der Ereignisanzeige meist einigermaßen erträglich. Es ist auch gut, das aktuelle Protokoll an einen Ort zu kopieren, der gesichert wird, und es dann zu löschen.

Zum Parsen großer Protokolldateien, die ohnehin generiert werden, gibt es zwei gute Optionen:

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

Ich bin sicher, dass es für 2) einige leicht verfügbare Dienstprogramme gibt, daher werde ich mich auf 1) konzentrieren.

Erstens verfügt Powershell über ein hervorragendes Cmdlet für diese Funktion namens „get-winevent“. Die schnellste Leistung, die ich gesehen habe, erfolgt durch die Verwendung von Hash-Tabellen. Hier ist ein Beispiel, das alle Ereignisse im Sicherheitsprotokoll abruft, 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 es an die Formatliste weiterleiten, um eine kleine Anzahl von Ereignissen einfach zu lesen. Für eine mittlere Anzahl machen Sie dasselbe, leiten die Ausgabe jedoch in eine Datei um:

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

Beginnen Sie bei einer großen Zahl mit der Filterung (sagen wir, Sie möchten den Computer des Anrufers für ein Sperrereignis für den Benutzer, den wir oben ermittelt haben):

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

Dadurch wird für jedes Sperrereignis ein einzeiliges Ergebnis angezeigt. Die oben genannten Prozesse dauern für ein 4 GB großes Protokoll unter 2008 R2 im Allgemeinen 1–4 Minuten.

Zweitens können Sie insbesondere bei 2003-Computern, die Sie möglicherweise verwalten müssen, mit der rechten Maustaste auf eine bestimmte Protokolldatei im linken Bereich der Ereignisanzeige klicken und „Protokolldatei speichern unter“ auswählen.

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.

Question 3

Beispiel aus der Praxis: Dies ist bei uns aufgetreten, als die Größe der Sicherheitsprotokolle auf 12 GB erhöht wurde, um eine 6-monatige Aufbewahrung gemäß einer Compliance-Anforderung zu ermöglichen.

Im dritten Monat konnten wir uns nicht mehr bei den Servern 2008r2 und 2012r2 anmelden. Die Anmeldung blieb beim „Willkommen“-Bildschirm hängen. Wir versuchten, den Serverspeicher auf 20 GB zu erhöhen, um die großen Dateien zu verarbeiten, die geöffnet werden mussten, aber der Server reagierte immer noch nicht richtig. Wir entschieden uns schließlich dafür, der Empfehlung von Manage Engine von 1 GB zu folgen und sie so anzupassen, dass alte Dateien archiviert werden, wenn sie voll sind, statt sie zu überschreiben.

Wir haben dieses Skript, um bei Bedarf alte Dateien zu bereinigen, die älter als 180 Tage sind, aber wahrscheinlich können wir die Dateien einfach an Ort und Stelle belassen.

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

Answer

Beispiel aus der Praxis: Dies ist bei uns aufgetreten, als die Größe der Sicherheitsprotokolle auf 12 GB erhöht wurde, um eine 6-monatige Aufbewahrung gemäß einer Compliance-Anforderung zu ermöglichen.

Im dritten Monat konnten wir uns nicht mehr bei den Servern 2008r2 und 2012r2 anmelden. Die Anmeldung blieb beim „Willkommen“-Bildschirm hängen. Wir versuchten, den Serverspeicher auf 20 GB zu erhöhen, um die großen Dateien zu verarbeiten, die geöffnet werden mussten, aber der Server reagierte immer noch nicht richtig. Wir entschieden uns schließlich dafür, der Empfehlung von Manage Engine von 1 GB zu folgen und sie so anzupassen, dass alte Dateien archiviert werden, wenn sie voll sind, statt sie zu überschreiben.

Wir haben dieses Skript, um bei Bedarf alte Dateien zu bereinigen, die älter als 180 Tage sind, aber wahrscheinlich können wir die Dateien einfach an Ort und Stelle belassen.

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

Question 4

Es gibt zahlreiche Berichte (1,2,3) dass selbst unter Windows Vista/Server 2008 und höher die „klassischen“ Ereignisprotokolle (Anwendung, Sicherheit, System und einige andere) immer noch zu Speichererschöpfung führen können, wenn die maximale Größe zu hoch eingestellt ist – es scheint, dass sie möglicherweise immer noch „speicherzugeordnet“ sind.

Während Microsoftsagen in ihrer Dokumentation zum Thema:

Windows Vista und Windows Server 2008 verwenden eine neue Infrastruktur zur Ereignisberichterstattung und weisen nicht das in den folgenden Absätzen beschriebene Verhalten auf.

Beim Testen scheint es, dass diesnurgelten für die neue 'Windows Event Log-Technologie' und 'Event Tracing for Windows' Protokolle, die in Windows Vista eingeführt wurden - die folgende Dokumentation auf derWinEvent abrufenUndEreignisprotokoll abrufenCmdlets legen nahe, dass „klassische“ Protokolle möglicherweise weiterhin auf der älteren Technologie ausgeführt werden:

Das Cmdlet Get-WinEvent ruft Ereignisse aus Ereignisprotokollen ab,einschließlich klassischer Protokolle, so wie dieSystem- und AnwendungsprotokolleDas Cmdlet ruft Daten aus Ereignisprotokollen ab, die vomIn Windows Vista eingeführte Windows-Ereignisprotokolltechnologieund Ereignisse in Protokolldateien generiert vonEreignisablaufverfolgung für Windows (ETW). Standardmäßig gibt Get-WinEvent Ereignisinformationen in der Reihenfolge vom neuesten zum ältesten zurück.

PowerShell-Cmdlets, die das Substantiv „EventLog“ enthalten, funktionieren nur unter Windows klassische Ereignisprotokollewie zum BeispielAnwendung, System oder Sicherheit. Um Protokolle zu erhalten, die dieWindows-Ereignisprotokolltechnologie in Windows Vista und späteren Windows-Versionen, verwenden Sie Get-WinEvent.

Das Ausführen dieses PowerShell-Cmdlets sogar unter Windows 11 zeigt, dass unter anderem die Anwendungs-, Sicherheits- und Systemereignisprotokolle immer noch im „klassischen“ Modus ausgeführt werden, was das gemeldete Verhalten erklären könnte.

Get-WinEvent -ListLog * | Sort-Object LogName | Select-Object -Property

LogName                           IsClassicLog
-------                           ------------
Application                               True
ForwardedEvents                          False
HardwareEvents                            True
Internet Explorer                         True
Key Management Service                    True
Microsoft-AppV-Client/Admin              False
Microsoft-AppV-Client/Operational        False
...
Security                                  True
...
System                                    True

Mit dem Tool Sysinternals RAMMap können Sie überprüfen, wie viel freier Speicher für zugeordnete Dateien verwendet wird (7). Auf der Seite „Dateiübersicht“ können Sie sehen, dass sich fast das gesamte Sicherheitsereignisprotokoll im aktiven Speicher befindet:

Obwohl die Grenze von >4 GB auf x64-Servern nicht mehr gilt, scheinen vielehabenfestgestellt, dass große Größen für die „klassischen“ Ereignisprotokolle (insbesondere das Sicherheitsereignisprotokoll) sogar auf neueren Betriebssystemen freien Speicher belegen können, da diese Ereignisprotokolle „speicherzugeordnet“ bleiben. Das Reduzieren der maximalen Größe des Protokolls und das Löschen der Protokolle behebt das Problem. Seien Sie also vorsichtig, bevor Sie den Wert zu hoch einstellen.

Answer

Es gibt zahlreiche Berichte (1,2,3) dass selbst unter Windows Vista/Server 2008 und höher die „klassischen“ Ereignisprotokolle (Anwendung, Sicherheit, System und einige andere) immer noch zu Speichererschöpfung führen können, wenn die maximale Größe zu hoch eingestellt ist – es scheint, dass sie möglicherweise immer noch „speicherzugeordnet“ sind.

Während Microsoftsagen in ihrer Dokumentation zum Thema:

Windows Vista und Windows Server 2008 verwenden eine neue Infrastruktur zur Ereignisberichterstattung und weisen nicht das in den folgenden Absätzen beschriebene Verhalten auf.

Beim Testen scheint es, dass diesnurgelten für die neue 'Windows Event Log-Technologie' und 'Event Tracing for Windows' Protokolle, die in Windows Vista eingeführt wurden - die folgende Dokumentation auf derWinEvent abrufenUndEreignisprotokoll abrufenCmdlets legen nahe, dass „klassische“ Protokolle möglicherweise weiterhin auf der älteren Technologie ausgeführt werden:

Das Cmdlet Get-WinEvent ruft Ereignisse aus Ereignisprotokollen ab,einschließlich klassischer Protokolle, so wie dieSystem- und AnwendungsprotokolleDas Cmdlet ruft Daten aus Ereignisprotokollen ab, die vomIn Windows Vista eingeführte Windows-Ereignisprotokolltechnologieund Ereignisse in Protokolldateien generiert vonEreignisablaufverfolgung für Windows (ETW). Standardmäßig gibt Get-WinEvent Ereignisinformationen in der Reihenfolge vom neuesten zum ältesten zurück.

PowerShell-Cmdlets, die das Substantiv „EventLog“ enthalten, funktionieren nur unter Windows klassische Ereignisprotokollewie zum BeispielAnwendung, System oder Sicherheit. Um Protokolle zu erhalten, die dieWindows-Ereignisprotokolltechnologie in Windows Vista und späteren Windows-Versionen, verwenden Sie Get-WinEvent.

Das Ausführen dieses PowerShell-Cmdlets sogar unter Windows 11 zeigt, dass unter anderem die Anwendungs-, Sicherheits- und Systemereignisprotokolle immer noch im „klassischen“ Modus ausgeführt werden, was das gemeldete Verhalten erklären könnte.

Get-WinEvent -ListLog * | Sort-Object LogName | Select-Object -Property

LogName                           IsClassicLog
-------                           ------------
Application                               True
ForwardedEvents                          False
HardwareEvents                            True
Internet Explorer                         True
Key Management Service                    True
Microsoft-AppV-Client/Admin              False
Microsoft-AppV-Client/Operational        False
...
Security                                  True
...
System                                    True

Mit dem Tool Sysinternals RAMMap können Sie überprüfen, wie viel freier Speicher für zugeordnete Dateien verwendet wird (7). Auf der Seite „Dateiübersicht“ können Sie sehen, dass sich fast das gesamte Sicherheitsereignisprotokoll im aktiven Speicher befindet:

Obwohl die Grenze von >4 GB auf x64-Servern nicht mehr gilt, scheinen vielehabenfestgestellt, dass große Größen für die „klassischen“ Ereignisprotokolle (insbesondere das Sicherheitsereignisprotokoll) sogar auf neueren Betriebssystemen freien Speicher belegen können, da diese Ereignisprotokolle „speicherzugeordnet“ bleiben. Das Reduzieren der maximalen Größe des Protokolls und das Löschen der Protokolle behebt das Problem. Seien Sie also vorsichtig, bevor Sie den Wert zu hoch einstellen.

Welche Auswirkungen hat es, wenn ein Windows-Ereignisprotokoll 4 GB überschreitet?

Antwort1

Antwort2

Antwort3

Antwort4

verwandte Informationen