Каковы последствия чрезмерных 4 ГБ в Windows Event Log?
Я нашел эту базу знаний Microsoft, которая покрывает рекомендуемые максимумы установки Event Log для операционных систем до Windows 2008/Vista, который рекомендует максимум 4 ГБ и видел некоторые другие неопределенные ссылки, которые журнал событий, больше, чем 4 ГБ, не рекомендуется по крайней мере в 2 008 R2, но я задаюсь вопросом, что на самом деле происходит, если журнал событий превышает этот размер?
Я превысил это на тестовом сервере (2 012 R2) и не заметил ничего как использование верхней памяти и т.д. Мы не заботимся о Ose до 2008 о R2, но хотим большой журнал, потому что мы собираем события из многих машин с помощью Windows Event Forwarding и хотим иметь все события в одном месте.
Кроме ужасной производительности и нелепых времен ожидания, когда вам нужно загрузить 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
Другой ответ касается аргументации - для современных систем, в основном сохраняющих время загрузки в пределах GUI просмотрщика событий несколько сносным. Также хорошо копировать текущий лог в место, где создается резервная копия, а затем очищать его.
Для разбора больших лог-файлов, которые все равно генерируются, есть две хорошие опции:
1) Разбирать лог быстрее, чем текущий GUI может управлять или 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, или некоторых программ, таких как блокнот++.
.Пример из реальной жизни: У нас это произошло, когда размер журналов безопасности был увеличен до 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