Windows Vista

Windows Vista의 새로운 이벤트 관리 도구

Val Menn

 

한 눈에 보기:

  • 새로운 이벤트 인프라
  • 이벤트 유형
  • 구조적 이벤트 속성
  • XPath 식 사용

많은 사람들이 이벤트 기록 및 추적을 지루하게 여깁니다. 추적 및 이벤트는 대개 디버깅과 자체 모니터링 기능 같은 보조적인 작업의 부산물에 불과하고, 이벤트 기록과 추적 기능의 중요성이 간과되는 경향이 있다고 불평하는 경우가 있습니다.

Microsoft® Windows Vista™는 엔터프라이즈 관리 측면의 혁신적인 변화를 통해 이러한 인식을 바꿀 것입니다. Microsoft는 몇 가지 핵심적인 구성 요소와 관련 사용자 인터페이스를 정밀하게 분석했습니다. 이벤트 로그 서비스는 엔터프라이즈를 염두에 두고 완전히 새롭게 재구성되었으며 추적 기능은 이전보다 속도와 안전성이 크게 향상되었습니다.

중요한 시스템에서 문제를 발견하고 해결할 수 있는 더 나은 도구가 있다고 생각해보십시오. 또는 기술 지원 엔지니어가 사용자의 시스템에서 경고 이벤트와 추적 내용을 쉽게 수집할 수 있도록 하는 기능이 있거나 사용자가 즉석에서 보낸 추적 내용을 개발자가 사용하여 이미 배포된 시스템의 버그를 진단하고 수정할 수 있다면 어떨까요? 정보를 수집하고 문제를 신속하게 해결할 수 있는 보다 쉽고 효율적인 방법이 있다면 지루하다는 생각은 바로 사라질 것입니다.

이벤트란?

컴퓨터 응용 프로그램은 하나 또는 그 이상의 기능을 수행하는 "블랙 박스"와 같습니다. 즉, 상자에 들어가는 내용은 많지만 상자 내부를 들여다볼 수 없기 때문에 내부 작동 방식을 이해하기는 어렵습니다. 그러나 응용 프로그램은 다른 프로그램 및 사용자와 외부적으로 통신하기 때문에 사용자는 이러한 통신 "이벤트"를 통해 응용 프로그램을 조금이나마 이해할 수 있습니다.

소프트웨어의 경우 이벤트는 일반적으로 소프트웨어 시스템 내에서 외부 사용자 또는 외부의 다른 프로그램과 통신할 때 발생하는 항목으로 정의됩니다. 이러한 항목은 주로 상태 또는 구성 변경 사항에 해당하는 것이며 소프트웨어 시스템의 현재 상태나 구성 및 변경 이유를 나타낼 수 있습니다.

좀 더 간단하게 말해서 이벤트라는 용어는 이러한 항목이 노출되는 방법을 나타내기도 합니다. 이러한 노출된 이벤트에 대한 예는 매우 다양합니다.

  • IPC(프로세스 간 통신)에 사용되는 Win32® 개체
  • 임시적인(비영구적) 알림에 사용되는 WMI 이벤트
  • 추적 파일에 저장되는 ETW(Event Tracing for Windows) 추적 이벤트
  • 이벤트 로그 라이브 로그에 저장되고 이벤트 로그 파일에 보관될 수도 있는 이벤트 로그 이벤트
  • 사용자 지정 인프라를 사용하여 파일에 저장되는 이벤트

이 기사에서는 위 목록 중 마지막 세 가지 예에 대해 살펴보겠습니다.

이벤트 사용 방법

추적 또는 기록된 이벤트는 프로그램 또는 운영 체제에서 발생한 항목에 대한 기록입니다. 이러한 추적 및 이벤트 로그는 단지 개발자만을 위한 것이 아닙니다. IT 및 지원 담당자는 이벤트 및 추적을 통해 현재 실행 중인 응용 프로그램의 상태 및 내부 작동 방식에 대해 간단하게나마 이해할 수 있습니다.

