Windows 2008/Vistaまでのオペレーティングシステムの推奨イベントログ設定の最大値をカバーするこのMicrosoft KBを見つけました 、これは最大4GBを推奨し、イベントログが4より大きいという他のあいまいな参照をいくつか見ましたGBは少なくとも2008 R2では推奨されていませんが、イベントログがこのサイズを超えると実際にはどうなるのでしょうか。
テストサーバー(2012 R2)でこれを超えており、メモリ使用量が高いなどのことに気づいていません。2008R2より前のOSは問題ではありませんが、多くのマシンからイベントを収集するため、大きなログが必要です。 Windowsイベント転送とすべてのイベントを1か所に置きたい。
4 GBのログをロードしなければならないときのひどいパフォーマンスとばかげた待機時間を除いて、このような巨大なものを検索する必要がある場合は、それほどではありません。私の環境で見た中で最大のものは10 GBだったと思います。ロードするのを待つことをあきらめましたが、何の害もないようでした。
Server 2008に対する4GBの注意は、4 GBで頻繁に発生する32ビットの制限によるものです。 64ビットシステムでは、最大16 TB(または64に応じて)まで)に拡大しても問題ありませんが、その制限のテストに近い場所に誰かがいることはわかりません。
もちろん、まだ行っていない場合は、非常に大きなログファイルを使用するのは実際的ではないことに気づくでしょう。前回、単純な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
他の答えは、この背後にある理由をカバーしています-最新のシステムでは、ほとんどの場合、イベントビューアGUI内のロード時間をある程度耐えられるようにしています。現在のログをバックアップされる場所にコピーしてから消去するのもよい方法です。
いずれにせよ生成されてしまう大きなログファイルを解析する場合、2つの適切なオプションが発生します。
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はイベントのコレクションになりました。一致の数に応じて、それをformat-listにパイプ処理して、少数のイベントを簡単に読み取ることができます。中程度の数の場合も同じことを行いますが、出力をファイルにリダイレクトします。
$userevt | format-list > <outputfile>.txt
多数の場合は、フィルタリングを開始します(たとえば、上記で取得したユーザーのロックアウトイベントに対して発信者のコンピューターが必要だとします)。
$userevt | %{if ($_.message -match "Caller Computer .*") {$matches[0]}}
これにより、ロックアウトイベントごとに1行の結果が表示されます。上記のプロセスは、2008 R2で4GBのログを記録するのに1〜4分かかります。
次に、特に管理しなければならない可能性のある2003マシンの場合は、イベントビューアの左側のペインで特定のログファイルを右クリックし、[名前を付けてログファイルを保存]を選択します。
ローカルマシンでイベントビューアを実行している場合は、get-wineventで解析できる.evtファイルを保存できます。
または、grepやfindstrなどの適切なコマンドラインユーティリティ、またはnotepad ++などの特定のプログラムで解析できるテキストファイルまたはCSVファイル(CSVの方が簡単です)を保存できます。
実際の例:これは、コンプライアンス要件ごとに6か月の保持を可能にするためにセキュリティログを12GBのサイズに増やしたときに発生しました。
3か月目までに、サーバー2008r2および2012r2サーバーにログオンできませんでした。ログオンが「ようこそ」画面で動かなくなる。開かれる大きなファイルに対応するために、サーバーのメモリを20GBに増やしましたが、サーバーはまだ怒っていました。最終的には、1 GBの管理エンジンの推奨に従い、完全な場合と上書きした場合に古いファイルをアーカイブするように調整しました。
このスクリプトでは、必要に応じて180日以上経過した古いファイルをクリーンアップしますが、ファイルをそのままにしておくことができます。
get-childitem -Path "C:\Windows\System32\winevt\Logs" |
where-object {$_.LastWriteTime -lt (get-date).AddDays(-180)} |
remove-item –whatif