Quais são as implicações de exceder 4 GB em um log de eventos do Windows?

Question

Encontrei este KB da Microsoft que cobre os máximos recomendados para os sistemas operacionais até o Windows 2008 / Vista . , que recomenda um máximo de 4 GB, e ter visto algumas outras referências vagas que um log de eventos maior que 4 GB não é recomendado em pelo menos 2008 R2, mas eu estou querendo saber o que realmente acontece se um log de eventos exceder esse tamanho? p>

Eu superei isso em um servidor de teste (2012 R2) e não notei nada como alto uso de memória, etc. Não nos preocupamos com SO antes de 2008 R2, mas queremos um log grande porque estamos coletando eventos de muitas máquinas via Windows Event Forwarding e deseja ter todos os eventos em um só lugar.

    

Answer 1

Além do desempenho horrível e tempos de espera ridículos quando você tem que carregar um log de 4 GB e o inferno será se você já tem que procurar através de uma coisa tão monstruosa, não muito. Eu acho que o maior que eu vi em meus ambientes foi de 10 GB, e embora eu tenha desistido de esperar para carregar, não pareceu prejudicar nada.

O aviso de 4 GB para o Servidor 2008 deve-se ao limite de 32 bits frequentemente encontrado em 4 GB. Em um sistema de 64 bits, você deve estar bem para deixá-lo crescer até 16 TB (ou 64, dependendo), embora eu não saiba que alguém chegou perto de testar esse limite.

É claro que, se você ainda não tiver feito isso, descobrirá que arquivos de log muito grandes são simplesmente impraticáveis de usar - a última vez que tentei carregar um simples arquivo de log de 100 GB (texto), ele não ser aberto sem travar o aplicativo de abertura, e eu suspeito que você vai bater esse problema bem antes de 100 GB.

A melhor abordagem é limitar o tamanho do arquivo a algo razoável e usar um script para apagá-lo de tempos em tempos. Eu uso o abaixo no meu ambiente, combinado com um limite de tamanho de 1 GB em nosso log de segurança. Alguns (bem, a maioria) de nossos servidores geram mais de 3 GB de eventos de segurança por dia, e não queremos desperdiçar todo esse espaço em arquivos de log enormes que eu fecho antes de vasculhar, então meu script copia o conteúdo do log para outra pasta e, em seguida, limpa o log de eventos para ser gravado novamente. E como a pasta para a qual eu copio é salva, sempre podemos voltar aos logs no horrível evento que precisamos.

#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

    

Answer 2

A outra resposta cobre o raciocínio por trás disso - para sistemas modernos, principalmente mantendo os tempos de carregamento dentro da GUI do visualizador de eventos um pouco suportável. Copiar o registro atual para um local que é salvo em backup e, em seguida, limpá-lo também é bom.

Para analisar grandes arquivos de log que acabam sendo gerados de qualquer maneira, duas boas opções ocorrem:

1) Analise o log mais rápido do que a GUI atual pode gerenciar ou 2) Divida o log em arquivos separados.

Tenho certeza de que existem alguns utilitários facilmente disponíveis por aí para 2), então vou focar em 1).

Em primeiro lugar, o Powershell tem um excelente cmdlet para essa funcionalidade chamada "get-winevent". O desempenho mais rápido que vi envolve o uso de tabelas de hash. Veja um exemplo que obtém todos os eventos no log de segurança referentes a um usuário específico do último dia:

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

$ userevt é agora uma coleção de eventos. Dependendo do número de correspondências, você pode canalizá-lo para a lista de formatos para ler facilmente um pequeno número de eventos. Para um número médio, faça o mesmo, mas redirecione a saída para um arquivo:

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

Para um grande número, inicie a filtragem (digamos que você queira que o computador chamador tenha um evento de bloqueio no usuário que adquirimos acima):

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

Isso mostrará um resultado de linha única para cada evento de bloqueio. Os processos acima geralmente levam de 1 a 4 minutos para um log de 4 GB no 2008 R2.

Em segundo lugar, especialmente para máquinas 2003 que você pode acabar tendo que gerenciar, você pode clicar com o botão direito do mouse em um arquivo de log específico no painel esquerdo do visualizador de eventos e selecionar 'salvar arquivo de log como'.

Se você estiver executando o visualizador de eventos na máquina local, poderá salvar um arquivo .evt que pode ser analisado pelo get-winevent.

Como alternativa, você pode salvar um arquivo de texto ou CSV (eu acho o CSV mais fácil) que pode ser analisado por utilitários de linha de comando apropriados como grep ou findstr, ou certos programas como o notepad ++.

    

Answer 3

Exemplo do mundo real: Isso ocorreu com o aumento dos registros de segurança para 12 GB para permitir uma retenção de 6 meses por requisito de conformidade.

No mês 3, não foi possível fazer logon nos servidores 2008r2 e 2012r2 dos servidores. O logon ficaria preso na tela "Bem-vindo". Tentamos aumentar a memória do servidor para 20 gb para acomodar os arquivos grandes que estão sendo abertos e o servidor ainda estava com raiva. Acabamos decidindo seguir a recomendação de 1GB do gerenciador de mecanismo e ajustá-lo para arquivar o arquivo antigo quando completo versus sobrescrever.

Temos esse script para limpar arquivos antigos com mais de 180 dias, se precisarmos, mas provavelmente só manteremos os arquivos no lugar.

get-childitem -Path "C:\Windows\System32\winevt\Logs" |
  where-object {$_.LastWriteTime -lt (get-date).AddDays(-180)} |
  remove-item –whatif

link