Windows Vista

Windows Vista 中新的事件管理工具

Val Menn

 

概览:

  • 新的事件基础结构
  • 事件类型
  • 结构化事件属性
  • 使用 XPath 表达式

许多人认为事件记录和跟踪是一件烦事。而另一些人则抱怨,事件跟踪和记录多半是一些辅助活动(如调试和自我监控功能)的“副产品”,没必要对事件记录与跟踪功能过分重视。

为了扭转这些观念,Microsoft® Windows Vista™ 在企业管理方面向前迈了一大步。Microsoft 对一些重要组件及其用户界面进行了大幅改进。事件日志服务已经被完全重新编写,编写时充分考虑了企业需求,而跟踪则变得更加快捷、安全。

设想一下,如果为关键任务系统配备一组能发现和解决问题的更好的工具那该多棒。能够支持技术人员轻松收集来自用户系统的可作为证据的事件与跟踪的功能是不是很不错?如果您的开发人员能够使用由动态出现的用户发送的跟踪来诊断并修补一个部署系统中的 Bug,情况又会怎样?假设您拥有更加简便、功能更强大的收集信息和快速进行故障排除的方法 — 那么事件记录与跟踪将不再是件烦事,不是吗?

什么是事件?

计算机应用程序就如用一个执行某种功能(或多种功能)的一个“黑盒”。许多工作是在盒子内部完成的,但是由于您无法对盒中情况探其究竟,因此很难理解其内部的工作方式。然而,应用程序是要对外与其他程序和用户进行通信的。这些通信“事件”使您能够对该应用程序有一个概括了解。

而对于软件,事件一般被定义为软件系统中的偶发事件,其需要与外界(“外界”指的是用户或其他程序)进行交流。这类事件通常对应着状态或配置的改变。它可以就软件系统当前的状态或配置以及发生改变的原因进行通信。

更宽泛一些,“事件”这一术语还被用来指这些偶发事件的公开方式。有许多这类公开事件的示例:

  • 用于进程间通信 (IPC) 的 Win32®对象
  • 用于临时(非永久性)通知的 WMI 事件
  • Windows 事件跟踪 (ETW) 可以跟踪保存到跟踪文件中的事件
  • 保存到事件日志实时日志中,或者可能被存档到事件日志文件中的事件日志事件
  • 使用自定义基础结构保存到文件中的事件

在此列出的最后三个示例涉及了我们将要在本文中介绍的事件类型。

事件使用方式

跟踪或记录的事件是对程序或操作系统中的偶发事件的记录。这些跟踪和事件日志不仅仅适用于开发人员。它们为 IT 和技术支持人员提供了必备的工具,能够及时了解正在运行的应用程序的状态和内部工作情况。

您可以使用这类日志监控整个系统的运行状况。使用事件日志,您可以搜索任何注明有问题的事件。例如,您可能发现在 CertificateServicesClient 源程序的应用程序日志中的错误事件 6 带有下列消息:“本地系统自动认证注册失败 (0x80070576)。客户端或服务器端的时间和/或日期存在差异。”同样地,您还可以检测组件从出现问题状态返向正常操作状态的过渡。例如,当时间和日期差异被更正后,同一个 CertificateServiceClient 源程序将在应用程序日志中发布信息事件 19,该事件带有下列消息:“<用户名>的认证注册成功收到一份来自认证机构<机构名称>的 AutoenrolledWindowsSystemComponentVerification 证书。”这种信息对于发现并解决与配置有关的冲突和其他问题非常重要。

该信息还为诊断问题提供了便利。您可以找到导致问题的程序和系统并发现能够帮您确定问题根源的详细信息。类似地,您还可以使用该信息评估并解决性能问题。

事件日志还提供了宝贵的信息,您可以用来确保环境更加安全。它们可被用来检测入侵企图、审核系统历史记录、确保不得否认性以及发现未正确配置的资源。

Windows Vista 中的事件

以前版本的 Windows® 在事件记录和跟踪方面存在许多缺陷。其中包括:事件日志的可伸缩性有限(这使得所有日志的总的大小被限制为不超过可用内存的数量)、事件发布性能有限(这限制了一个活动域控制器可发布的事件的数量)、跟踪事件的安全性有限。

借助新的事件记录和跟踪工具(称为 Windows Eventing 6.0),Windows Vista 解决了许多这类问题。该工具扩展了自 Windows 2000 以来一直在使用的 Windows 事件跟踪 (ETW),并取代了事件日志服务和事件查看器。新的 Windows Eventing 是专为处理日志文件中的事件以便今后进行检查而设计的。(它不是针对于类似 IPC 和通知机制的临时事件。)