이러한 로그를 사용하면 전반적인 시스템 상태를 모니터링할 수 있습니다. 이벤트 로그를 사용하여 문제를 나타내는 이벤트를 검색할 수 있습니다. 예를 들어 CertificateServicesClient 소스의 응용 프로그램 로그에서 "로컬 시스템에 대한 자동 인증 등록이 실패했습니다(0x80070576). 클라이언트와 서버 사이의 시간 및/또는 날짜가 다릅니다."와 같은 메시지가 표시된 오류 이벤트 6을 확인할 수도 있습니다. 또한 구성 요소를 잘못된 상태에서 다시 정상 작동 상태로 전환하는 것도 검색할 수 있습니다. 예를 들어 시간 및 날짜를 동일하게 설정한 다음에는 동일한 CertificateServiceClient 소스의 응용 프로그램 로그에 "<사용자 이름>에 대한 인증 등록을 성공적으로 수행하여 인증 기관 <인증 기관 이름>으로부터 AutoenrolledWindowsSystemComponentVerification 인증서를 받았습니다."와 같은 정보 제공용 이벤트 19가 게시될 수 있습니다. 이러한 정보는 구성과 관련한 충돌 및 기타 문제를 확인하고 해결하는 데 매우 중요합니다.

또한 이러한 정보는 문제를 진단하는 데도 유용합니다. 문제 원인이 되는 프로그램 및 시스템 작업을 확인하고 근본 원인을 확인하는 데 도움이 될 수 있는 상세 정보를 찾을 수 있습니다. 또한 이 정보를 활용하여 성능 문제를 평가하고 해결할 수 있습니다.

이벤트 로그는 보다 안전한 환경을 유지하는 데 사용할 수 있는 중요한 정보를 제공합니다. 이러한 정보는 침입 시도를 검색하고, 시스템 기록을 감사하고, 부인 방지(non-repudiation)를 보장하고, 잘못 구성된 리소스를 찾는 데 활용할 수 있습니다.

Windows Vista의 이벤트

이전 버전의 Windows®에서는 이벤트 기록 및 추적과 관련하여 여러 가지 단점이 있었습니다. 이러한 단점으로는 이벤트 로그의 제한적인 확장성(모든 로그의 전체 크기를 사용 가능한 메모리 양으로 제한), 이벤트 게시 성능(예: 사용 중인 도메인 컨트롤러에 게시할 수 있는 이벤트 수 제한) 및 추적 이벤트의 제한적인 보안성 등이 있습니다.

Windows Vista에서는 이벤트 기록 및 추적을 위해 Windows Eventing 6.0이라는 새로운 인프라를 통해 이러한 많은 문제를 해결합니다. 이 인프라는 Windows 2000부터 사용되고 있는 ETW의 확장 기능으로, 이벤트 로그 서비스 및 이벤트 뷰어의 기능을 대신합니다. 새로운 Windows Eventing은 특별히 이후 검사를 위해 로그 파일에 보관되는 이벤트를 처리하도록 설계되었습니다. 이 인프라는 IPC 및 알림 메커니즘과 같은 임시 이벤트에는 사용되지 않습니다.

보안 및 확장 솔루션을 제공함으로써 사용자 지정 이벤트 및 추적 구현의 중요성은 낮아졌습니다. 이러한 향상된 기능은 기존 이벤트 로그 및 ETW API와의 완벽한 호환성을 보장하면서 제공되기 때문에 기존의 모든 응용 프로그램을 변경하지 않고도 사용할 수 있습니다.

새로운 이벤트 표시 방법

기존 이벤트 뷰어는 이미 IT 커뮤니티에서 가장 널리 알려진 Windows 프로그램 중 하나입니다. 새로운 이벤트 뷰어는 완전히 새롭게 작성되었으며, MMC(Microsoft Management Console) 3.0 이래로 모양이 바뀌기는 했지만 여전히 익숙한 형태로 제공되기 때문에 사용자가 변경된 이벤트 뷰어를 매우 쉽게 활용할 수 있습니다.

