Windows イベントログが 4 GB を超えるとどのような影響がありますか?

Question 1

4 GB のログをロードするときのひどいパフォーマンスと途方もない待ち時間、そしてそのような巨大なものを検索しなければならないときの地獄を除けば、大したことはありません。私の環境で見た最大のものは 10 GB だったと思いますが、ロードを待つのをあきらめましたが、何も害はなかったようです。

Server 2008 の 4 GB に関する注意は、4 GB でよく発生する 32 ビットの制限によるものです。64 ビットシステムでは、16 TB (または 64 TB、状況によります) まで拡張しても問題ありませんが、その制限をテストしたことがある人がいるかどうかはわかりません。

もちろん、まだ試していない場合でも、非常に大きなログファイルは使用するのが実用的ではないことがわかります。前回、単純な 100 GB (テキスト) ログファイルを読み込もうとしたとき、それを開くとアプリケーションがクラッシュしてしまい、開くことすらできませんでした。100 GB を超える前に、この問題が発生すると思われます。

はるかに良い方法は、ファイルサイズを妥当なサイズに制限し、スクリプトを使用して時々クリアすることです。私の環境では、セキュリティログの 1 GB サイズ制限と組み合わせて、以下を使用しています。一部の (ほとんどの) サーバーは、1 日に 3 GB を超えるセキュリティイベントを生成しますが、調べる前に終了する巨大なログファイルにそのすべてのスペースを無駄にしたくないため、スクリプトはログの内容を別のフォルダーにコピーし、イベントログをクリアして再度書き込みます。また、コピー先のフォルダーはバックアップされているため、必要な恐ろしいイベントが発生した場合はいつでもログに戻ることができます。

#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 GB のログをロードするときのひどいパフォーマンスと途方もない待ち時間、そしてそのような巨大なものを検索しなければならないときの地獄を除けば、大したことはありません。私の環境で見た最大のものは 10 GB だったと思いますが、ロードを待つのをあきらめましたが、何も害はなかったようです。

Server 2008 の 4 GB に関する注意は、4 GB でよく発生する 32 ビットの制限によるものです。64 ビットシステムでは、16 TB (または 64 TB、状況によります) まで拡張しても問題ありませんが、その制限をテストしたことがある人がいるかどうかはわかりません。

もちろん、まだ試していない場合でも、非常に大きなログファイルは使用するのが実用的ではないことがわかります。前回、単純な 100 GB (テキスト) ログファイルを読み込もうとしたとき、それを開くとアプリケーションがクラッシュしてしまい、開くことすらできませんでした。100 GB を超える前に、この問題が発生すると思われます。

はるかに良い方法は、ファイルサイズを妥当なサイズに制限し、スクリプトを使用して時々クリアすることです。私の環境では、セキュリティログの 1 GB サイズ制限と組み合わせて、以下を使用しています。一部の (ほとんどの) サーバーは、1 日に 3 GB を超えるセキュリティイベントを生成しますが、調べる前に終了する巨大なログファイルにそのすべてのスペースを無駄にしたくないため、スクリプトはログの内容を別のフォルダーにコピーし、イベントログをクリアして再度書き込みます。また、コピー先のフォルダーはバックアップされているため、必要な恐ろしいイベントが発生した場合はいつでもログに戻ることができます。

#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

他の回答では、この背後にある理由について説明しています。最新のシステムでは、主にイベントビューアー GUI 内の読み込み時間をある程度許容できる程度に抑えることが主な目的です。現在のログをバックアップされる場所にコピーしてからクリアするのも良い方法です。

いずれにせよ生成される大きなログファイルを解析するには、次の 2 つの適切なオプションがあります。

1) 現在の GUI が管理できるよりも高速にログを解析するか、2) ログを個別のファイルに分割します。

2) については簡単に入手できるユーティリティがいくつかあると思うので、ここでは 1) に焦点を当てます。

まず、Powershell にはこの機能のための優れたコマンドレット「get-winevent」があります。私が見た中で最も高速なパフォーマンスは、ハッシュテーブルの使用です。以下は、過去 1 日間の特定のユーザーに関連するセキュリティログ内のすべてのイベントを取得する例です。

$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 行の結果が表示されます。上記のプロセスは、2008 R2 の 4 GB のログでは通常 1 ～ 4 分かかります。

次に、特に管理する必要がある 2003 マシンの場合は、イベントビューアーの左側のペインで特定のログファイルを右クリックし、[ログファイルに名前を付けて保存] を選択します。

ローカルマシンでイベントビューアーを実行している場合は、get-winevent で解析できる .evt ファイルを保存できます。

あるいは、grep や findstr などの適切なコマンドラインユーティリティ、または notepad++ などの特定のプログラムで解析できるテキストファイルまたは CSV ファイル (CSV の方が簡単だと思います) を保存することもできます。

