Quelles sont les implications du dépassement de 4 Go dans un journal des événements Windows?

J'ai trouvé cette base de connaissances Microsoft qui couvre les maximums de paramètres du journal des événements recommandés pour les systèmes d'exploitation jusqu'à Windows 2008 / Vista , qui recommande un maximum de 4 Go, et j'ai vu d'autres références vagues qu'un journal des événements supérieur à 4 Go n'est pas recommandé au moins 2008 R2, mais je me demande ce qui se passe réellement si un journal des événements dépasse cette taille?

J'ai dépassé cela sur un serveur de test (2012 R2) et je n'ai rien remarqué comme une utilisation élevée de la mémoire, etc. Nous ne nous soucions pas des systèmes d'exploitation avant 2008 R2, mais nous voulons un journal volumineux car nous collectons des événements de nombreuses machines via Transfert d'événements Windows et souhaitez avoir tous les événements au même endroit.

À part les performances horribles et les temps d'attente ridicules lorsque vous devez charger un journal de 4 Go et que ce sera le cas si vous deviez rechercher une chose aussi monstrueuse, pas grand-chose. Je pense que le plus grand que j'ai vu dans mes environnements était de 10 Go, et même si j'ai renoncé à l'attendre pour le charger, il ne semblait rien nuire.

La mise en garde de 4 Go pour Server 2008 est due à cette limite de 32 bits qui est souvent rencontrée à 4 Go. Sur un système 64 bits, vous devriez être en mesure de le laisser atteindre jusqu'à 16 To (ou 64, selon), bien que je ne sache pas que quiconque soit parvenu à tester cette limite.

Bien sûr, si vous ne l'avez pas déjà fait, vous découvrirez que les très gros fichiers journaux ne sont tout simplement pas pratiques à utiliser - la dernière fois que j'ai essayé de charger un simple fichier journal de 100 Go (texte), il ne pouvait même pas être ouvert sans planter l'application en l'ouvrant, et je pense que vous rencontrerez ce problème bien avant 100 Go.

La meilleure approche consiste à limiter la taille du fichier à quelque chose de raisonnable et à utiliser un script pour l'effacer de temps en temps. J'utilise ce qui suit dans mon environnement, combiné à une limite de taille de 1 Go sur notre journal de sécurité. Certains (enfin, la plupart) de nos serveurs génèrent plus de 3 Go d'événements de sécurité par jour, et nous ne voulons pas perdre tout cet espace sur d'énormes fichiers journaux que je quitterai avant de passer au peigne fin, donc mon script copie le contenu du journal dans un autre dossier, puis efface le journal des événements dans lequel réécrire. Et puisque le dossier dans lequel je les copie est sauvegardé, nous pouvons toujours revenir aux journaux de l'événement horrible dont nous avons besoin.

#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'autre réponse couvre le raisonnement derrière cela - pour les systèmes modernes, gardant la plupart du temps les temps de chargement dans l'interface graphique de l'observateur d'événements quelque peu supportable. Copier le journal actuel vers un emplacement sauvegardé, puis l'effacer, est également une bonne chose.

Pour analyser de gros fichiers journaux qui finissent par être générés de toute façon, deux bonnes options se produisent:

1) Analysez le journal plus rapidement que l'interface graphique actuelle ne peut gérer ou 2) Divisez le journal en fichiers séparés.

Je suis sûr qu'il existe des utilitaires facilement disponibles pour 2), je vais donc me concentrer sur 1).

Premièrement, Powershell a une excellente applet de commande pour cette fonctionnalité appelée «get-winevent». La performance la plus rapide que j'ai vue consiste à utiliser des tables de hachage. Voici un exemple qui obtient tous les événements du journal de sécurité relatifs à un utilisateur spécifique du dernier jour:

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

$ userevt est maintenant une collection d'événements. Selon le nombre de correspondances, vous pouvez le diriger vers format-list pour lire facilement un petit nombre d'événements. Pour un nombre moyen, faites de même mais redirigez la sortie vers un fichier:

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

Pour un grand nombre, commencez le filtrage (disons que vous voulez que l'ordinateur appelant pour un événement de verrouillage sur l'utilisateur que nous avons acquis ci-dessus):

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

Cela affichera un résultat sur une seule ligne pour chaque événement de verrouillage. Les processus ci-dessus prennent généralement 1 à 4 minutes pour un journal de 4 Go sur 2008 R2.

Deuxièmement, en particulier pour toutes les machines 2003 que vous pourriez avoir à gérer, vous pouvez cliquer avec le bouton droit sur un fichier journal particulier dans le volet gauche de l'Observateur d'événements et sélectionner «enregistrer le fichier journal sous».

Si vous exécutez l'Observateur d'événements sur la machine locale, vous pouvez enregistrer un fichier .evt qui peut être analysé par get-winevent.

Alternativement, vous pouvez enregistrer un fichier texte ou CSV (je trouve CSV plus facile) qui peut être analysé par les utilitaires de ligne de commande appropriés tels que grep ou findstr, ou certains programmes comme notepad ++.

Exemple réel: nous avons eu cela avec des journaux de sécurité augmentés à 12 Go pour permettre une conservation de 6 mois selon une exigence de conformité.

Au mois 3, nous ne pouvions pas nous connecter aux serveurs 2008r2 et 2012r2. La connexion resterait bloquée sur l'écran "Bienvenue". Nous avons essayé d'augmenter la mémoire du serveur à 20 Go pour accueillir les gros fichiers ouverts et le serveur était toujours en colère. Nous avons fini par décider de suivre la recommandation du moteur de gestion de 1 Go et de l'ajuster pour archiver l'ancien fichier lorsqu'il est plein par rapport à l'écraser.

Nous avons ce script pour nettoyer les anciens fichiers de plus de 180 jours si nous en avons besoin, mais nous pouvons probablement simplement garder les fichiers en place.

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