11 votos

¿Cuáles son las implicaciones de más de 4 GB en un Registro de Eventos de Windows?

He encontrado este de Microsoft KB que cubre recomienda el Registro de Eventos configuración de máximos para los sistemas operativos Windows 2008/Vista, en la que se recomienda un máximo de 4 GB, y he visto algunas otras referencias vagas de que un Evento de Registro de más de 4 GB no se recomienda en al menos 2008 R2, pero me pregunto lo que en realidad sucede si un registro de eventos supera este tamaño?

He superado esta en un servidor de prueba (2012 R2) y no he notado nada como el uso de memoria alta, etc. No nos preocupamos de los sistemas operativos antes del 2008 R2, pero quieren tener un registro de gran tamaño debido a que estamos recogiendo los eventos de muchas máquinas a través de Windows envío de Eventos y quieren tener todos los eventos en un solo lugar.

8voto

HopelessN00b Puntos 38607

Aparte de la terrible rendimiento y ridículo de los tiempos de espera cuando tiene que cargar un 4 GB de registro y el infierno será si alguna vez tiene que buscar a través de esa cosa monstruosa, no mucho. Creo que el más grande que he visto en mi ambientes fue de 10 GB, y aunque me dio esperando a que se cargue, no parece dañar nada.

Los 4 gb de precaución para Server 2008 es debido a que 32 bits límite que a menudo se encuentran en los 4 GB. En un sistema de 64 bits, que debe estar bien para dejarlo crecer para hasta 16 TB (o de 64, dependiendo), aunque no sé que nadie ha vuelto a acercarse a probar ese límite.

Por supuesto, si aún no lo ha hecho, usted descubrirá que una gran cantidad de archivos de registro son simplemente poco práctico utilizar - la última vez que he intentado cargar una simple 100 GB (texto) del archivo de registro, que ni siquiera podía abrirse sin que se caiga la solicitud de apertura, y sospecho que va a golpear a esa cuestión antes de 100 GB.

El enfoque mucho mejor es limitar el tamaño del archivo a algo razonable, y utilizar un script para borrar un vistazo de vez en cuando. Yo uso el de abajo en mi entorno, combinado con un 1 GB de límite de tamaño en nuestro registro de seguridad. Algunos (bueno, la mayoría) de nuestros servidores generar más de 3 GB de seguridad de los eventos por día, y no queremos perder espacio en enormes archivos de registro voy a dejar de fumar antes de peinar a través de, por lo que mi script copia el contenido del registro a otra carpeta y, a continuación, se borra el registro de eventos a escribirse de nuevo. Y desde la carpeta copio a es una copia de seguridad, siempre podemos volver a los registros en el horrible suceso 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

2voto

Bruno Puntos 36

La otra respuesta cubre el razonamiento detrás de esto - para los sistemas modernos, en su mayoría mantener los tiempos de carga en el visor de eventos GUI algo soportable. Copia del registro actual a una ubicación en la que se copia de seguridad, luego de compensación, también es bueno.

Para el análisis de grandes archivos de registro que terminan siendo generado de todos modos, dos buenas opciones de ocurrir:

1) Analizar el registro más rápido que el actual GUI puede administrar o 2) Dividir la sesión en archivos separados.

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

En primer lugar, Powershell tiene una excelente cmdlet para esta funcionalidad llamada 'winevent'. El rendimiento más rápido he visto que implica el uso de tablas hash. He aquí un ejemplo de que obtiene todos los eventos en el registro de seguridad pertenecientes a un usuario específico a partir 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 del número de partidos, se puede canalizar a través de un formato de lista para leer fácilmente en un pequeño número de eventos. Para un número medio, hacer lo mismo pero redirigir la salida a un archivo:

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

Para un gran número de inicio de filtrado (digamos que quiere la persona que llama equipo para un suceso de bloqueo de usuario en la adquisición de arriba):

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

Esto muestra una sola línea de resultado para cada suceso de bloqueo. Los procesos anteriores, en general tomar de 1 a 4 minutos para la una de 4GB de registro en 2008 R2.

En segundo lugar, especialmente para cualquier 2003 máquinas usted podría terminar encima de tener que administrar, usted puede hacer clic derecho sobre un determinado archivo de registro en el panel de la izquierda en el visor de sucesos, y seleccione 'guardar archivo de registro como".

Si se ejecuta el visor de sucesos en el local de la máquina, usted puede ahorrar .archivo evt que puede ser interpretado por get-winevent.

Como alternativa, puede guardar un archivo de texto o CSV (me parece más fácil CSV) que puede ser interpretado por los correspondientes utilidades de línea de comandos tales como grep o findstr, o ciertos programas como el bloc de notas++.

EnMiMaquinaFunciona.com

EnMiMaquinaFunciona es una comunidad de administradores de sistemas en la que puedes resolver tus problemas y dudas.
Puedes consultar las preguntas de otros sysadmin, hacer tus propias preguntas o resolver las de los demás.

Powered by: