Encontré esta base de conocimientos 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 no se recomienda un registro de eventos mayor a 4 GB al menos en 2008 R2, pero me pregunto qué sucede realmente si un registro de eventos excede este tamaño.
Superé esto en un servidor de prueba (2012 R2) y no noté nada como un uso elevado de memoria, etc. No nos importan los sistemas operativos anteriores a 2008 R2, pero queremos un registro grande porque estamos recopilando eventos de muchas máquinas a través de Windows Event Forwarding y quieres tener todos los eventos en un solo lugar.
Respuesta1
Aparte del pésimo rendimiento y los ridículos tiempos de espera cuando tienes que cargar un registro de 4 GB y qué diablos será si alguna vez tienes que buscar en algo tan monstruoso, no mucho. Creo que el más grande que he visto en mis entornos era de 10 GB, y aunque dejé de esperar a que cargara, no pareció perjudicar nada.
La precaución de 4 GB para Server 2008 se debe al límite de 32 bits que a menudo se encuentra en 4 GB. En un sistema de 64 bits, debería poder dejar que crezca hasta 16 TB (o 64, dependiendo), aunque no sé si alguien se ha 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 se podía abrir sin bloquea la aplicación al abrirla 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 un tamaño razonable y utilizar 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 archivos de registro enormes que cerraré antes de revisarlos, por lo que mi secuencia de comandos copia el contenido del registro en otra carpeta y luego borra el registro de eventos para volver a escribir. Y dado que la carpeta donde los copio tiene una copia de seguridad, siempre podemos volver a los registros en el horrible caso de que lo necesitemos.
#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
Respuesta2
La otra respuesta cubre el razonamiento detrás de esto: para los sistemas modernos, en su mayoría mantener los tiempos de carga dentro de la GUI del visor de eventos es algo soportable. También es bueno copiar el registro actual en una ubicación de la que se haga una copia de seguridad y luego borrarlo.
Para analizar archivos de registro grandes que terminan generándose de todos modos, existen dos buenas opciones:
1) Analizar el registro más rápido de lo que la GUI actual puede administrar o 2) Dividir el registro en archivos separados.
Estoy seguro de que existen algunas utilidades fácilmente disponibles para 2), así que me centraré en 1).
En primer lugar, Powershell tiene un cmdlet excelente para esta funcionalidad llamado 'get-winevent'. El rendimiento más rápido que he visto implica el uso de tablas hash. A continuación se muestra un ejemplo que obtiene todos los eventos en el registro de seguridad pertenecientes a un usuario específico del ú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 de la cantidad de coincidencias, puede canalizarlo a format-list 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 número grande, comience a filtrar (supongamos que desea que la computadora que llama tenga 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 entre 1 y 4 minutos para un registro de 4 GB en 2008 R2.
En segundo lugar, especialmente para cualquier máquina 2003 que tenga que administrar, puede hacer clic con el botón derecho en un archivo de registro en particular en el panel izquierdo del 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 puede ser analizado por get-winevent.
Alternativamente, puede guardar un archivo de texto o CSV (creo que CSV es más fácil) que puede analizarse mediante utilidades de línea de comandos apropiadas como grep o findstr, o ciertos programas como notepad++.
Respuesta3
Ejemplo del mundo real: esto ocurrió cuando los registros de seguridad se aumentaron a un tamaño de 12 GB para permitir una retención de 6 meses según un requisito de cumplimiento.
Al tercer mes no pudimos iniciar sesión en los servidores 2008r2 y 2012r2. El inicio de sesión se atascaba en la pantalla "Bienvenida". Intentamos aumentar la memoria del servidor a 20 GB para dar cabida a los archivos grandes que se estaban abriendo y el servidor todavía estaba enojado. Terminamos decidiéndonos por seguir la recomendación del motor de administración de 1 GB y ajustarlo para archivar el archivo antiguo cuando esté lleno en lugar de sobrescribirlo.
Tenemos este script para limpiar archivos antiguos de más de 180 días si lo necesitamos, pero probablemente 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
Respuesta4
Hay muchos informes (1,2,3) que incluso en Windows Vista/Server 2008 y posteriores, los registros de eventos 'clásicos' (Aplicación, Seguridad, Sistema y algunos otros) aún pueden causar agotamiento de la memoria si el tamaño máximo se establece demasiado alto; parece que todavía pueden serlo. memoria mapeada'.
Si bien Microsoft puededecir en su documentación sobre el tema:
Windows Vista y Windows Server 2008 utilizan una nueva infraestructura de informes de eventos y no presentan el comportamiento descrito en los siguientes párrafos.
En las pruebas parece que esto puedesolose aplican a los nuevos registros 'Tecnología de registro de eventos de Windows' y 'Seguimiento de eventos para Windows' introducidos en Windows Vista: la siguiente documentación sobreEvento Obtener-GanaryObtener registro de eventosLos cmdlets sugieren que los registros "clásicos" aún pueden ejecutarse en la tecnología anterior:
El cmdlet Get-WinEvent obtiene eventos de los registros de eventos,incluyendo registros clásicos, tales como elRegistros del sistema y de aplicaciones. El cmdlet obtiene datos de los registros de eventos generados por elTecnología de registro de eventos de Windows introducida en Windows Vistay eventos en archivos de registro generados porSeguimiento de eventos para Windows (ETW). De forma predeterminada, Get-WinEvent devuelve información de eventos en orden del más nuevo al más antiguo.
Los cmdlets de PowerShell que contienen el nombre EventLog solo funcionan en Windows registros de eventos clásicoscomoAplicación, sistema o seguridad. Para obtener registros que utilizan elTecnología de registro de eventos de Windows en Windows Vista y versiones posteriores de Windows, utilice Get-WinEvent.
La ejecución de este cmdlet de PowerShell incluso en Windows 11 muestra que los registros de eventos del sistema, de seguridad y de aplicaciones, entre otros, todavía se ejecutan en modo "Clásico", lo que puede explicar el comportamiento informado.
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
Puede verificar cuánta memoria libre se está utilizando para los 'archivos mapeados' usando la herramienta Sysinternals RAMMap (7). En la página "Resumen de archivos" puede ver que casi todo el registro de eventos de seguridad está en la memoria activa:
Por lo tanto, aunque el límite de >4 GB ya no se aplica en servidores x64, parece que muchostenerdescubrió que los tamaños grandes para los registros de eventos 'Clásicos' (especialmente el registro de eventos de seguridad) pueden consumir memoria libre incluso en sistemas operativos más nuevos, ya que estos registros de eventos permanecen 'mapeados en memoria' y reducen el tamaño máximo del registro y borran los registros. soluciona el problema. Así que tenga cuidado antes de ponerlo demasiado alto.