트리 창과 이벤트 목록도 그대로 제공됩니다. Windows 로그 노드 아래의 응용 프로그램, 시스템 및 보안 로그도 계속 사용할 수 있습니다. 그러나 루트에 몇 가지 새로운 노드가 추가되었으며 뒤에 간단히 설명할 새로운 Forwarded Events(전달된 이벤트) 로그가 Windows 로그 노드에 추가되었습니다.

가장 돋보이는 새로운 기능은 이벤트 목록 아래의 미리 보기 창입니다. 여기에는 현재 선택한 이벤트의 속성이 표시됩니다. 즉, 이벤트 속성을 보기 위해 더 이상 이벤트를 두 번 클릭할 필요가 없으며 목록과 이벤트 속성 대화 상자를 보기 위해 여러 개의 창을 확인해야 할 필요가 없게 된 것입니다. 물론 이벤트를 두 번 클릭해서 속성 대화 상자를 표시하는 기능도 계속 사용할 수 있습니다. 그러나 새로운 대화 상자는 모달 방식이 아니기 때문에 동시에 여러 개의 이벤트 속성 대화 상자를 표시할 수 있습니다.

이 새로운 보기에서는 간단한 마우스 클릭만으로 원하는 모든 이벤트를 표시할 수 있습니다. 하나 이상의 로그 파일에 대해 이벤트를 수집하고 특정 ID, 심각도 수준 또는 기간에 따라 특정 내용을 확인할 수 있습니다.

Custom Views(사용자 지정 보기) 노드 아래에는 Administrative Events(관리 이벤트)가 표시됩니다(그림 1 참조). 여기에는 관리자에게 도움이 되는 여러 가지 로그 파일에서 가져온 모든 오류 및 경고 목록이 표시됩니다.

그림 1 Administrative Events(관리 이벤트)

그림 1** Administrative Events(관리 이벤트) **(더 크게 보려면 이미지를 클릭하십시오.)

Windows Vista 개발 팀에서는 관리자가 처리해야 하는 로그 및 이벤트를 어떻게 정확하게 결정할 수 있었을까요? 저희 개발 팀에서는 5가지의 개별적인 이벤트 유형과 각 유형과 관련된 사용자를 분류했습니다. 이에 대한 설명은 그림 2를 참조하십시오. 이러한 분류는 여러 그룹에 해당하는 모든 이벤트 로그 및 추적 이벤트를 매우 일반적이지만 효율적으로 구분해 줍니다.

Figure 2 이벤트 유형 및 사용자

이벤트 유형 설명 사용자
관리 관리 유형은 대부분 시스템 관리자를 위한 것입니다. 이 이벤트는 매우 높은 수준의 이벤트이며 문제 확인 및 해결에 도움이 되는 다양한 정보를 제공합니다. 관리 이벤트는 문제가 발생한 경우 해당 문제를 확인하거나 전체적으로 응용 프로그램, 구성 요소 또는 시스템이 정상적이지 않은 상태에서 복구된 경우 관련 내용을 나타내야 합니다. 대부분의 관리 이벤트는 오류 또는 경고이며 일반적으로 조치를 취할 수 있는 이벤트입니다. 관리자, 지원 담당자, 모니터링 및 분석 프로그램
작동 관리 이벤트와 마찬가지로 작동 이벤트 역시 문제를 진단하는 데 사용됩니다. 작동 이벤트는 단순한 오류 및 경고 이상의 내용으로 구성되어 있습니다. 또한 응용 프로그램 또는 OS 구성 요소의 정상적인 작동에 대해 알려 줍니다. 작동 이벤트는 비교적 적은 용량으로 저장되므로 시스템 성능에 영향을 주지 않고 사용할 수 있습니다. 관리 이벤트와 마찬가지로 작동 이벤트는 지원 담당자, 모니터링 유틸리티 및 일부 숙련된 관리자가 사용합니다. 고급 관리자, 지원 담당자, 모니터링 및 분석 프로그램
감사 감사 이벤트는 사용자가 수행한 모든 리소스 액세스 또는 작업에 대한 기록을 제공합니다. 이 이벤트가 프로그램의 성공 또는 실패 여부를 나타내지는 않지만 수행한 작업이 성공했는지 또는 실패했는지 여부는 확인할 수 있습니다. 세분화된 수준에 따라 감사 이벤트를 전혀 사용하지 않을 수도 있고 선택적으로 사용할 수도 있습니다. OS 수준에 대한 보안 감사도 지원되며 해당 이벤트는 이벤트 로그의 보안 로그에서 확인할 수 있습니다. 고급 관리자, 보안 감사자 및 법적 분석 전문가
분석 분석 이벤트는 작동 이벤트와 크게 다르지 않으며 응용 프로그램 및 구성 요소의 정상적인 작동 중에 기록됩니다. 그러나 분석 이벤트의 용량 및 세부 항목은 작동 이벤트보다 훨씬 크고 많으므로 시스템 성능에 부정적인 영향을 미칠 수 있습니다. 따라서 분석 이벤트는 일반적으로 사용하지 않도록 설정됩니다. 분석 이벤트를 올바르게 활용하려면 진단 세션 전에 사용하도록 설정한 다음 추적 내용을 검사하기 전에 사용하지 않도록 설정합니다. 지원 담당자, 모니터링 및 분석 프로그램
디버그 디버그 이벤트는 용량이 큰 이벤트이므로 일반적으로 사용하지 않도록 설정됩니다. 디버그 이벤트는 주로 개발자 및 IT 전문가가 검토 작업을 수행할 때 사용됩니다. 개발자

Windows Eventing에서 모든 로그는 각각의 유형이 지정되어 있습니다. 특정 로그에 해당하는 모든 이벤트는 해당 로그의 유형을 공유합니다. 그림 1의 보기는 이러한 유형 정보를 사용하여 정의되었습니다. 이 보기에는 관리 유형의 로그에 포함되는 모든 오류 및 경고 이벤트가 표시되어 있습니다.

Windows Eventing 아키텍처

Windows Eventing 인프라는 이벤트 개체를 프로그램별로 게시하고 로그 파일로 전달할 수 있게 해 주는 소프트웨어 구성 요소로 이루어져 있습니다. ETW는 해당 이벤트 게시자로부터 해당 대상으로 모든 유형의 이벤트를 전송하는 데 사용되는 전송 방식을 제공합니다. ETW는 Windows Vista 개발 과정에서 매우 중요한 것으로 인식되었으며, 그 결과 현재는 보다 나은 성능과 향상된 보안성을 제공합니다. ETW를 통한 이벤트 게시는 비동기적으로 수행되기 때문에 게시 프로그램의 성능에 영향을 주지 않습니다. 시스템에서 새로운 이벤트를 수신하면 현재 사용자 컨텍스트 및 게시 프로세스에 대한 정보가 수집되고 이벤트에 추가됩니다.

이벤트가 게시된 다음에는 여러 가지 유형이 다양한 방식으로 처리됩니다. 분석 및 디버그 이벤트는 일반적으로 볼륨이 크기 때문에 시스템 성능에 대한 영향을 줄이기 위해서는 최소한의 처리 과정을 통해 파일로 저장해야 합니다. 따라서 이러한 이벤트는 추적 파일에 즉시 저장됩니다.

관리 및 작동 이벤트는 아주 가끔 발생하기 때문에 추가 처리를 허용하더라도 시스템에 미치는 영향이 적습니다. 이러한 이벤트는 이벤트 로그 서비스에 전달되며, 이 서비스는 이벤트를 라이브 이벤트 로그에 저장하고 선택적으로 실시간 구독자에게 전달할 수도 있습니다. 구독자는 쿼리 언어(아래 내용 참조)를 사용하여 원하는 이벤트를 선택하여 구독할 수 있습니다.