通过提供安全性和可伸缩性解决方案,自定义的事件记录和跟踪实施应该不太重要了。请注意,在保持与现有事件日志和 ETW API 完全兼容的同时,提供了增强的功能,这意味着所有现有应用程序将无需改变,继续可用。

查看事件的新方法

现有事件查看器是 IT 社区中最常用的 Windows 程序之一。新的事件查看器已经被完全重新编写,由于其包含在 Microsoft Management Console (MMC) 3.0 中,其外观已发生变化,但仍然非常类似,因此,从现有的查看器向新的查看器过渡应当相当简便。

其中依旧包括三个窗格和一个事件列表。您仍可以使用类似的应用程序、系统和 Windows 日志节点下的安全日志。然而,根节点下添加了一些新的节点,我们很快将要讨论的新的 ForwardedEvents 日志已经被添加到了 Windows Logs 节点下。

最明显的新功能是位于事件列表下的预览窗格。它包括聚焦事件的属性。这意味着您不再需要双击某一事件以查看该事件的属性,您不必调整窗口以查看列表和“事件属性”对话框。仍然可能需要双击一个事件以便在对话框中显属性。不过,新的对话框不是模式对话框,因此您可以同时显示多个事件属性对话框。

新的视图使您只需点击几下鼠标就可以显示想要查看的所有事件。可以为一个或一个以上的日志文件收集事件,并关注特定的 ID、级别(安全性)或时间框。

请注意,在“自定义视图”节点下,您将发现 Administrative Events(如图 1 所示)。其提供了一份管理员感兴趣的各类日志文件的所有错误和警告的列表。

图 1 Administrative Events

图 1** Administrative Events **(单击该图像获得较大视图)

那么,我们如何确定管理员会对哪些日志和事件感兴趣呢?我们明确了五种单独的事件类型以及与每一类型相关的用户。图 2 中对此进行了详细说明。这是对各组可能感兴趣的所有事件日志和跟踪事件进行的一般而有效的划分。

Figure 2 事件类型及其用户

事件类型 说明 使用者
Admin 对于多数系统管理员而言,Admin 类型已经足够了。这些事件级别较高,通常提供足够的信息来识别问题和确定解决方案。至少,Admin 事件应该识别问题发生的时间,并且当应用程序、组件或系统处在不正常状态或从不正常状态恢复时,给出提示。多数 Admin 事件是错误或警告,它们通常是可操作的。 管理员、技术支持人员以及监控和分析程序
Operational 与 Admin 事件类似,Operational 事件支持问题诊断。Operational 事件不仅包含错误和警告。它们还能通知用户如何正常使用应用程序或操作系统组件。这些事件的量很少,因此,Operational 事件的使用不会影响系统性能。Operational 事件 — 以及 Admin 事件 — 可以被技术支持人员、监控食用程序以及一些经验丰富的管理员使用。 高级管理员、技术支持人员以及监控和分析程序
Audit Audit 事件提供了对资源访问或用户采取的行动的历史记录。这些事件本身并不代表程序的成功或失败,而只表明操作的失败或成功。审核事件可以根据粒度的不同级别被完全禁用或有选择地启用。支持操作系统级的安全审核(事件日志安全日志中可找到的事件)。 高级管理员、安全审核员以及 Forensics 专家
Analytic Analytic 事件与 Operational 事件完全不同,它们可以在应用程序和组件的正常操作过程中被记录。但 Analytic 事件的量和详细程度远大于 Operational 事件,因此,它们有可能对系统性能造成负面影响。因而,Analytic 事件正常情况下是被禁用的。要使用 Analytic 事件,应在诊断会话开始之前启用它们,并在检查跟踪之前禁用它们。 技术支持人员、监控与分析程序
Debug Debug 事件也是正常情况下被禁用的大容量事件。它们主要由开发人员使用,很少有 IT 专业人员查看。 开发人员

Windows Eventing 有指定的类型。日志中的所有事件都具有该日志的类型。图 1 中的视图是使用该类型信息定义的 — 它从 Admin 类型的日志中挑出所有错误和警告事件。

Windows Eventing 体系结构

Windows Eventing 基础结构包括允许由程序发布事件对象并传递给日志文件的软件组件。ETW 提供了用于从其事件发布服务器向其目标位置传递所有类型的事件的传输过程。在 Windows Vista 中,ETW 也已经被修改,现在可提供更好的性能和全球性。通过 ETW 发布事件是个异步过程,因此不会影响发布程序的性能。当系统收到新的事件时,关于当前用户环境以及发布过程的信息被收集并附加到事件中。

事件发布后,以不同的方法来处理不同类型的事件。由于 Analytic 和 Debug 事件通常规模较大,它们需要经过最少的处理即被保存到文件中以避免影响系统性能。因此,这些事件会被立即保存到跟踪文件中。

Admin 和 Operational 事件很少能在不影响系统性能的情况下支持其他处理过程。这些事件被传递给事件日志服务,事件日志服务将它们保存到实时事件日志中并选择性地将它们传递给实时订阅服务器。订阅服务器可以使用我很快会介绍的查询语言来分拣将要传递给它们的事件。

值得一提的是,有两类对 IT 社区特别重要的订阅服务器。这些订阅服务器包括功能更强的 Windows Vista Task Scheduler 以及能够被用于向远程事件收集器发送事件的事件转发器。

结构化事件概览

事件日志常常被抱怨包含了大量的“垃圾”。也就是说,它们充斥了大量重要性较小甚至不重要的事件,这些事件会隐匿一些重要事件。而一些事件提供的很少信息,对于某位用户而言,似乎毫无用处,而对于另一位用户则可能非常有价值。

Windows Vista 提供了过滤掉不重要事件的方法,使您可以只关注那些对您而言至关重要的事件。该方法以事件日志服务支持的跨日志查询语言为基础。为了使用该方法,所有事件必须遵循定义良好的结构。

以前版本的事件日志提供了一些事件结构,但这类结构未被良好定义,而且仅对 Win32 API 是可见的。在 Windows Vista 中,事件有了定义良好的结构。实际上,使用带有已发布架构的 XML 可以在外部表示事件。这使创建这样的查询成为可能:在过滤掉对您不相干的事件的同时收集对您至关重要的事件。由于要使用 XML,XPath 被选作事件查询语言的基础。当然,结构化事件的使用为自动化开启了新的大门,可以使用新的 Task Scheduler 集成工具来查看事件的使用情况。.

事件预览窗格被包含在“详细信息”选项卡中。在“事件属性”对话框中也有相同的选项卡。选择“事件属性”对话框中的 “详细信息”选项卡可以展示事件的 XML 表示。图 3 显示的示例是 Task Scheduler 的一个 Operational 事件。它包含两个部分。System 部分由一般的事件信息组成,对于该事件的每一个事件实例而言(这些信息都是通用的),以及发布实例时收集的一些参数。EventData 部分,该部分是可扩展的,包含应用程序的结构化信息。

图 3 事件的 XML 表示

图 3** 事件的 XML 表示 **(单击该图像获得较大视图)

每一个事件日志文件都被看作一个这类结构化事件元素的序列。这提供了一个事件日志和事件存档文件的逻辑的、可读的视图。在内部,事件被以二进制格式存储,旨在确保紧密性、可靠性和搜索性能间的平衡。

事件属性

XML 数据的 System 部分提供了时间发生的时间、过程 ID、线程 ID、计算机名以及用户的安全标识符 (SID)。在以前版本的 Windows 中,事件有两大属性 — EventID 和 Category。XML 还提供了其他详细信息,包括 EventID、Level、Task、Opcode 和 Keywords 属性。让我们进一步了解一下这些属性。

EventID 和 Version:使用 EventID(一个两字节数)和 Version (一字节数)的组合可以唯一地识别一个事件。共享 EventID 和 Version 的同一个事件提供程序的所有事件也共享相同的结构。

Level:该值代表一个事件的严重性和详细程度。通常使用 5 种预定义的值:1(重要)、2(错误)、3(警告)、4(信息)、5(详细),但提供程序可以自行定义最大不超过 255 的值。更高的数值对应更详细的事件。

Task:Task 属性通常识别事件提供程序功能的一个常规方面(如打印、网络或 UI)。它还可以指程序的一个子组件。Security Audit(安全审核)事件可以更广泛地使用这些属性。每个事件发布服务器可以定义自己的一组两字节数值。请注意,Task 属性的含义与以前版本的 Windows 中的 Category 属性在语义上通常是匹配的,Task 属性可看作 Category 属性的一个扩展集。因此,事件查看器在名为 Task Category 的列中显示了该值。

