Windows Vista

Windows Vista のイベント管理用の新しいツール

Val Menn

 

概要:

  • 新しいイベント インフラストラクチャ
  • イベントの種類
  • イベントの構造化されたプロパティ
  • XPath 式の使用

多くの人々は、イベント監視やトレースにはうんざりさせられると言います。多くの場合、トレースやイベントは補助的な操作 (デバッグ機能や自己監視機能など) の単なる副産物にすぎないと言う人もいれば、イベント監視機能やトレース機能が軽視されすぎていると言う人もいます。

Microsoft® Windows Vista™ は、このような見解を変えることを目指し、エンタープライズ管理という点で大きな一歩を踏み出します。マイクロソフトは、主要なコンポーネントの一部とそのユーザー インターフェイスを一新しました。イベント ログ サービスは、エンタープライズ環境を考慮して全面的に書き換えられました。また、トレースは実行時間が短縮され、セキュリティが強化されました。

ミッション クリティカルなシステムに関する問題点を検出および解決するための優れたツール セットが用意されたところを想像してください。サポート技術者が、ユーザーのシステムから証拠となるイベントやトレースを簡単に収集できる機能があるとどうなるでしょう。開発者が、ユーザーから送信されたトレースを使用して、展開済みのシステムのバグをその場で診断して修正できるとしたらどうでしょう。情報を収集して迅速にトラブルシューティングを行うことがこれまでよりも簡単かつ効果的になることを想像してください。これでも、うんざりだと言えますか。

イベントについて

コンピュータ アプリケーションは、(複数の) 関数を実行する "ブラック ボックス" のようなものです。このボックス内ではいろいろなことが行われますが、それを調べることができないため、内部動作を把握することは非常に困難です。ただし、アプリケーションは、表面上、他のプログラムやユーザーと通信します。このような通信 "イベント" により、アプリケーションの動作を垣間見ることができます。

ソフトウェアに関して言えば、通常、イベントは、外部に通信しているソフトウェア システム内の出来事と定義されます (外部とは、ユーザーまたは他のプログラムのことです)。このような出来事は、通常、状態や構成の変化に対応しています。これにより、ソフトウェア システムの現在の状態や構成とその変化の理由が通知される可能性があります。

"イベント" という用語は、さらに広い意味では、これらの出来事を公開する方法を示す場合にも使用されます。このように公開されるイベントの例は多数あります。

  • プロセス間通信 (IPC) に使用される Win32® オブジェクト
  • 一時的な (非永続的な) 通知に使用される WMI イベント
  • トレース ファイルに保存される Event Tracing for Windows (ETW) トレース イベント
  • イベント ログのログにリアルタイムに保存され、イベント ログ ファイルにアーカイブできるイベント ログ イベント
  • カスタム インフラストラクチャを使用してファイルに保存されるイベント

この記事では、上記の最後 3 つの例について説明します。

イベントの使用方法

トレースやログに記録されたイベントは、プログラムやオペレーティング システムでの出来事の記録です。このようなトレースやイベント ログは、開発者のためだけにあるのではありません。こうした情報は、ユーザーが実行しているアプリケーションの状態や内部動作を把握するための、IT 担当者やサポート スタッフにとって必要不可欠なツールになります。

このようなログを使用して、システム全体の状態を監視できます。イベント ログを使用すると、問題点を示すイベントを検索できます。たとえば、アプリケーション ログに、CertificateServicesClient からのエラー イベント 6 "ローカル システムの証明書の自動登録は、失敗しました (0x80070576) クライアントとサーバーの間で、時間または日付が違います。" というメッセージが記録されているのが見つかるかもしれません。同様に、コンポーネントが問題のある状態から通常の状態に移行したことがわかることもあります。たとえば、時間や日付の違いを修正すると、同じ CertificateServiceClient から情報イベント 19 "<user name> の証明書の登録で、証明機関 <authority name> から AutoenrolledWindowsSystemComponentVerification 証明書を正しく受け取りました。" というメッセージがアプリケーション ログに記録されます。このような情報は、競合、および構成に関する他の問題を検出して解決するために非常に重要です。

