Windows 事件日誌中超過 4 GB 會產生什麼影響？

Question 1

除了當你必須加載 4 GB 日誌時糟糕的性能和荒謬的等待時間以及如果你必須搜索這樣一個可怕的東西時那將是地獄之外，沒有太多。我認為我在我的環境中見過的最大的一個是 10 GB，雖然我放棄了等待它加載，但它似乎沒有造成任何損害。

Server 2008 的 4GB 警告是由於 4GB 時經常遇到的 32 位元限制。在 64 位元系統上，您應該可以讓它成長到 16 TB（或 64，取決於），但我不知道是否有人已經接近測試該限制。

當然，如果您還沒有這樣做，您會發現非常大的日誌文件根本無法使用 - 上次我嘗試加載一個簡單的 100 GB（文本）日誌文件時，如果沒有它甚至無法打開它打開它的應用程序會崩潰，我懷疑您會在100 GB 之前遇到這個問題。

更好的方法是將檔案大小限制在合理的範圍內，並使用腳本不時地清除它。我在我的環境中使用以下內容，並結合我們的安全日誌的 1 GB 大小限制。我們的一些（嗯，大多數）伺服器每天產生超過 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 的 4GB 警告是由於 4GB 時經常遇到的 32 位元限制。在 64 位元系統上，您應該可以讓它成長到 16 TB（或 64，取決於），但我不知道是否有人已經接近測試該限制。

當然，如果您還沒有這樣做，您會發現非常大的日誌文件根本無法使用 - 上次我嘗試加載一個簡單的 100 GB（文本）日誌文件時，如果沒有它甚至無法打開它打開它的應用程序會崩潰，我懷疑您會在100 GB 之前遇到這個問題。

更好的方法是將檔案大小限制在合理的範圍內，並使用腳本不時地清除它。我在我的環境中使用以下內容，並結合我們的安全日誌的 1 GB 大小限制。我們的一些（嗯，大多數）伺服器每天產生超過 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 內的載入時間在某種程度上可以忍受。將當前日誌複製到備份的位置，然後清除它也很好。

為了解析最終生成的大型日誌文件，有兩個不錯的選擇：

1) 解析日誌的速度比目前 GUI 可以管理的速度更快，或 2) 將日誌拆分為單獨的檔案。

我確信有一些易於使用的實用程式可用於 2)，因此我將重點放在 1)。

首先，Powershell 有一個出色的 cmdlet 可以實現此功能，稱為「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]}}

這將顯示每個鎖定事件的單行結果。對於 2008 R2 上的 4GB 日誌，上述過程通常需要 1-4 分鐘。

其次，特別是對於您最終可能需要管理的任何 2003 計算機，您可以右鍵單擊事件檢視器左窗格中的特定日誌文件，然後選擇「日誌文件另存為」。

如果您在本機上執行事件檢視器，則可以儲存可由 get-winevent 解析的 .evt 檔案。

或者，您可以保存文字或 CSV 檔案（我發現 CSV 更容易），該檔案可以透過適當的命令列公用程式（例如 grep 或 findstr）或某些程式（例如 notepad++）進行解析。

Answer

另一個答案涵蓋了這背後的原因 - 對於現代系統，主要是讓事件檢視器 GUI 內的載入時間在某種程度上可以忍受。將當前日誌複製到備份的位置，然後清除它也很好。

為了解析最終生成的大型日誌文件，有兩個不錯的選擇：

1) 解析日誌的速度比目前 GUI 可以管理的速度更快，或 2) 將日誌拆分為單獨的檔案。

我確信有一些易於使用的實用程式可用於 2)，因此我將重點放在 1)。

首先，Powershell 有一個出色的 cmdlet 可以實現此功能，稱為「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]}}

這將顯示每個鎖定事件的單行結果。對於 2008 R2 上的 4GB 日誌，上述過程通常需要 1-4 分鐘。

其次，特別是對於您最終可能需要管理的任何 2003 計算機，您可以右鍵單擊事件檢視器左窗格中的特定日誌文件，然後選擇「日誌文件另存為」。

如果您在本機上執行事件檢視器，則可以儲存可由 get-winevent 解析的 .evt 檔案。

或者，您可以保存文字或 CSV 檔案（我發現 CSV 更容易），該檔案可以透過適當的命令列公用程式（例如 grep 或 findstr）或某些程式（例如 notepad++）進行解析。

Question 3

現實世界的範例：我們遇到了這種情況，安全日誌大小增加到 12GB，以便根據合規性要求保留 6 個月。

到第 3 個月，我們無法登入伺服器 2008r2 和 2012r2 伺服器。登入會卡在「歡迎」畫面。我們嘗試將伺服器記憶體增加到 20GB 以容納正在打開的大文件，但伺服器仍然很生氣。我們最終決定遵循管理引擎建議的 1GB 並調整它以在滿時存檔舊文件而不是覆蓋。

如果需要的話，我們有這個腳本來清理超過 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

現實世界的範例：我們遇到了這種情況，安全日誌大小增加到 12GB，以便根據合規性要求保留 6 個月。

到第 3 個月，我們無法登入伺服器 2008r2 和 2012r2 伺服器。登入會卡在「歡迎」畫面。我們嘗試將伺服器記憶體增加到 20GB 以容納正在打開的大文件，但伺服器仍然很生氣。我們最終決定遵循管理引擎建議的 1GB 並調整它以在滿時存檔舊文件而不是覆蓋。

如果需要的話，我們有這個腳本來清理超過 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 事件追蹤」日誌 - 有關以下文檔獲獎活動和取得事件日誌cmdlet 表明「經典」日誌可能仍然在舊技術上運行：

Get-WinEvent cmdlet 從事件日誌中取得事件，包括經典日誌，如那個系統和應用程式日誌。該 cmdlet 從由事件日誌產生的數據Windows Vista 中引入的 Windows 事件日誌技術和生成的日誌檔案中的事件Windows 事件追蹤 (ETW)。預設情況下，Get-WinEvent 會依照最新到最舊的順序傳回事件資訊。

包含 EventLog 名詞的 PowerShell cmdlet 僅適用於 Windows 經典事件日誌例如應用程式、系統或安全性。要取得使用的日誌Windows Vista 和更高版本的 Windows 中的 Windows 事件日誌技術，使用 Get-WinEvent。

即使在 Windows 11 上執行此 PowerShell cmdlet，也會顯示應用程式、安全性和系統事件日誌等仍在「經典」模式下執行，這可以解釋所報告的行為。

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）。在「文件摘要」頁面下，您可以看到幾乎所有安全事件日誌都位於活動記憶體中：

因此，雖然 >4GB 限制不再適用於 x64 伺服器，但似乎許多有發現“經典”事件日誌（尤其是安全事件日誌）的大尺寸即使在較新的作業系統上也會耗盡可用內存，因為這些事件日誌保持“內存映射”，並減少日誌的最大大小並清除日誌解決了這個問題。因此，在將其設置得太高之前要小心。

Answer