Opcode:这是一个一字节的值,通常用于表示软件执行的某一特定操作或操作的一部分。该值通常在跟踪基于活动的过程时被使用(如 Web 服务,其中活动是 Web 服务接受的一项特定请求)。有一些预定义的值,其中最常用的是 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 表达式指示包含在起始元素中的另一个元素。由于事件日志实质上是事件元素的序列,您可以假设各日志如下所示:

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

根元素没有名称 — 它仅仅用作所有 XPath 表达式的上下文。仅仅定义前向轴,这意味着一个 XPath 表达式可以引用事件元素,事件元素的子元素,以及它们的属性。如果一个 XPath 表达式选择一个存在的元素,则评估为“真”。考虑一下一个基于如图 3 所示的事件的非常简单的 XPath 表达式:

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

该表达式可以从具有 2 级或更小级别(表示所有错误和关键事件)的 Microsoft-Windows-TaskScheduler 事件提供程序选择所有事件元素(“all”用星号表示)。

在使用简单的 XPath 表达式从单个日志选择事件的同时,简单的、功能强大的基于 XML 的查询语言支持从任何日志或外部日志档案选择和禁止事件。实际上,查询语言在 Windows Vista 事件中普遍存在。例如,自定义视图就是基于查询的。您可以使用查询语言来指定在事件查看器的“事件列表”窗格中应当显示哪些特定日志中的事件。您可以使用该语言来订阅事件、归档所选事件并触发新的 Task Scheduler 中的任务。

实际的查询 XML 或 XPath 表达式必须提供给事件日志命令行实用工具。不必为每个人定义这类查询,因此,事件查看器只提供了创建通用查询的简单 UI。例如,图 5 所示的“创建自定义视图”对话框可被用于创建一个针对所有 Task Scheduler 事件的视图。请注意,每个查询创建对话框都有一个题为 XML 的选项卡,该选项卡显示了查询文本,使您能够直接编辑查询。

图 5 创建通用查询的 UI

图 5** 创建通用查询的 UI **(单击该图像获得较大视图)

查询的通用方法

查询有多种使用方法。但是,有些方法显然比其他方法更常用。例如,查询通常被用于在事件查看器或事件日志命令行实用程序中查看事件选择。

您可以使用 Windows Task Scheduler 将任务与查询相连。当发布与查询匹配的事件时,Task Scheduler 将启动指定的任务。请注意,这一功能使用订阅并能对新到达的事件做出反应。您可以只订阅 Admin 事件和 Operational 事件;Debug 事件和 Analytic 事件被直接写入跟踪文件,当它们发生时,系统无法对其进行检查。

查询可被用于对选择的事件进行存档。您可以从任何类型的实时日志、下一级事件存案(EVT 文件)、外部跟踪文件或 Windows Vista 事件存档文件。存档文件可在事件查看器中打开,备份到次要存储设备中或发送给技术支持人员以便诊断问题。所有事件说明和与事件相关的其他设置可以在存档操作过程中以选择的语言连接到存档文件。这样一来,在任何机器上,事件均可以以选择的语言来使用,并带有全部事件说明。

最后,查询可被用于将事件转发给专门收集事件的系统。这一功能使用新的事件收集器服务,该服务允许管理员创建对远程计算机的事件订阅。这些订阅存在于收集器计算机中,并且能够使用可配置的计划来重新尝试。事件收集器使用符合行业标准的 WS 管理协议创建对远程计算机的订阅,并使用 WS 事件协议传送事件(这两个协议是安全和不受防火墙影响的)。事件收集器接收的事件被保存到本地事件日志中。

总结

Windows Eventing 的变化是巨大而影响深远的 — 本文只能对它们进行一些简单介绍。单单事件转发功能可能就需要一整篇的篇幅来阐述。

事件系统在性能、可伸缩型、可靠性和安全性方面做了改进。但是不要忘记主要的目标是提高 Windows 的可管理性。查询语言以及事件查看器视图使您能够更轻易地发现问题。与 Task Scheduler 的紧密集成为简化监控、自动解决问题和快速通知问题状况提供了方法。事件转发支持事件存档、服务器和桌面机的无代理监控。

所有这些功能都能在不影响后向兼容性的情况下进行实施,这意味着现有解决方案仍然继续可用。最终,这些对事件记录的改进会帮助组织更有效地管理它们的系统。

Val Menn任职于 Microsoft 管理基础结构组,担任事件日志软件项目经理。他曾担任软件工程师和许多新项目的系统管理员。

© 2008 Microsoft Corporation 与 CMP Media, LLC.保留所有权利;不得对全文或部分内容进行复制.