また、こうした情報は問題の診断にも便利です。問題や問題の原因となるシステム動作を突き止め、根本的な原因を特定する際に役立つ詳細を見つけることができます。同様に、このような情報を使用して、パフォーマンスの問題を評価して解決することもできます。

さらに、イベント ログでは、セキュリティが強化された環境を確保するために使用できる貴重な情報が提供されます。イベント ログを使用すると、不正侵入の検出、システムの履歴の監査、否認防止の保証、および正しく構成されていないリソースの検出を行うことができます。

Windows Vista のイベント

以前のバージョンの Windows® にはイベント監視やトレースに関して多くの欠点がありました。たとえば、イベント ログの拡張性の限界 (すべてのログの合計サイズが使用可能なメモリ量に制限されます)、イベントを発行する際のパフォーマンス (たとえば、アクティブなドメイン コントローラで発行できるイベントの数が制限されます)、トレース イベントのセキュリティの制限事項などがあります。

Windows Vista では、これらの問題の多くを、Windows Eventing 6.0 と呼ばれる、イベント監視やトレースのための新しいインフラストラクチャを使用して解決します。これは、Windows 2000 以降で使用されていた ETW を拡張し、イベント ログ サービスやイベント ビューアに置き換わるものです。新しい Windows Eventing は、将来の検証のためにログ ファイルに保存されるイベントを具体的に扱うようにデザインされています (IPC や通知メカニズムのような一時的なイベントは対象としていません)。

セキュリティ ソリューションやスケーラビリティ ソリューションを用意したことで、イベント監視やトレースのカスタム実装を行うことはそれほど重要ではなくなります。機能が強化されるだけでなく、既存のイベント ログや ETW API との完全な互換性が確保されることに注意してください。つまり、既存のすべてのアプリケーションは変更なしに機能し続けます。

イベントの新しい表示方法

既存のイベント ビューアは、既に、IT コミュニティで最も一般的な Windows プログラムの 1 つになっています。このイベント ビューアが新しく全面的に書き換えられました。Microsoft 管理コンソール (MMC) 3.0 に含まれるようになり外観も変更されましたが、それでも十分使い慣れた環境なので、移行は非常に簡単です。

ツリー ペインとイベントの一覧はそのまま存在します。[Windows ログ] ノードにある使い慣れた [アプリケーション]、[システム]、[セキュリティ] の各ログにもアクセスできます。ただし、ルートに新しいノードがいくつか追加されました。新しい [転送されたイベント] ログが [Windows ログ] ノードに追加されています。[転送されたイベント] ログについては、この後簡単に説明します。

最も目立つ新機能は、イベント一覧に下にあるプレビュー ウィンドウです。プレビュー ウィンドウには、フォーカスが設定されたイベントのプロパティが表示されます。つまり、イベントをダブルクリックしてイベントのプロパティを表示する必要がなくなりました。さらに、一覧と [イベントのプロパティ] ダイアログの両方を表示するために、複数のウィンドウを同時に開く必要もありません。依然として、イベントをダブルクリックして、プロパティをダイアログに表示することもできますが、新しいダイアログはモーダルではないため、複数の [イベントのプロパティ] ダイアログを同時に表示できるようになります。

新しいビューでは、マウスを数回クリックするだけで、目的のイベントをすべて表示できます。イベントは、1 つ以上のログ ファイルに収集できます。また、特定の ID、レベル (重要度)、または時間枠に的を絞って収集することもできます。

[カスタム ビュー] ノードの下に [管理イベント] があることに注意してください (図 1 参照)。ここには、さまざまなログ ファイルから、管理者に役立つすべてのエラーと警告の一覧が表示されます。

図 1 管理イベント

図 1** 管理イベント **(画像を拡大するには、ここをクリックします)