특히 IT 커뮤니티에 특별한 관심을 갖는 두 가지 유형의 구독자가 있습니다. 그 중 하나는 더욱 향상된 Windows Vista 작업 스케줄러이며, 다른 하나는 원격 이벤트 수집기로 이벤트를 보내는 데 사용할 수 있는 이벤트 전달기입니다.

구조화된 이벤트 개요

이벤트 로그에 대한 일반적인 불만 사항 중 하나는 쓸모없는 정보가 너무 많이 포함된다는 점입니다. 즉, 거의 중요하지 않거나 전혀 필요 없는 이벤트까지 모두 수집되어 중요한 이벤트를 찾기가 어렵다는 것입니다. 그러나 몇몇 사용자에게는 중요하지 않게 보이는 이벤트라도 다른 사용자에게는 매우 중요한 것일 수 있습니다.

Windows Vista에서는 사용자가 자신에게 필요하지 않은 이벤트를 필터링하여 필요한 이벤트에만 집중할 수 있습니다. 이 기능은 이벤트 로그 서비스에서 지원되는 교차 로그 쿼리 언어를 기반으로 합니다. 이 기능을 사용하기 위해서는 모든 이벤트가 잘 정의된 구조를 따라야 합니다.

이전 버전의 이벤트 로그에서도 이벤트에 대해 약간의 구조화된 방식을 제공했지만 잘 정의된 구조가 아니었으며 Win32 API에서만 확인할 수 있었습니다. Windows Vista에서는 이벤트가 효과적으로 정의된 구조를 갖습니다. 실제로 이벤트는 게시된 스키마와 XML을 통해 외부에 표시됩니다. 이를 통해 필요한 이벤트는 수집하고 그렇지 않은 이벤트는 필터링하는 쿼리를 만들 수 있습니다. XML이 사용되기 때문에 이벤트 쿼리 언어 기반으로 XPath가 선택되었습니다. 당연한 결과로, 구조화된 이벤트를 사용함에 따라 새로운 작업 스케줄러 통합에서 볼 수 있는 것처럼 자동화 가능성이 열리게 되었습니다.

현재의 이벤트 미리 보기 창에는 Details(자세히) 탭이 있습니다. Event Properties(이벤트 속성) 대화 상자에도 이 탭이 있습니다. Event Properties(이벤트 속성) 대화 상자에서 Details(자세히) 탭을 선택하면 이벤트가 XML로 표시됩니다. 그림 3의 예제는 작업 스케줄러에 표시된 작동 이벤트를 보여 줍니다. 여기에는 두 가지 부분이 포함됩니다. System 부분은 이 이벤트의 모든 이벤트 인스턴스에 공통적인 일반 이벤트 정보와 인스턴스가 게시될 때 수집된 몇 가지 시스템 매개 변수로 구성됩니다. 확장 가능한 EventData 섹션에는 응용 프로그램의 구조화된 정보가 들어 있습니다.

그림 3 XML로 표시된 이벤트

그림 3** XML로 표시된 이벤트 **(더 크게 보려면 이미지를 클릭하십시오.)

각각의 이벤트 로그 파일은 이러한 일련의 구조화된 이벤트 요소로 간주됩니다. 이 요소는 이벤트 로그 및 이벤트 보관 파일을 읽을 수 있는 형태로 논리적으로 표시합니다. 내부적으로 이벤트는 압축 성능, 안정성 및 검색 성능을 균형적으로 제공하도록 설계된 바이너리 형식으로 저장됩니다.

이벤트 특성

XML 데이터의 System 섹션은 이벤트가 발생한 시간, 프로세스 ID, 스레드 ID, 컴퓨터 이름 및 사용자의 SID(보안 식별자)를 제공합니다. 이전 버전의 Windows에서는 이벤트에 EventID 및 Category의 두 가지 특성만 있었습니다. XML은 또한 EventID, Level, Task, Opcode 및 Keywords 속성을 비롯한 기타 상세 정보도 제공합니다. 이러한 속성에 대해 자세히 살펴보도록 하겠습니다.

