Які наслідки перевищують 4 Гб у Журналі подій Windows?

Я виявив цей Microsoft KB, який охоплює рекомендовані параметри журналу подій для операційних систем до Windows 2008 / Vista , який рекомендує максимум 4 Гб, і я побачив деякі інші нечіткі посилання, що журнал подій більше 4 Гб не рекомендується принаймні 2008 R2, але мені цікаво, що насправді відбувається, якщо журнал подій перевищує цей розмір?

Я перевищив це на тестовому сервері (2012 R2) і не помітив нічого, як високе використання пам'яті і т. Д. Нам не важливо ОС, перш ніж R2 2008, але хочемо великого журналу, оскільки ми збираємо події з багатьох машин через Перенаправлення подій 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

Інша відповідь стосується міркувань цього - для сучасних систем, здебільшого зберігаючи час завантаження в інтерфейсі 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

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