では、管理者に役立つログやイベントをどの程度正確に判断できたでしょうか。ここでは、5 つの個別のイベントの種類と、各種類に関連するユーザーを特定しました。詳細については、図 2 を参照してください。これは、さまざまなグループに役立ちそうなすべてのイベント ログとトレース イベントを効果的に区分する際に非常に一般的な方法です。

Figure 2 イベントの種類とそのユーザー

イベントの種類 説明 使用者
管理 大多数のシステム管理者にとって有益な種類です。これらのイベントは、非常に高レベルで、多くの場合、問題を特定してその解決策を決定するために十分な情報を提供します。少なくとも、管理イベントでは、問題が発生した時点を特定するか、アプリケーション、コンポーネント、またはシステムが全体的に問題のある状態から復旧した時点を示します。ほとんどの管理イベントはエラーまたは警告であり、通常は実用性があります。 管理者、サポート スタッフ、監視プログラムと分析プログラム
操作 管理イベントと同様に、問題の診断が可能です。操作イベントは、単にエラーと警告だけでは構成されていません。このイベントは、アプリケーションや OS コンポーネントの正常な操作に関する情報もユーザーに提供します。これらのイベントの量は非常に少ないので、システムのパフォーマンスに影響することなく、有効にできます。サポート スタッフ、監視ユーティリティ、および高度な技術力を持つ管理者は、操作イベントを管理イベントと併用します。 上級管理者、サポート スタッフ、監視プログラムと分析プログラム
監査 リソース アクセスまたはユーザーによる操作の履歴記録を提供します。これらのイベントは、本来、プログラムの失敗や成功を表しませんが、操作の失敗や成功は示します。監査イベントは、さまざまなレベルの粒度を使用して、完全に無効にしたり、選択して有効にしたりできます。OS レベルのセキュリティ監査がサポートされます (このイベントは、イベント ログのセキュリティ ログに記録されます)。 上級管理者、セキュリティ監査者、フォレンジック専門家
分析 分析イベントは、操作イベントとそれほど異なりませんが、アプリケーションやコンポーネントの正常な操作中にログに記録されます。分析イベントの量と詳細度は操作イベントよりも多くなるので、システムのパフォーマンスに悪影響を与える可能性があります。したがって、通常、分析イベントは無効になっています。分析イベントを使用するには、診断セッションの前にイベントを有効にし、トレースを検証する前に無効にします。 サポート スタッフ、監視プログラムと分析プログラム
デバッグ デバッグ イベントも量の多いイベントであり、通常は無効になっています。このイベントは、主に開発者が使用し、IT プロフェッショナルが目にすることはほとんどありません。 開発者

Windows Eventing の各ログには、種類が指定されています。そのログ内のすべてのイベントでは、そのログの種類を共有します。図 1 のビューは、この種類の情報を使用して定義されました。つまり、"管理" という種類のログからすべてのエラー イベントと警告イベントを取得しています。

Windows Eventing アーキテクチャ

Windows Eventing インフラストラクチャは、複数のソフトウェア コンポーネントで構成されています。これらのコンポーネントにより、イベント オブジェクトをプログラムから発行し、ログ ファイルに配信できます。ETW は、すべての種類のイベントをイベントの発行元から発行先に転送する際に使用されるトランスポートを提供します。ETW も Windows Vista で一新されたため、現在は、パフォーマンスが向上し、セキュリティが強化されています。ETW からのイベントの発行は非同期なので、発行元のプログラムのパフォーマンスには影響しません。システムは新しいイベントを受け取ると、現在のユーザー コンテキストと発行プロセスに関する情報を収集し、イベントに追加します。

イベントが発行されると、種類によってその処理方法が異なります。通常は分析イベントやデバッグ イベントの量が多いため、システムのパフォーマンスに影響しないように処理を最小限に抑えてファイルに保存する必要があります。そのため、これらのイベントはすぐにトレース ファイルに保存されます。

