Encontrei esta base de conhecimento da Microsoft que cobre os máximos recomendados de configuração de log de eventos para sistemas operacionais até Windows 2008/Vista, que recomenda um máximo de 4 GB, e vi algumas outras referências vagas de que um log de eventos maior que 4 GB não é recomendado pelo menos no 2008 R2, mas estou me perguntando o que realmente acontece se um log de eventos exceder esse tamanho?
Ultrapassei isso em um servidor de teste (2012 R2) e não notei nada como alto uso de memória, etc. Não nos importamos 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.
Responder1
Além do péssimo desempenho e dos tempos de espera ridículos quando você precisa carregar um log de 4 GB e que inferno será se você tiver que pesquisar algo tão monstruoso, não muito. Acho que o maior que vi em meus ambientes foi de 10 GB e, embora tenha desistido de esperar carregar, não pareceu prejudicar nada.
O cuidado 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 se alguém chegou perto de testar esse limite.
Claro, se você ainda não o fez, descobrirá que arquivos de log muito grandes são simplesmente impraticáveis de usar - a última vez que tentei carregar um arquivo de log simples de 100 GB (texto), ele nem sequer pôde ser aberto sem travando o aplicativo ao abri-lo, e suspeito que você encontrará 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 de vez em quando. Eu uso o seguinte 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 arquivos de log enormes. Vou encerrar 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 gravação novamente. E como há backup da pasta para onde os copio, sempre podemos voltar aos logs no evento horrível que precisarmos.
#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
Responder2
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 tanto suportável. Copiar o log atual para um local onde seja feito backup e depois limpá-lo também é bom.
Para analisar arquivos de log grandes que acabam sendo gerados de qualquer maneira, ocorrem duas boas opções:
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 para 2), então vou me concentrar em 1).
Em primeiro lugar, o Powershell possui um excelente cmdlet para esta funcionalidade chamado ‘get-winevent’. O desempenho mais rápido que já vi envolve o uso de tabelas hash. Aqui está um exemplo que obtém todos os eventos do último dia no log de segurança pertencentes a um usuário específico:
$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 número grande, comece a filtrar (digamos que você queira que o computador chamador sofra um evento de bloqueio do 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 qualquer máquina de 2003 que você possa ter que gerenciar, você pode clicar com o botão direito 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 por get-winevent.
Alternativamente, você pode salvar um arquivo de texto ou CSV (acho CSV mais fácil) que pode ser analisado por utilitários de linha de comando apropriados, como grep ou findstr, ou certos programas como notepad++.
Responder3
Exemplo do mundo real: isso ocorreu com o aumento dos logs de segurança para 12 GB para permitir retenção de 6 meses de acordo com um requisito de conformidade.
No terceiro mês, não conseguimos fazer logon nos servidores 2008r2 e 2012r2. O logon ficaria 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 irritado. Acabamos decidindo seguir a recomendação do mecanismo de gerenciamento de 1 GB e ajustá-lo para arquivar arquivos antigos quando cheios ou sobrescrever.
Temos esse script para limpar arquivos antigos com mais de 180 dias, se precisarmos, mas provavelmente podemos apenas manter os arquivos no lugar.
get-childitem -Path "C:\Windows\System32\winevt\Logs" |
where-object {$_.LastWriteTime -lt (get-date).AddDays(-180)} |
remove-item –whatif
Responder4
Existem muitos relatórios (1,2,3) que mesmo no Windows Vista/Server 2008 e posteriores, os logs de eventos 'clássicos' (Aplicativos, Segurança, Sistema e alguns outros) ainda podem causar esgotamento da memória se o tamanho máximo for definido muito alto - parece que eles ainda podem ser ' memória mapeada'.
Embora a Microsoft possadizer em sua documentação sobre o tema:
O Windows Vista e o Windows Server 2008 usam uma nova infra-estrutura de relatórios de eventos e não apresentam o comportamento descrito nos parágrafos a seguir.
Nos testes, parece que isso podeapenasaplicam-se aos novos logs de 'tecnologia de log de eventos do Windows' e 'rastreamento de eventos para Windows' introduzidos no Windows Vista - a seguinte documentação sobre oGet-WinEventeObter-EventLogOs cmdlets sugerem que os logs 'clássicos' ainda podem ser executados na tecnologia mais antiga:
O cmdlet Get-WinEvent obtém eventos de logs de eventos,incluindo registros clássicos, tais como oLogs do sistema e do aplicativo. O cmdlet obtém dados de logs de eventos gerados peloTecnologia de log de eventos do Windows introduzida no Windows Vistae eventos em arquivos de log gerados porRastreamento de eventos para Windows (ETW). Por padrão, Get-WinEvent retorna informações de eventos na ordem do mais recente para o mais antigo.
Os cmdlets do PowerShell que contêm o substantivo EventLog funcionam apenas no Windows logs de eventos clássicoscomoAplicativo, sistema ou segurança. Para obter registros que usam oTecnologia de log de eventos do Windows no Windows Vista e versões posteriores do Windows, use Get-WinEvent.
A execução deste cmdlet do PowerShell mesmo no Windows 11 mostra que os logs de aplicativos, segurança e eventos do sistema, entre outros, ainda estão em execução no modo ‘Clássico’, o que pode explicar o comportamento relatado.
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
Você pode verificar quanta memória livre está sendo usada para 'arquivos mapeados' usando a ferramenta Sysinternals RAMMap(7). Na página 'Resumo do arquivo' você pode ver que quase todo o log de eventos de segurança está na memória ativa:
Portanto, embora o limite de >4 GB não se aplique mais a servidores x64, parece que muitosterdescobriu que tamanhos grandes para os logs de eventos 'Clássicos' (especialmente o log de eventos de segurança) podem consumir memória livre mesmo em sistemas operacionais mais recentes, uma vez que esses logs de eventos permanecem 'mapeados na memória' e reduzindo o tamanho máximo do log e limpando os logs corrige o problema. Portanto, tenha cuidado antes de definir um valor muito alto.