EventID 및 Version: 이벤트는 EventID(2바이트 숫자) 및 Version(1바이트 숫자)의 조합으로 고유하게 식별됩니다. EventID와 Version을 공유하는 동일 이벤트 공급자의 모든 이벤트는 동일한 구조를 공유합니다.

Level: 이 값은 이벤트의 심각도 또는 자세한 표시 수준을 나타냅니다. 1(중요), 2(오류), 3(경고), 4(정보) 및 5(자세한 정보)로 미리 정의된 값이 일반적으로 사용되지만 공급자가 최대 255까지 고유한 값을 정의할 수 있습니다. 숫자가 높을수록 보다 자세한 정보가 제공되는 이벤트를 나타냅니다.

Task: Task 속성은 일반적으로 이벤트 공급자의 기능에 대한 일반적인 영역을 나타냅니다(예: 인쇄, 네트워킹 또는 UI). 이 속성은 프로그램의 하위 구성 요소를 나타낼 수도 있습니다. 보안 감사 이벤트에서는 이러한 속성이 광범위하게 사용됩니다. 각 이벤트 공급자는 이 2바이트 숫자에 대한 값을 고유하게 정의할 수 있습니다. Task 특성은 문자 그대로 "작업"을 나타내며, 이전 버전의 Windows에 사용된 Category 특성의 상위 집합입니다. 이러한 이유로 이벤트 뷰어에는 이 값이 Task Category(작업 범주) 열에 표시됩니다.

Opcode: 이 속성은 일반적으로 특정 작업이나 소프트웨어에서 수행되는 작업의 일부를 나타내기 위해 사용되는 1바이트 값입니다. 이 값은 주로 작업 기반 프로세스(예: 웹 서비스에서 특정한 요청으로 수신되는 작업)를 추적하는 데 사용됩니다. 미리 정의된 일부 값 중에서는 1(시작)과 2(중지)가 가장 일반적으로 사용됩니다.

Keywords: 이 속성은 프로그램에서 비슷한 이벤트를 쉽게 그룹화하기 위해 설정할 수 있는 56개의 플래그의 마스크입니다. 각 이벤트는 두 개 이상의 플래그 집합을 가질 수 있으므로 이벤트는 여러 그룹에 속할 수 있습니다.

게시자 및 이벤트 이해

이벤트 로그 및 추적 파일에 포함될 수 있는 모든 정보 유형을 미리 알고 있지 않은 경우에는 사전에 조치를 취하기가 어렵습니다. 따라서 새로운 이벤트 인프라를 만드는 데 있어 중요한 목표 중 하나는 이벤트 집합에 대한 정보 및 정보의 대상을 비롯하여 각 이벤트 게시자에 대한 설명서를 제공하는 것이었습니다.

이러한 목표를 달성하기 위해 각 게시자는 이러한 이벤트에 대한 구조와 함께 게시할 모든 이벤트를 열거해야 합니다. 이 정보는 게시자의 바이너리(프로그램 또는 DLL)에 컴파일, 인코딩 및 저장됩니다.

이제는 이벤트 기록 시스템에 등록된 모든 게시자를 검색하고 모든 게시자의 구성을 확인할 수 있습니다. 게시자가 기록할 수 있는 모든 가능한 이벤트에 대한 전체 목록, 이러한 이벤트의 구조 및 관련 메시지를 이벤트가 발생하기 전에 미리 확인할 수 있습니다. 그림 4에서는 명령줄 유틸리티인 wevtutil을 사용하여 공급자 구성을 표시하는 방법을 보여 줍니다. 아래 표시된 명령은 Microsoft-Windows-Video For Windows라는 이름의 이벤트 게시자에 대해 시스템에 알려진 모든 정보를 보여 줍니다.

그림 4 wevtutil을 사용하여 공급자 구성 표시

그림 4** wevtutil을 사용하여 공급자 구성 표시 **(더 크게 보려면 이미지를 클릭하십시오.)

쿼리 언어의 작동 방식