管理イベントと操作イベントは頻繁に発生しないため、システムのパフォーマンスに影響することなく追加の処理が可能です。これらのイベントはイベント ログ サービスに配信され、実際のイベント ログに保存されるため、必要に応じて、リアルタイムでサブスクライバに配信できます。サブスクライバは、クエリ言語を使用して、サービスに配信されるイベントを取得できます。クエリ言語については、後で説明します。

具体的には、特に IT コミュニティに役立つ 2 つのサブスクライバがあります。大幅に強化された Windows Vista タスク スケジューラと、リモート イベント コレクタへのイベントの送信に使用できるイベント フォワーダが代表的なサブスクライバです。

構造化されたイベントの表示

イベント ログに関してよく寄せられる苦情には、イベント ログに不要なデータが多く含まれている点があります。つまり、ほとんどまたはまったく意味のないイベントがイベント ログに散在しているため、重要なイベントが隠れてしまったり、不明瞭になりがちです。ほとんど情報を提供しないイベントもありますが、あるユーザーにとっては役に立たなくても、他のユーザーにとっては貴重な情報であることもよくあります。

Windows Vista では、関心のないイベントをフィルタで除外できるため、ユーザーは自身にとって重要なイベントに的を絞ることができます。これには、イベント ログ サービスでサポートされるログ間クエリ言語を使用します。この機能のために、すべてのイベントは明確に定義された構造に従う必要があります。

以前のバージョンのイベント ログのイベントにはいくつかの構造がありましたが、その構造が明確には定義されていなかったため、Win32 API でしか表示されませんでした。Windows Vista では、イベントの構造が明確に定義されています。実際には、イベントは、公開済みのスキーマを備えた XML を使用して外部に示されます。これにより、関心のあるイベントを収集すると同時に、無関係のイベントをフィルタで除外するクエリを作成できます。XML を使用するため、すべてのクエリ言語の基盤として XPath が選択されました。当然ながら、新しいタスク スケジューラの統合で見られるように、構造化されたイベントを使用することで、自動化への新たな扉が開かれます。

イベントのプレビュー ウィンドウに、[詳細] タブが含まれるようになりました。同じタブが、[イベントのプロパティ] ダイアログにもあります。[イベントのプロパティ] ダイアログの [詳細] タブをクリックすると、イベントの XML 表記が表示されます。図 3 に示すサンプルは、タスク スケジューラの操作イベントです。このイベントは 2 つの部分で構成されています。System セクションは、このイベントのすべてのイベント インスタンスに共通する一般的なイベント情報に加え、インスタンスの公開時に収集されたシステム パラメータで構成されています。拡張可能な EventData セクションは、アプリケーションからの構造化された情報を含みます。

図 3 イベントの XML 表記

図 3** イベントの XML 表記 **(画像を拡大するには、ここをクリックします)

各イベント ログ ファイルは、このような構造化されたイベント要素のシーケンスとして扱われます。これは、イベント ログ ファイルやイベント アーカイブ ファイルの判読可能な論理ビューを表します。イベントは、内部的には、簡潔さ、信頼性、および検索パフォーマンスのバランスを保つようにデザインされたバイナリ形式で保存されます。

イベントの属性

XML データの System セクションには、イベントの発生時刻、プロセス ID、スレッド ID、コンピュータ名、およびユーザーのセキュリティ識別子 (SID) が示されます。以前のバージョンの Windows のイベントには、イベント ID とカテゴリという 2 つの属性しかありませんでした。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 のカテゴリ属性に相当するか、それを含みます。このため、イベント ビューアでは、[タスクのカテゴリ] 列にこの値が表示されます。

Opcode : 特定の操作、またはソフトウェアによって実行される操作の一部を表すために通常使用される 1 バイト値です。この値は、作業に基づくプロセス (作業が Web サービスが受け取った特定の要求である場合の Web サービスなど) のトレースによく使用されます。事前に定義された値もいくつかありますが、最もよく使用されるのは 1 (開始) と 2 (停止) です。

