Windows 事件日志超过 4 GB 会造成什么后果？

Question 1

除了加载 4 GB 日志时糟糕的性能和荒谬的等待时间，以及搜索如此庞大的内容时会遇到的麻烦之外，没有什么好处。我认为我在我的环境中见过的最大文件是 10 GB，虽然我放弃了等待它加载，但似乎没有什么坏处。

Server 2008 的 4GB 警告是由于 32 位限制，通常 4GB 时会遇到此限制。在 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 警告是由于 32 位限制，通常 4GB 时会遇到此限制。在 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 现在是事件的集合。根据匹配的数量，您可以将其通过管道传输到 format-list，以轻松读取少量事件。对于中等数量的事件，请执行相同操作，但将输出重定向到文件：

$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 现在是事件的集合。根据匹配的数量，您可以将其通过管道传输到 format-list，以轻松读取少量事件。对于中等数量的事件，请执行相同操作，但将输出重定向到文件：

$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 事件跟踪”日志 - 以下文档获取 WinEvent和获取事件日志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