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

Question 1

Кроме ужасной производительности и смехотворного времени ожидания, когда вам нужно загрузить журнал размером 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

Answer

Кроме ужасной производительности и смехотворного времени ожидания, когда вам нужно загрузить журнал размером 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

Question 2

Другой ответ касается обоснования этого - для современных систем, в основном, сохранение времени загрузки в графическом интерфейсе просмотра событий более-менее терпимым. Копирование текущего журнала в место, которое резервируется, а затем его очистка, также хороши.

Для анализа больших файлов журналов, которые в любом случае создаются, есть два хороших варианта:

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 теперь является коллекцией событий. В зависимости от количества совпадений вы можете передать его в format-list, чтобы легко прочитать небольшое количество событий. Для среднего количества сделайте то же самое, но перенаправьте вывод в файл:

$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++.

Answer

Другой ответ касается обоснования этого - для современных систем, в основном, сохранение времени загрузки в графическом интерфейсе просмотра событий более-менее терпимым. Копирование текущего журнала в место, которое резервируется, а затем его очистка, также хороши.

Для анализа больших файлов журналов, которые в любом случае создаются, есть два хороших варианта:

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 теперь является коллекцией событий. В зависимости от количества совпадений вы можете передать его в format-list, чтобы легко прочитать небольшое количество событий. Для среднего количества сделайте то же самое, но перенаправьте вывод в файл:

$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++.

Question 3

Пример из реальной жизни: это произошло, когда размер журналов безопасности был увеличен до 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

Answer

Пример из реальной жизни: это произошло, когда размер журналов безопасности был увеличен до 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

Question 4

Есть много отчетов (1,2,3), что даже в Windows Vista / Server 2008 и более поздних версиях «классические» журналы событий (Приложения, Безопасность, Система и некоторые другие) по-прежнему могут вызывать исчерпание памяти, если максимальный размер установлен слишком большим — похоже, они все еще могут быть «отображены в памяти».

Хотя Microsoft можетсказать в их документации по теме:

Windows Vista и Windows Server 2008 используют новую инфраструктуру отчетов о событиях и не демонстрируют поведение, описанное в следующих параграфах.

При тестировании кажется, что это можеттолькоприменяются к новой технологии «Журнал событий Windows» и журналам «Трассировка событий для Windows», представленным в Windows Vista - следующая документация поПолучить-WinEventиПолучить-EventLogКомандлеты предполагают, что «классические» журналы могут по-прежнему работать на основе старой технологии:

Командлет Get-WinEvent получает события из журналов событий,включая классические журналы, такой какЖурналы системы и приложений. Командлет получает данные из журналов событий, которые генерируютсяТехнология журнала событий Windows, представленная в Windows Vistaи события в файлах журнала, сгенерированныхОтслеживание событий для Windows (ETW). По умолчанию Get-WinEvent возвращает информацию о событиях в порядке от новых к старым.

Командлеты PowerShell, содержащие существительное EventLog, работают только в Windows. классические журналы событийтакой какПриложение, система или безопасность. Чтобы получить журналы, которые используютТехнология журнала событий Windows в Windows Vista и более поздних версиях Windows, используйте Get-WinEvent.

Запуск этого командлета PowerShell даже в Windows 11 показывает, что журналы событий приложений, безопасности и системы, среди прочего, по-прежнему работают в «классическом» режиме, что может объяснять указанное поведение.

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

Вы можете проверить, сколько свободной памяти используется для «отображенных файлов», с помощью инструмента Sysinternals RAMMap (7). На странице «Сводка файлов» вы можете увидеть, что почти весь журнал событий безопасности находится в активной памяти:

Поэтому, хотя ограничение >4 ГБ больше не применяется на серверах x64, похоже, что многиеиметьобнаружили, что большие размеры журналов событий «Classic» (особенно журнала событий Security) могут занимать свободную память даже в новых операционных системах, поскольку эти журналы событий остаются «отображенными в памяти», а уменьшение максимального размера журнала и очистка журналов устраняют проблему. Поэтому будьте осторожны, прежде чем устанавливать слишком большое значение.

Answer

Есть много отчетов (1,2,3), что даже в Windows Vista / Server 2008 и более поздних версиях «классические» журналы событий (Приложения, Безопасность, Система и некоторые другие) по-прежнему могут вызывать исчерпание памяти, если максимальный размер установлен слишком большим — похоже, они все еще могут быть «отображены в памяти».

Хотя Microsoft можетсказать в их документации по теме:

Windows Vista и Windows Server 2008 используют новую инфраструктуру отчетов о событиях и не демонстрируют поведение, описанное в следующих параграфах.

При тестировании кажется, что это можеттолькоприменяются к новой технологии «Журнал событий Windows» и журналам «Трассировка событий для Windows», представленным в Windows Vista - следующая документация поПолучить-WinEventиПолучить-EventLogКомандлеты предполагают, что «классические» журналы могут по-прежнему работать на основе старой технологии:

Командлет Get-WinEvent получает события из журналов событий,включая классические журналы, такой какЖурналы системы и приложений. Командлет получает данные из журналов событий, которые генерируютсяТехнология журнала событий Windows, представленная в Windows Vistaи события в файлах журнала, сгенерированныхОтслеживание событий для Windows (ETW). По умолчанию Get-WinEvent возвращает информацию о событиях в порядке от новых к старым.

Командлеты PowerShell, содержащие существительное EventLog, работают только в Windows. классические журналы событийтакой какПриложение, система или безопасность. Чтобы получить журналы, которые используютТехнология журнала событий Windows в Windows Vista и более поздних версиях Windows, используйте Get-WinEvent.

Запуск этого командлета PowerShell даже в Windows 11 показывает, что журналы событий приложений, безопасности и системы, среди прочего, по-прежнему работают в «классическом» режиме, что может объяснять указанное поведение.

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

Вы можете проверить, сколько свободной памяти используется для «отображенных файлов», с помощью инструмента Sysinternals RAMMap (7). На странице «Сводка файлов» вы можете увидеть, что почти весь журнал событий безопасности находится в активной памяти:

Поэтому, хотя ограничение >4 ГБ больше не применяется на серверах x64, похоже, что многиеиметьобнаружили, что большие размеры журналов событий «Classic» (особенно журнала событий Security) могут занимать свободную память даже в новых операционных системах, поскольку эти журналы событий остаются «отображенными в памяти», а уменьшение максимального размера журнала и очистка журналов устраняют проблему. Поэтому будьте осторожны, прежде чем устанавливать слишком большое значение.

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

решение1

решение2

решение3

решение4

Связанный контент