Каковы последствия превышения 4 ГБ в журнале событий Windows?

Я обнаружил этот 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

https://www.manageengine.com/products/active-directory-audit/help/getting-started/event-log-size-retention-settings.html