Quali sono le conseguenze del superamento di 4 GB in un registro eventi di Windows?

Ho trovato questo Microsoft KB che copre i valori massimi raccomandati per il registro eventi per i sistemi operativi fino a Windows 2008 / Vista , che consiglia un massimo di 4 GB, e ho visto alcuni altri riferimenti vaghi che un registro eventi più grande di 4 GB non è raccomandato in almeno 2008 R2, ma mi chiedo cosa accada realmente se un registro eventi supera queste dimensioni?

L'ho superato su un server di prova (2012 R2) e non ho notato nulla di simile all'utilizzo elevato della memoria, ecc. Non ci preoccupiamo dei sistemi operativi prima del 2008 R2, ma vogliamo un registro di grandi dimensioni perché stiamo raccogliendo eventi da molte macchine tramite Inoltro di eventi di Windows e vuoi avere tutti gli eventi in un unico posto.

A parte le terribili prestazioni e i tempi di attesa ridicoli quando devi caricare un registro da 4 GB e diavolo sarà se dovessi cercare attraverso una cosa così mostruosa, non molto. Penso che il più grande che abbia mai visto nei miei ambienti fosse di 10 GB, e sebbene abbia rinunciato ad aspettare che si caricasse, non sembrava danneggiare nulla.

La cautela di 4 GB per Server 2008 è dovuta al limite di 32 bit che si incontra spesso a 4 GB. Su un sistema a 64 bit, dovresti essere in grado di farlo crescere fino a 16 TB (o 64, a seconda), anche se non so che qualcuno si è avvicinato in qualche modo ai test di quel limite.

Ovviamente, se non lo hai già fatto, scoprirai che file di registro molto grandi sono semplicemente poco pratici da usare: l'ultima volta che ho provato a caricare un semplice file di registro da 100 GB (testo), non poteva nemmeno essere aperto senza l'arresto anomalo dell'applicazione aprendola e sospetto che il problema verrà risolto ben prima di 100 GB.

L'approccio migliore è limitare la dimensione del file a qualcosa di ragionevole e utilizzare uno script per cancellarlo di volta in volta. Uso il seguito nel mio ambiente, combinato con un limite di dimensioni di 1 GB sul nostro registro di sicurezza. Alcuni (bene, la maggior parte) dei nostri server generano oltre 3 GB di eventi di sicurezza al giorno, e non vogliamo sprecare tutto lo spazio su enormi file di registro che abbandonerò prima di esaminare, quindi il mio script copia il contenuto del registro in un'altra cartella, quindi cancella il registro eventi da riscrivere. E dal momento che viene eseguito il backup della cartella in cui li copio, possiamo sempre tornare ai registri nell'evento orribile di cui abbiamo bisogno.

#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

L'altra risposta copre il ragionamento alla base di questo - per i sistemi moderni, mantenendo in gran parte sopportabili i tempi di caricamento all'interno della GUI del Visualizzatore eventi. Anche copiare il registro corrente in una posizione di cui viene eseguito il backup, quindi cancellarlo, va bene.

Per analizzare file di registro di grandi dimensioni che finiscono comunque per essere generati, si verificano due buone opzioni:

1) Analizzare il registro più velocemente di quanto l'attuale GUI possa gestire o 2) Dividere il registro in file separati.

Sono sicuro che ci sono alcune utility facilmente disponibili là fuori per 2), quindi mi concentrerò su 1).

Innanzitutto, Powershell ha un cmdlet eccellente per questa funzionalità chiamata "get-winevent". Le prestazioni più veloci che ho visto coinvolgono l'utilizzo di tabelle hash. Ecco un esempio che ottiene tutti gli eventi nel registro di sicurezza relativi a un utente specifico dall'ultimo giorno:

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

$ userevt ora è una raccolta di eventi. A seconda del numero di corrispondenze, è possibile reindirizzarlo all'elenco dei formati per leggere facilmente un piccolo numero di eventi. Per un numero medio, fai lo stesso ma reindirizza l'output su un file:

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

Per un numero elevato, inizia a filtrare (supponiamo che tu voglia il computer chiamante per un evento di blocco sull'utente che abbiamo acquisito sopra):

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

Questo mostrerà un risultato a riga singola per ogni evento di blocco. I processi sopra indicati richiedono generalmente 1-4 minuti per un log da 4 GB su 2008 R2.

In secondo luogo, specialmente per qualsiasi macchina del 2003 che potresti dover gestire, puoi fare clic con il tasto destro su un particolare file di registro nel riquadro di sinistra nel Visualizzatore eventi e selezionare "Salva file di registro come".

Se si esegue il Visualizzatore eventi sul computer locale, è possibile salvare un file .evt che può essere analizzato da get-winevent.

In alternativa, è possibile salvare un file di testo o CSV (trovo CSV più semplice) che può essere analizzato da utility della riga di comando appropriate come grep o findstr o alcuni programmi come notepad ++.

Esempio reale: abbiamo avuto questo problema con i log di sicurezza aumentati a 12 GB per consentire una conservazione di 6 mesi per un requisito di conformità.

Al terzo mese non siamo stati in grado di accedere ai server 2008r2 e 2012r2. L'accesso verrebbe bloccato nella schermata di benvenuto. Abbiamo provato ad aumentare la memoria del server a 20 GB per accogliere i file di grandi dimensioni che venivano aperti e il server era ancora arrabbiato. Alla fine abbiamo deciso di seguire il consiglio di gestione del motore da 1 GB e di adattarlo per archiviare il vecchio file quando pieno contro sovrascrivere.

Abbiamo questo script per ripulire i vecchi file più vecchi di 180 giorni se ne abbiamo bisogno, ma probabilmente possiamo semplicemente mantenere i file sul posto.

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