Keywords : 56 個のフラグから成るマスクです。これらのフラグは、類似するイベントを簡単にグループ化できるようにプログラムで設定できます。各イベントに、複数のフラグを設定できます。つまり、イベントは複数のグループに所属できます。

発行元とイベントについて

イベント ログやトレース ファイルでどのような種類の情報が見つかるかがあらかじめすべてわかっていないと、事前の対応は困難です。そのため、新しいイベント監視インフラストラクチャの主な目的の 1 つに、各イベントの発行元に関するドキュメント (イベントとその発行先を組み合わせた情報など) の提供がありました。

これを実現するために、各発行元は、発行するすべてのイベントをそのイベントの構造と共に列挙する必要があります。この情報は、発行元のバイナリ (プログラムまたは DLL) でコンパイル、エンコード、および保存されます。

これで、イベント監視システムに登録されているすべての発行元に加え、各発行元の構成も発見できるようになりました。これには、発行元がログに記録する可能性のあるすべてのイベント、そのイベントの構造、および関連するメッセージの完全な一覧を表示することも含みます。こうした表示は、これらのイベントがスローされる前でも可能です。図 4 は、コマンド ライン ユーティリティ wevtutil を使用してプロバイダの構成を表示する方法を示しています。表示されているコマンドでは、Microsoft-Windows-Video-For-Windows という名前のイベントの発行元に関してシステムが把握しているすべての情報が表示されます。

図 4 wevtutil を使用してプロバイダ構成を表示する

図 4** wevtutil を使用してプロバイダ構成を表示する **(画像を拡大するには、ここをクリックします)

クエリ言語のしくみ

既に説明したように、新しいインフラストラクチャの構造化されたイベントの性質から、標準の XPath 式に基づくクエリ言語のサポートを含めることができました。一般的に、XPath 式は開始場所 (XML 要素) を指定すれば、要素内の任意の場所を参照できます (XPath 言語の詳細については、w3.org/TR/xpath にある公式資料 (英語) を参照してください)。さらに一般的には、XPath 式は開始要素内に含まれる別の要素または属性を参照します。イベント ログは本来 Event 要素のシーケンスなので、各ログは次のようになると考えることができます。

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

ルート要素には名前がありません。この要素は、すべての XPath 式のコンテキストとして使用されるだけです。順方向軸のみが定義されます。これは、XPath 式が Event 要素、そのサブ要素、およびその属性を参照できることを意味します。さらに、XPath 式は存在する要素を選択すると、true に評価されます。図 3 で示したイベントに基づいた非常に簡単な XPath 式を考えてみましょう。

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

この式では、Microsoft-Windows-TaskScheduler イベント プロバイダから、レベル 2 以下 (すべてのエラー イベントと重大イベントを意味します) の Event 要素すべて ("すべて" はアスタリスクで表されます) を選択します。

単純な XPath 式を使用して 1 つのログからイベントを選択できますが、単純でも強力な XML ベースのクエリ言語を使用すると、任意のログまたは外部のイベント アーカイブからのイベントの選択と選択解除が可能になります。実際、クエリ言語は、Windows Vista イベント監視で幅広く使用されています。たとえば、カスタム ビューはクエリに基づいて作成されます。また、クエリ言語を使用すると、特定のログの中から、イベント ビューアのイベント一覧ウィンドウに表示するイベントを指定できます。この言語を使用すると、イベントのサブスクライブ、選択したイベントのアーカイブ、および新しいタスク スケジューラでのアクションのトリガを実行できます。

実際のクエリの XML または XPath 式は、イベント ログ コマンド ライン ユーティリティに提供する必要があります。このようなクエリを定義することはだれでもできるわけではないので、イベント ビューアには、一般的なクエリを作成するための簡単な UI が用意されています。たとえば、図 5 に示す [カスタム ビューの作成] ダイアログを使用すると、タスク スケジューラのすべてのイベントに関するビューを作成できます。クエリを作成する各ダイアログには [XML] というタブがあります。このタブでは、クエリのテキストが表示され、クエリを直接編集できます。

