Я нашел этот Microsoft KB, который охватывает рекомендуемые максимальные настройки журнала событий для операционных систем до Windows 2008 / Vista., который рекомендует не более 4 ГБ и видел некоторые другие расплывчатые упоминания о том, что журнал событий размером более 4 ГБ не рекомендуется по крайней мере в 2008 R2, но мне интересно, что на самом деле происходит, если журнал событий превышает этот размер?
Я превысил это значение на тестовом сервере (2012 R2) и не заметил ничего подобного высокому использованию памяти и т. Д. Мы не заботимся об ОС до 2008 R2, но хотим иметь большой журнал, потому что мы собираем события со многих машин через Пересылка событий Windows и хотите, чтобы все события были в одном месте.
Если не считать ужасной производительности и нелепого времени ожидания, когда вам нужно загрузить журнал размером 4 ГБ, и, черт возьми, это будет, если вам когда-нибудь придется искать такую чудовищную вещь, не так много. Я думаю, что самый большой из тех, что я видел в своих средах, был 10 ГБ, и хотя я перестал ждать его загрузки, похоже, он ничему не повредил.
Предупреждение о 4 ГБ для Server 2008 связано с 32-разрядным пределом, который часто встречается на уровне 4 ГБ. В 64-битной системе у вас должно быть все в порядке, если вы позволите ей вырасти до 16 ТБ (или до 64, в зависимости от того, что), хотя я не знаю, чтобы кто-то приблизился к тестированию этого предела.
Конечно, если вы еще этого не сделали, вы обнаружите, что очень большие файлы журнала просто непрактично использовать - в последний раз, когда я пытался загрузить простой (текстовый) файл журнала размером 100 ГБ, его невозможно было даже открыть без сбой приложения, открывающего его, и я подозреваю, что вы столкнетесь с этой проблемой задолго до 100 ГБ.
Намного лучший подход - ограничить размер файла чем-то разумным и время от времени очищать его с помощью сценария. Я использую приведенное ниже в своей среде в сочетании с ограничением размера в 1 ГБ в нашем журнале безопасности. Некоторые (ну, большинство) наших серверов генерируют более 3 ГБ событий безопасности в день, и мы не хотим тратить все это пространство на огромные файлы журналов, которые я выйду, прежде чем прочесать их, поэтому мой сценарий копирует содержимое журнала в в другую папку, а затем очищает журнал событий для повторной записи. А поскольку папка, в которую я их копирую, имеет резервную копию, мы всегда можем вернуться к журналам в случае ужасного события, которое нам нужно.
#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
Другой ответ объясняет причину этого - для современных систем, в основном, сохраняя время загрузки в графическом интерфейсе средства просмотра событий несколько терпимым. Копирование текущего журнала в место, для которого создается резервная копия, а затем его очистка - тоже хорошо.
Для анализа больших файлов журналов, которые все равно создаются, есть два хороших варианта:
1) Анализируйте журнал быстрее, чем может управлять текущий графический интерфейс, или 2) Разделите журнал на отдельные файлы.
Я уверен, что есть несколько легко доступных утилит для 2), поэтому я сосредоточусь на 1).
Во-первых, в Powershell есть отличный командлет для этой функции, называемый get-winevent. Самая высокая производительность, которую я видел, связана с использованием хеш-таблиц. Вот пример, который получает все события в журнале безопасности, относящиеся к конкретному пользователю, за последний день:
$timeframe = (get-date) - (new-timespan -day 1)
$userevt = Get-WinEvent -ComputerName <specify> -FilterHashTable @{LogName='Security'; Data='<enter username here>'; StartTime=$timeframe}
$ userevt теперь представляет собой набор событий. В зависимости от количества совпадений вы можете перенаправить его в список форматирования, чтобы легко прочитать небольшое количество событий. Для среднего числа сделайте то же самое, но перенаправьте вывод в файл:
$userevt | format-list > <outputfile>.txt
Для большого количества начните фильтрацию (скажем, вы хотите, чтобы вызывающий компьютер заблокировал событие для пользователя, которого мы получили выше):
$userevt | %{if ($_.message -match "Caller Computer .*") {$matches[0]}}
Это покажет однострочный результат для каждого события блокировки. Вышеупомянутые процессы обычно занимают 1–4 минуты для журнала размером 4 ГБ на 2008 R2.
Во-вторых, особенно для любых машин 2003 года, которыми вам, возможно, придется управлять, вы можете щелкнуть правой кнопкой мыши конкретный файл журнала на левой панели в средстве просмотра событий и выбрать «сохранить файл журнала как».
Если вы запускаете программу просмотра событий на локальном компьютере, вы можете сохранить файл .evt, который можно будет проанализировать с помощью get-winevent.
В качестве альтернативы вы можете сохранить текстовый или CSV-файл (я считаю, что CSV проще), который может быть проанализирован соответствующими утилитами командной строки, такими как grep или findstr, или некоторыми программами, такими как notepad ++.
Пример из реальной жизни: это произошло, когда размер журналов безопасности был увеличен до 12 ГБ, чтобы обеспечить хранение в течение 6 месяцев в соответствии с требованиями соответствия.
К 3 месяцу мы не смогли войти на серверы 2008r2 и 2012r2. Вход в систему останавливался на экране «Добро пожаловать». Мы попытались увеличить память сервера до 20 ГБ, чтобы вместить открываемые большие файлы, но сервер все еще злился. В итоге мы решили последовать рекомендации движка управления размером 1 ГБ и настроить его для архивации старого файла при его заполнении, а не перезаписи.
У нас есть этот скрипт для очистки старых файлов старше 180 дней, если он нам нужен, но мы, вероятно, можем просто оставить файлы на месте.
get-childitem -Path "C:\Windows\System32\winevt\Logs" |
where-object {$_.LastWriteTime -lt (get-date).AddDays(-180)} |
remove-item –whatif