¿Cuáles son las implicaciones de exceder los 4 GB en un registro de eventos de Windows?

Encontré este KB de Microsoft que cubre los valores máximos recomendados de configuración del Registro de eventos para sistemas operativos hasta Windows 2008 / Vista , que recomienda un máximo de 4 GB, y he visto algunas otras referencias vagas de que un Registro de eventos de más de 4 GB no se recomienda al menos 2008 R2, pero me pregunto qué sucede si un registro de eventos supera este tamaño.

He excedido esto en un servidor de prueba (2012 R2) y no he notado nada como un uso elevado de memoria, etc. No nos interesan los sistemas operativos antes de 2008 R2, pero queremos un registro grande porque estamos recopilando eventos de muchas máquinas a través de Reenvío de eventos de Windows y desea tener todos los eventos en un solo lugar.

Aparte del rendimiento horrible y los tiempos de espera ridículos cuando tienes que cargar un registro de 4 GB y demonios será si alguna vez tienes que buscar a través de algo tan monstruoso, no mucho. Creo que el más grande que he visto en mis entornos fue de 10 GB, y aunque dejé de esperar a que se cargara, no pareció dañar nada.

La precaución de 4 GB para Server 2008 se debe a ese límite de 32 bits que a menudo se encuentra en 4 GB. En un sistema de 64 bits, debería estar bien para dejarlo crecer hasta 16 TB (o 64, dependiendo), aunque no sé si alguien se haya acercado a probar ese límite.

Por supuesto, si aún no lo ha hecho, descubrirá que los archivos de registro muy grandes simplemente no son prácticos de usar: la última vez que intenté cargar un archivo de registro simple de 100 GB (texto), ni siquiera podría abrirse sin bloqueando la aplicación abriéndola, y sospecho que encontrarás ese problema mucho antes de los 100 GB.

El enfoque mucho mejor es limitar el tamaño del archivo a algo razonable y usar un script para borrarlo de vez en cuando. Utilizo lo siguiente en mi entorno, combinado con un límite de tamaño de 1 GB en nuestro registro de seguridad. Algunos (bueno, la mayoría) de nuestros servidores generan más de 3 GB de eventos de seguridad por día, y no queremos desperdiciar todo ese espacio en enormes archivos de registro que dejaré antes de revisar, por lo que mi script copia el contenido del registro en otra carpeta y luego borra el registro de eventos para que se vuelva a escribir. Y dado que la carpeta en la que los copio está respaldada, siempre podemos volver a los registros en el horrible evento que necesitamos.

#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

La otra respuesta cubre el razonamiento detrás de esto: para los sistemas modernos, principalmente manteniendo los tiempos de carga dentro de la GUI del visor de eventos algo soportable. Copiar el registro actual a una ubicación que se respalda y luego borrarlo también es bueno.

Para analizar archivos de registro grandes que terminan siendo generados de todos modos, ocurren dos buenas opciones:

1) Analice el registro más rápido de lo que la GUI actual puede administrar o 2) Divida el registro en archivos separados.

Estoy seguro de que hay algunas utilidades fácilmente disponibles para 2), así que me centraré en 1).

En primer lugar, Powershell tiene un excelente cmdlet para esta funcionalidad llamada 'get-winevent'. El rendimiento más rápido que he visto implica el uso de tablas hash. Aquí hay un ejemplo que obtiene todos los eventos en el registro de seguridad pertenecientes a un usuario específico desde el último día:

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

$ userevt ahora es una colección de eventos. Dependiendo del número de coincidencias, puede canalizarlo a la lista de formato para leer fácilmente una pequeña cantidad de eventos. Para un número medio, haga lo mismo pero redirija la salida a un archivo:

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

Para un gran número, comience a filtrar (supongamos que desea que la computadora que llama para un evento de bloqueo en el usuario que adquirimos anteriormente):

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

Esto mostrará un resultado de una sola línea para cada evento de bloqueo. Los procesos anteriores generalmente demoran de 1 a 4 minutos para un registro de 4 GB en 2008 R2.

En segundo lugar, especialmente para cualquier máquina 2003 que pueda tener que administrar, puede hacer clic con el botón derecho en un archivo de registro particular en el panel izquierdo en el visor de eventos y seleccionar 'guardar archivo de registro como'.

Si está ejecutando el visor de eventos en la máquina local, puede guardar un archivo .evt que get-winevent puede analizar.

Alternativamente, puede guardar un archivo de texto o CSV (creo que CSV es más fácil) que puede ser analizado por las utilidades de línea de comandos apropiadas como grep o findtr, o ciertos programas como notepad ++.

Ejemplo del mundo real: esto ocurrió cuando los registros de seguridad aumentaron a 12 GB para permitir una retención de 6 meses según un requisito de cumplimiento.

Para el mes 3 no pudimos iniciar sesión en los servidores 2008r2 y 2012r2. El inicio de sesión se atascaría en la pantalla "Bienvenido". Intentamos aumentar la memoria del servidor a 20 gb para acomodar los archivos grandes que se están abriendo y el servidor todavía estaba enojado. Terminamos decidiendo seguir la recomendación del motor de administración de 1 GB y ajustarla para archivar el archivo antiguo cuando está lleno versus sobrescribir.

Tenemos este script para limpiar archivos antiguos de más de 180 días si lo necesitamos, pero es probable que podamos mantener los archivos en su lugar.

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