図 5 一般的なクエリを作成するための UI

図 5** 一般的なクエリを作成するための UI **(画像を拡大するには、ここをクリックします)

クエリの一般的な使用方法

クエリはさまざまな場面で使用できます。ただし、当然ながら、クエリの中には、よく使用されるものとそうでないものがあります。たとえば、クエリは、選択したイベントをイベント ビューアやイベント ログ コマンド ライン ユーティリティで表示するためによく使用されます。

Windows タスク スケジューラを使用して、タスクをクエリに関連付けることができます。タスク スケジューラは、クエリに一致するイベントが発行されるたびに、指定されたタスクを開始します。この機能は、サブスクリプションを使用して、新しく到着するイベントに対応することに注意してください。管理イベントや操作イベントのみをサブスクライブできます。デバッグ イベントや分析イベントはトレース ファイルに直接書き込まれるため、システムはこれらのイベントを発生時に検証することはできません。

クエリを、選択したイベントのアーカイブに使用できます。イベントは、任意の種類のリアルタイム ログ、ダウンレベルのイベント アーカイブ (EVT ファイル)、外部トレース ファイル、または Windows Vista イベント アーカイブ ファイルから選択できます。アーカイブ ファイルは、イベント ビューアで開いたり、二次記憶装置にバックアップしたり、問題を診断するためにサポート スタッフに送信したりできます。すべてのイベントの説明などのイベントに関連付けられた文字列は、アーカイブ操作中に選択した言語でアーカイブに追加できます。この操作が完了すると、イベントには、コンピュータで選択している言語での完全な説明を表示できます。

最後に、クエリを使用して、イベント収集専用のシステムにイベントを転送できます。この機能では、新しいイベント コレクタ サービスを使用します。このサービスにより、管理者は、リモート コンピュータに対するイベント サブスクリプションを作成できます。これらのサブスクリプションは収集元のコンピュータに保存され、構成可能なスケジュールを使用して再試行できます。イベント コレクタは、業界標準の WS-Management プロトコルを使用してリモート コンピュータ上にサブスクリプションを作成し、WS-Eventing プロトコルを使用してイベントを転送します (どちらのプロトコルもセキュリティが確保され、ファイアウォールに対応しています)。イベント コレクタが受け取ったイベントは、ローカルのイベント ログに保存されます。

まとめ

Windows Eventing への変更は、劇的かつ広範囲に行われています。この記事では、こうした変更の一部のみを扱っています。イベント転送機能だけでも、1 つ記事を執筆できます。

イベント システムでは、パフォーマンス、スケーラビリティ、信頼性、およびセキュリティが強化されています。ただし、こうした強化の主な目的が Windows の管理の容易性を向上することにあったことを忘れないでください。クエリ言語をイベント ビューアのビューと併用することで、問題点の検出がさらに容易になります。タスク スケジューラとの緊密な統合により、簡単な監視、自動的な問題解決、および発生した問題の迅速な通知が可能になります。また、イベント転送機能により、サーバーやデスクトップのイベントのアーカイブやエージェントを使用しない監視が可能になります。

こうした機能はすべて、旧バージョンとの互換性を犠牲にすることなく実装されます。つまり、既存のソリューションは機能し続けます。最終的に、イベント監視の強化により、システムをより効率的に管理できるようになります。

Val Menn は、マイクロソフトの Management Infrastructure グループの一員で、イベント ログのプログラム マネージャをしています。以前は、多くのベンチャー企業向けのソフトウェア エンジニアおよびシステム管理者を担当していました。

© 2008 Microsoft Corporation and CMP Media, LLC. All rights reserved; 許可なしに一部または全体を複製することは禁止されています.