Windows 이벤트 로그에서 4GB를 초과하면 어떤 의미가 있습니까?

Question 1

4GB 로그를 로드해야 할 때 발생하는 끔찍한 성능과 터무니없는 대기 시간 외에는 그런 괴물 같은 것을 검색해야 한다면 그리 많지 않을 것입니다. 내 환경에서 본 것 중 가장 큰 것은 10GB였던 것 같은데, 로드 대기를 포기했지만 아무런 해를 끼치지 않는 것 같았다.

Server 2008의 4GB 주의 사항은 4GB에서 흔히 발생하는 32비트 제한 때문입니다. 64비트 시스템에서는 최대 16TB(또는 경우에 따라 64TB)까지 확장해도 괜찮지만, 누구도 그 한계를 테스트한 적이 있는지는 모르겠습니다.

물론 아직 수행하지 않았다면 매우 큰 로그 파일은 사용하기가 비현실적이라는 사실을 알게 될 것입니다. 지난번에 간단한 100GB(텍스트) 로그 파일을 로드하려고 시도했을 때 없이는 열 수도 없었습니다. 응용 프로그램을 열 때 충돌이 발생하고 100GB가 되기 훨씬 전에 해당 문제가 발생할 것으로 생각됩니다.

훨씬 더 나은 접근 방식은 파일 크기를 적당한 크기로 제한하고 스크립트를 사용하여 때때로 파일 크기를 지우는 것입니다. 내 환경에서는 보안 로그의 1GB 크기 제한과 함께 아래를 사용합니다. 우리 서버 중 일부(대부분)는 하루에 3GB가 넘는 보안 이벤트를 생성하며, 그 공간을 모두 살펴보기 전에 종료할 대용량 로그 파일에 낭비하고 싶지 않으므로 스크립트는 로그 내용을 다음 위치에 복사합니다. 다른 폴더에 저장한 다음 다시 기록할 이벤트 로그를 지웁니다. 그리고 복사한 폴더가 백업되어 있으므로 필요한 끔찍한 사건이 발생하면 언제든지 로그로 돌아갈 수 있습니다.

#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

4GB 로그를 로드해야 할 때 발생하는 끔찍한 성능과 터무니없는 대기 시간 외에는 그런 괴물 같은 것을 검색해야 한다면 그리 많지 않을 것입니다. 내 환경에서 본 것 중 가장 큰 것은 10GB였던 것 같은데, 로드 대기를 포기했지만 아무런 해를 끼치지 않는 것 같았다.

Server 2008의 4GB 주의 사항은 4GB에서 흔히 발생하는 32비트 제한 때문입니다. 64비트 시스템에서는 최대 16TB(또는 경우에 따라 64TB)까지 확장해도 괜찮지만, 누구도 그 한계를 테스트한 적이 있는지는 모르겠습니다.

물론 아직 수행하지 않았다면 매우 큰 로그 파일은 사용하기가 비현실적이라는 사실을 알게 될 것입니다. 지난번에 간단한 100GB(텍스트) 로그 파일을 로드하려고 시도했을 때 없이는 열 수도 없었습니다. 응용 프로그램을 열 때 충돌이 발생하고 100GB가 되기 훨씬 전에 해당 문제가 발생할 것으로 생각됩니다.

훨씬 더 나은 접근 방식은 파일 크기를 적당한 크기로 제한하고 스크립트를 사용하여 때때로 파일 크기를 지우는 것입니다. 내 환경에서는 보안 로그의 1GB 크기 제한과 함께 아래를 사용합니다. 우리 서버 중 일부(대부분)는 하루에 3GB가 넘는 보안 이벤트를 생성하며, 그 공간을 모두 살펴보기 전에 종료할 대용량 로그 파일에 낭비하고 싶지 않으므로 스크립트는 로그 내용을 다음 위치에 복사합니다. 다른 폴더에 저장한 다음 다시 기록할 이벤트 로그를 지웁니다. 그리고 복사한 폴더가 백업되어 있으므로 필요한 끔찍한 사건이 발생하면 언제든지 로그로 돌아갈 수 있습니다.

#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에는 'get-winevent'라는 이 기능을 위한 뛰어난 cmdlet이 있습니다. 내가 본 가장 빠른 성능은 해시 테이블을 사용하는 것과 관련이 있습니다. 다음은 마지막 날의 특정 사용자와 관련된 보안 로그의 모든 이벤트를 가져오는 예입니다.

$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 파일을 저장할 수 있습니다.

또는 grep 또는 findstr과 같은 적절한 명령줄 유틸리티나 notepad++와 같은 특정 프로그램으로 구문 분석할 수 있는 텍스트 또는 CSV 파일(CSV가 더 쉽다고 생각함)을 저장할 수 있습니다.

Answer

다른 대답은 이에 대한 이유를 다룹니다. 현대 시스템의 경우 대부분 이벤트 뷰어 GUI 내에서 로드 시간을 어느 정도 견딜 수 있게 유지합니다. 현재 로그를 백업할 위치에 복사한 후 삭제하는 것도 좋습니다.

결국 생성되는 대용량 로그 파일을 구문 분석하려면 두 가지 좋은 옵션이 발생합니다.

1) 현재 GUI가 관리할 수 있는 것보다 더 빠르게 로그를 구문 분석하거나 2) 로그를 별도의 파일로 분할합니다.

2)에 대해 쉽게 사용할 수 있는 유틸리티가 있다고 확신하므로 1)에 중점을 두겠습니다.

첫째, Powershell에는 'get-winevent'라는 이 기능을 위한 뛰어난 cmdlet이 있습니다. 내가 본 가장 빠른 성능은 해시 테이블을 사용하는 것과 관련이 있습니다. 다음은 마지막 날의 특정 사용자와 관련된 보안 로그의 모든 이벤트를 가져오는 예입니다.

$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 파일을 저장할 수 있습니다.

또는 grep 또는 findstr과 같은 적절한 명령줄 유틸리티나 notepad++와 같은 특정 프로그램으로 구문 분석할 수 있는 텍스트 또는 CSV 파일(CSV가 더 쉽다고 생각함)을 저장할 수 있습니다.

Question 3

실제 사례: 규정 준수 요구 사항에 따라 6개월 동안 보존할 수 있도록 보안 로그를 12GB 크기로 늘렸을 때 이런 일이 발생했습니다.

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

실제 사례: 규정 준수 요구 사항에 따라 6개월 동안 보존할 수 있도록 보안 로그를 12GB 크기로 늘렸을 때 이런 일이 발생했습니다.

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,삼) Windows Vista/Server 2008 이상에서도 최대 크기를 너무 높게 설정하면 '클래식' 이벤트 로그(응용 프로그램, 보안, 시스템 및 기타 몇 가지)로 인해 여전히 메모리 소모가 발생할 수 있습니다. 메모리 매핑'.

마이크로소프트는 그럴 수도 있지만말하다 주제에 대한 문서에서:

Windows Vista 및 Windows Server 2008은 새로운 이벤트 보고 인프라를 사용하며 다음 단락에 설명된 동작을 나타내지 않습니다.

테스트 결과에 따르면 그럴 수도 있습니다.오직Windows Vista에 도입된 새로운 'Windows 이벤트 로그 기술' 및 'Windows용 이벤트 추적' 로그에 적용됩니다.Get-Win이벤트그리고Get-EventLogcmdlet은 '클래식' 로그가 이전 기술에서 계속 실행될 수 있음을 제안합니다.

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