앞에서도 언급한 것처럼 새로운 인프라에 사용되는 이벤트의 구조화된 특성으로 인해 표준 XPath 식을 기반으로 하는 쿼리 언어에 대해서도 지원할 수 있게 되었습니다. 일반적으로 시작 위치, 즉 XML 요소가 정해져 있는 경우 XPath 식은 해당 요소 내의 모든 위치를 참조할 수 있습니다. XPath 언어에 대한 자세한 설명은 w3.org/TR/xpath에서 제공하는 공식 참조 자료를 참조하십시오. 보다 일반적으로 의미로 XPath 식은 시작 요소 내에 포함된 다른 요소나 특성을 참조합니다. 이벤트 로그는 본질적으로 순차적인 Event 요소의 모음이기 때문에 각 로그는 다음과 같은 구조를 갖습니다.

<root>
<Event>... </Event>
...
<Event>... </Event>
</root>

root 요소는 이름이 없으며, 단순히 모든 XPath 식에 대한 컨텍스트로 사용됩니다. 정방향 축만 정의됩니다. 즉, XPath 식에서 Event 요소, 해당 하위 요소 및 해당 특성을 참조할 수 있습니다. XPath 식이 기존의 요소를 선택하면 true가 반환됩니다. 다음은 그림 3에 표시된 이벤트를 기반으로 하는 매우 간단한 XPath 식입니다.

*/System[Provider/@Name='Microsoft-Windows-TaskScheduler' and Level <= 2]

이 식은 Microsoft-Windows-TaskScheduler 이벤트 공급자에서 Level이 2 이하(모든 오류 및 중요 이벤트 포함)인 모든 Event 요소를 선택합니다. 여기서 별표(*)는 "모두"를 의미합니다.

XPath 식을 사용하여 단일 로그에서 이벤트를 선택할 수도 있지만 강력하면서도 단순한 XML 기반 쿼리 언어를 사용하면 어떠한 로그나 외부 이벤트 보관 파일에서도 이벤트를 선택하거나 제외할 수 있습니다. 실제로 쿼리 언어는 Windows Vista 이벤트 기록에서 매우 광범위하게 활용됩니다. 예를 들어 Custom Views(사용자 지정 보기)도 쿼리를 기반으로 합니다. 또한 쿼리 언어를 사용하여 특정 로그로부터 이벤트 뷰어의 이벤트 목록 창에 표시할 이벤트를 지정할 수 있습니다. 쿼리 언어를 사용하면 이벤트를 구독하고, 선택한 이벤트를 보관하고, 새로운 작업 스케줄러에서 작업을 트리거할 수 있습니다.

이벤트 로그 명령줄 유틸리티에는 실제 쿼리 XML 또는 XPath 식을 제공해야 합니다. 이러한 쿼리 정의 기능은 모든 사용자를 위한 것이 아니므로 이벤트 뷰어는 일반적인 쿼리를 작성할 수 있는 간단한 UI를 제공합니다. 예를 들어 그림 5에 표시된 Create Custom View(사용자 지정 보기 만들기) 대화 상자를 사용하면 모든 작업 스케줄러 이벤트에 대한 보기를 만들 수 있습니다. 각 쿼리 생성 대화 상자에는 쿼리 텍스트가 표시되는 XML이라는 이름의 탭이 있으며, 이 탭에서 쿼리를 직접 편집할 수 있습니다.

그림 5 일반 쿼리를 만들기 위한 UI

그림 5** 일반 쿼리를 만들기 위한 UI **(더 크게 보려면 이미지를 클릭하십시오.)

일반적인 쿼리 사용

다양한 용도로 쿼리를 사용할 수 있습니다. 그러나 기본적으로 다른 것보다 더 많이 활용되는 용도가 있습니다. 예를 들어 쿼리는 이벤트 뷰어 또는 이벤트 로그 명령줄 유틸리티에서도 선택 이벤트를 표시하는 데 사용되는 경우가 있습니다.