Answer

他の回答では、この背後にある理由について説明しています。最新のシステムでは、主にイベントビューアー GUI 内の読み込み時間をある程度許容できる程度に抑えることが主な目的です。現在のログをバックアップされる場所にコピーしてからクリアするのも良い方法です。

いずれにせよ生成される大きなログファイルを解析するには、次の 2 つの適切なオプションがあります。

1) 現在の GUI が管理できるよりも高速にログを解析するか、2) ログを個別のファイルに分割します。

2) については簡単に入手できるユーティリティがいくつかあると思うので、ここでは 1) に焦点を当てます。

まず、Powershell にはこの機能のための優れたコマンドレット「get-winevent」があります。私が見た中で最も高速なパフォーマンスは、ハッシュテーブルの使用です。以下は、過去 1 日間の特定のユーザーに関連するセキュリティログ内のすべてのイベントを取得する例です。

$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 行の結果が表示されます。上記のプロセスは、2008 R2 の 4 GB のログでは通常 1 ～ 4 分かかります。

次に、特に管理する必要がある 2003 マシンの場合は、イベントビューアーの左側のペインで特定のログファイルを右クリックし、[ログファイルに名前を付けて保存] を選択します。

ローカルマシンでイベントビューアーを実行している場合は、get-winevent で解析できる .evt ファイルを保存できます。

あるいは、grep や findstr などの適切なコマンドラインユーティリティ、または notepad++ などの特定のプログラムで解析できるテキストファイルまたは CSV ファイル (CSV の方が簡単だと思います) を保存することもできます。

Question 3

実際の例: コンプライアンス要件に従って 6 か月間保持できるようにセキュリティログのサイズを 12 GB に増やしたときに、この現象が発生しました。

3 か月目には、2008r2 サーバーと 2012r2 サーバーにログオンできなくなりました。ログオンは「ようこそ」画面で停止します。開かれる大きなファイルに対応するためにサーバーメモリを 20 GB に増やしてみましたが、サーバーは依然として応答しませんでした。最終的には、管理エンジンの推奨値である 1 GB に従い、いっぱいになったときに古いファイルを上書きするのではなくアーカイブするように調整することにしました。

必要に応じて 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

実際の例: コンプライアンス要件に従って 6 か月間保持できるようにセキュリティログのサイズを 12 GB に増やしたときに、この現象が発生しました。

3 か月目には、2008r2 サーバーと 2012r2 サーバーにログオンできなくなりました。ログオンは「ようこそ」画面で停止します。開かれる大きなファイルに対応するためにサーバーメモリを 20 GB に増やしてみましたが、サーバーは依然として応答しませんでした。最終的には、管理エンジンの推奨値である 1 GB に従い、いっぱいになったときに古いファイルを上書きするのではなくアーカイブするように調整することにしました。

必要に応じて 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 以降でも、最大サイズの設定が高すぎると、「従来の」イベントログ (アプリケーション、セキュリティ、システムなど) でメモリ不足が発生する可能性があり、依然として「メモリマップ」されている可能性があるようです。

マイクロソフトは言うこのトピックに関するドキュメントでは:

Windows Vista および Windows Server 2008 では、新しいイベントレポートインフラストラクチャが使用されているため、次の段落で説明する動作は発生しません。

テストではこれがのみWindows Vistaで導入された新しい「Windowsイベントログテクノロジ」と「Windowsイベントトレーシング」ログに適用されます。Get-WinEventそして取得イベントログコマンドレットは、「クラシック」ログが古いテクノロジでも実行される可能性があることを示唆しています。

Get-WinEventコマンドレットはイベントログからイベントを取得します。クラシックログを含む、例えばシステムおよびアプリケーションログこのコマンドレットは、Windows Vista で導入された Windows イベントログテクノロジおよびログファイル内のイベントWindows イベントトレーシング (ETW)デフォルトでは、Get-WinEvent はイベント情報を最新から古い順に返します。

EventLog 名詞を含む PowerShell コマンドレットは Windows でのみ動作します。 クラシックイベントログのようなアプリケーション、システム、またはセキュリティログを取得するにはWindows Vista 以降の Windows バージョンの 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)。[ファイルの概要] ページでは、セキュリティイベントログのほぼすべてがアクティブメモリ内にあることがわかります。

したがって、x64サーバーでは4GBを超える制限は適用されなくなりましたが、多くの持っている「クラシック」イベントログ (特にセキュリティイベントログ) のサイズが大きいと、新しいオペレーティングシステムでも空きメモリを使い果たしてしまう可能性があることがわかりました。これは、これらのイベントログが「メモリマップ」されたままになっているためです。ログの最大サイズを減らしてログをクリアすると、この問題は解決します。したがって、設定を高くしすぎる前に注意してください。

Answer