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

Encontrei este Microsoft KB que cobre os máximos recomendados de configuração de log de eventos para sistemas operacionais até Windows 2008 / Vista , que recomenda no máximo 4 GB, e vi algumas outras referências vagas de que um log de eventos maior que 4 GB não é recomendado pelo menos 2008 R2, mas estou imaginando o que realmente acontece se um log de eventos exceder esse tamanho?

Eu excedi 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 sistemas operacionais anteriores a 2008 R2, mas queremos um log grande porque estamos coletando eventos de muitas máquinas via Encaminhamento de eventos do Windows e deseja ter todos os eventos em um só lugar.

Além do desempenho horrível e dos tempos de espera ridículos, quando você precisa carregar um log de 4 GB e, diabos, será se você precisar pesquisar algo tão monstruoso, não muito. Acho que o maior que já vi em meus ambientes foi de 10 GB e, embora tenha desistido de esperar o carregamento, ele não pareceu prejudicar nada.

A cautela de 4 GB para o Server 2008 se deve ao limite de 32 bits que geralmente é encontrado em 4 GB. Em um sistema de 64 bits, você deve permitir que ele cresça até 16 TB (ou 64, dependendo), embora eu não saiba que alguém chegou perto de testar esse limite.

Obviamente, se você ainda não o fez, descobrirá que arquivos de log muito grandes são simplesmente impraticáveis ​​de usar - da última vez que tentei carregar um arquivo de log simples de 100 GB (texto), ele não poderia ser aberto sem travando o aplicativo ao abri-lo, e suspeito que você acerte esse problema bem antes de 100 GB.

A abordagem muito melhor é limitar o tamanho do arquivo a algo razoável e usar um script para limpá-lo periodicamente. Eu uso o abaixo em 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 grandes arquivos de log que encerrarei antes de analisar, de modo que meu script copia o conteúdo do log para outra pasta e, em seguida, limpa o log de eventos a ser gravado novamente. E como é feito o backup da pasta na qual eu os copio, sempre podemos voltar aos logs no evento horrível 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

A outra resposta cobre o raciocínio por trás disso - para sistemas modernos, mantendo principalmente os tempos de carregamento na GUI do visualizador de eventos. Copiar o log atual para um local que é copiado e depois limpá-lo também é bom.

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

1) Analise o log mais rapidamente 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 para 2), então vou me concentrar em 1).

Em primeiro lugar, o Powershell possui um excelente cmdlet para essa funcionalidade chamada 'get-winevent'. O desempenho mais rápido que eu já vi envolve o uso de tabelas de hash. Aqui está um exemplo que obtém todos os eventos no log de segurança pertencentes a um usuário específico desde o ú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 direcioná-lo para a lista de formatação 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 número grande, inicie a filtragem (digamos que você queira que o computador de chamada faça 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 em qualquer máquina 2003 que você possa precisar gerenciar, clique com o botão direito do mouse em um arquivo de log específico no painel esquerdo no visualizador de eventos e selecione '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 por get-winevent.

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

Exemplo do mundo real: isso ocorreu com o aumento do tamanho dos logs de segurança para 12 GB, para permitir a retenção de 6 meses por um requisito de conformidade.

No terceiro mês, não conseguimos fazer logon nos servidores 2008r2 e 2012r2. O logon fica preso na tela "Bem-vindo". Tentamos aumentar a memória do servidor para 20 GB para acomodar os arquivos grandes que estavam sendo abertos e o servidor ainda estava com raiva. Acabamos decidindo seguir a recomendação de 1 GB do mecanismo de gerenciamento e ajustá-la para arquivar o arquivo antigo quando estiver cheio ou sobrescrito.

Temos esse script para limpar arquivos antigos com mais de 180 dias, se precisarmos, mas provavelmente podemos manter os arquivos no 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