Windows 작업 스케줄러에서는 쿼리에 작업을 첨부할 수 있습니다. 예를 들어 쿼리와 일치하는 이벤트가 게시될 때마다 작업 스케줄러에서 지정된 작업을 시작하도록 설정할 수 있습니다. 이 기능을 위해서는 구독을 사용하고 새로 도착하는 이벤트에 대한 응답 작업을 수행해야 합니다. 관리 및 작동 이벤트만 구독할 수 있습니다. 디버그 및 분석 이벤트는 추적 파일에 직접 기록되기 때문에 이 이벤트가 발생하기 전에는 시스템에서 이를 검사할 수 없습니다.

쿼리는 선택한 이벤트를 보관하는 데도 사용할 수 있습니다. 모든 유형의 라이브 로그, 하위 수준 이벤트 보관 파일(EVT 파일), 외부 추적 파일 또는 Windows Vista 이벤트 보관 파일에서 이벤트를 선택할 수 있습니다. 보관 파일은 이벤트 뷰어에서 열거나, 보조 저장소에 백업하거나, 문제 진단을 돕기 위해 지원 담당자에게 보낼 수 있습니다. 보관 작업 중에 선택한 언어로 모든 이벤트 설명 및 이벤트 관련 기타 문자열을 보관 파일에 첨부할 수 있습니다. 이러한 작업을 완료하면 모든 시스템에서 사용자가 원하는 언어로 완전한 설명과 함께 이벤트 정보를 확인할 수 있습니다.

마지막으로 쿼리는 이벤트 수집 전용 시스템에 이벤트를 전달하는 용도로 사용될 수 있습니다. 이 기능을 위해서는 관리자가 원격 컴퓨터에 대한 이벤트 구독을 만들 수 있게 해 주는 새로운 이벤트 수집기 서비스가 사용됩니다. 이러한 구독은 수집기 시스템에 영구적으로 저장되며 구성 가능한 일정을 사용하여 다시 시도할 수 있습니다. 이벤트 수집기는 산업 표준인 WS-Management 프로토콜을 사용하여 원격 컴퓨터에 구독을 만들고 WS-Eventing 프로토콜을 사용하여 이벤트를 전송합니다. 두 프로토콜 모두 보안 및 방화벽 기능을 지원합니다. 이벤트 수집기에서 수신한 이벤트는 로컬 이벤트 로그에 저장됩니다.

결론

Windows Eventing은 많은 부분이 대대적으로 변경되었으며 이 문서에서는 이러한 변경된 기능 중 일부만을 살펴봤습니다. 이벤트 전달 기능만으로도 충분히 한 회분의 기사로 다룰 수 있습니다.

이벤트 시스템은 성능, 확장성, 안정성 및 보안 측면에서 크게 향상되었습니다. 그러나 기본적인 목적은 Windows의 관리 성능을 향상시키기 위한 것이라는 점을 잊지 말아야 합니다. 이벤트 뷰어 보기와 함께 쿼리 언어를 사용하면 문제를 보다 쉽게 발견할 수 있습니다. 완벽하게 통합된 작업 스케줄러는 간단한 모니터링, 자동 문제 해결 및 문제에 대한 신속한 알림을 가능하게 해 줍니다. 또한 이벤트 전달 기능은 이벤트 보관을 지원하고 전문가의 도움 없이도 서버 및 데스크톱을 모니터링할 수 있게 해 줍니다.

이러한 모든 기능은 이전 버전과의 호환성에 영향을 주지 않도록 구현되기 때문에 기존의 솔루션도 계속해서 사용할 수 있습니다. 결과적으로 향상된 이벤트 기록 기능을 통해 조직에서는 시스템을 보다 효과적으로 관리할 수 있습니다.

Val Menn은 Microsoft의 Management Infrastructure Group에서 이벤트 로그 프로그램 관리자로 일하고 있으며 이전에는 여러 회사에서 소프트웨어 엔지니어와 시스템 관리자로 근무했습니다.

© 2008 Microsoft Corporation 및 CMP Media, LLC. All rights reserved. 이 문서의 전부 또는 일부를 무단으로 복제하는 행위는 금지됩니다..