レベル: 中級 Marcelo Perazolo (mperazol@us.ibm.com), Autonomic Computing Architecture, IBM
Abdi Salahshour (abdis@us.ibm.com), Problem Determination Architect, IBM
2007年 4月 10日 問題判別の「優先順位付け」の設定は、どのように行うのでしょう。この記事では、問題判別を優先順位付けするための、イベントの視覚化に関するさまざまな側面について説明します。こうした視覚化の側面では、オートノミック・コンピューティングの概念 (例えば LTA-JD (Log and Trace Analyzer for Java Desktop)) や、ビジネスにおけるミッション・クリティカルなインフラ管理やオペレーションに関連するインシデントや問題を表現、検出、評価し、そして解決するためのシンプトン (症状) を使用します。この 2 回シリーズの記事では、そうしたインシデントや問題を効果的に事前回避するために、LTA-JD を使ってイベントとシンプトンを視覚化し、処理する方法についても説明します。第 2 回となる今回の記事では、このフレームワークが実際にどのように機能するのかを詳しく解説します。
このシリーズの第 1 回の復習をしましょう。ごく単純なことですが、イベントを監視するタスクは、イベント・ソースの量や数が増加するにつれて複雑になります。そして、イベントを適切に視覚化できなければ、問題判別や根本原因の分析も不十分なものとなり、それが時間の損失、不適切なビジネス習慣、そして回復のためのコスト増大につながります。そのため、イベントやイベントに関連するシンプトンの視覚化を改善し、人間が目で確認できる情報の質を向上させる必要があります。なぜなら、人間による問題把握が、問題の検出、切り分け、防止につながるからです。オートノミック・コンピューティングによる管理アプリケーションでは、このアプリケーションが監視する一連の管理対象リソースに対して機能や要件を定義する、特定の管理スタイルをサポートすることができます。
イベントの視覚化には、いくつかの異なる手法があります。通常、イベント監視ソリューションには、イベントに関連する問題の分析や対応に責任を持つ、人間のオペレーターが介在します。オペレーターは、イベントの組み合わせに関する経験と認識に基づいて、いつ問題が発生するのか、どのようにその問題を解決するのかを判断します。IT 環境では、複数のイベントを組み合わせることによって、より複雑な問題の所在を明らかにすることができます。そしてその時点で人間による分析が非常に困難で、かつ、時間を要するものになる可能性があります。
こうした場合には、監視ソリューションによってイベントの組み合わせを自動的に相関させる処理を行い、システム・エンジニアの負担を軽減させる必要があります。この自動相関処理では、根本原因の分析を行ったり、問題の痕跡をたどり、そこへ与えた相対的な影響に応じてイベントをグループ分けしたりします。こうして根本原因を明示するイベントが自動検出され、人間のオペレーターが調査や対応を行えるように、そして、できれば無事に問題を解決できるように表示される必要があります。
オートノミック・コンピューティングの管理アプリケーションがサポートする管理スタイルは、ハンズオン型、ハンズオフ型、もしくはその両方が可能です。ハンズオン型のスタイルを使う場合には、オートノミック・マネージャーは、管理しているリソースをポーリングし、いつアクションを起こすべきかを判断します。別の言い方をすると、この方法は、人間とユーザー・インターフェースを組み合わせることで、オートノミック・コンピューティング・アーキテクチャー (「参考文献」を参照) における、マニュアル・マネージャーの役割を果たすための、最適な方法です。例えば、マニュアル・マネージャーは複数のイベント・ソースを監視し、特定の重要度を持つイベント (オートノミック・コンピューティングの用語でシンプトンとしても知られているパターン) が 1 つ以上観測された場合には、その観測された問題を軽減する、あるいは解決するために、1 つ以上のアクションを開始するかもしれません。
一般的に、問題のシンプトンが検出されるのは、そのシンプトンに対する基準 (シンプトン・ルールとしても知られています) を満たす全てのイベントが観測された場合です。実際、このシリーズの記事の主な目標の 1 つは、シンプトンのインクリメンタルな検出と視覚化を容易に行うための方法を説明すること、また、イベントとシンプトンを視覚的に表したものとを最も効率的に組み合わせ、人間のオペレーター同士の間でドメイン・ナレッジ (つまりシンプトン定義) を共有するための方法を説明することです。このドメイン・ナレッジの共有は、LTA-JD (Log and Trace Analyzer for Java Desktop) という簡単なイベント・ビジュアライザーによって行われます。LTA-JD は、問題の切り分けや問題分析の優先順位付けのために、標準化されたイベント・ソース (例えば Common Base Event (CBE) や、WEF (WSDM (Web Services Distributed Management) Event Format) など) のコンテンツを収集し、マージ、フィルタリング、ソート、表示、そして分析することができるツールです。
LTA-JD が提供する、優先順位付け機能と、優れた視覚化機構を組み合わせることにより、根本原因の分析や、問題の予測、問題への対応といった能力を向上させることができます。また LTA-JD によって、シンプトン・ルールに似たドメイン固有情報と半構造化された情報を、業界標準の XPath 表現形式を使って、容易に見つけ出して取得することができ、シンプトン・イベントの検出や視覚化が迅速になります。
この 2 回シリーズの記事では、イベントの監視、問題の分析や対応のためのシンプトン検出、そして LTA-JD によって実装される高度な視覚化属性に関する基本事項を説明します。第 1 回では基本事項に焦点を絞ったので、この第 2 回では、より詳細な説明を行います。
段階的検出機能
前述したように、LTA-JD はスタンドアロン型の使いやすい Java™ イベント・ビューアーであり、問題の切り分けと問題分析の優先順位付けを行うために、多数の製品からのログ・ファイルの内容とイベントを 1 つのビューのなかで収集、マージ、フィルタリング、ソート、表示、そして分析することができます。LTA-JD は標準化されたイベント・フォーマットを使用して、Common Base Event に代表されるようなイベント・データを集約します。
LTA-JD には、イベントの各集合を処理する際に視覚化情報をイベントの各集合に関連付け、1 つの「複合イベント」あるいは 1 つのシンプトンへのイベントの各集合の関与をエンド・ユーザーに通知する機能もあります。さらに、シンプトンを相互に関連付けて、ビジネス・プロセスの従来からの要素であるインシデントまたは問題を組み立てることもできます。以下に、LTA-JD の主要な機能を要約します。
- 異種環境にまたがるイベント・ソースのエンドツーエンド表示
- タイムスタンプ、あるいは Common Base Event プロパティーを基準にしたソートによる相関付け
- 任意のイベント・プロパティーのフィルタリングおよびマルチレベル・ソート
- 優先順位付けイベント (単純なシンプトン・イベント選択ルール) のカスタム強調表示
- シンプトン・カタログを用いたイベント分析
- 優先順位付けイベントのみを表示するためのイベント・ビューの折りたたみ
- 連携を目的としたフィルター、強調表示機能、構成設定値 (インポート/エクスポート) の保管と共有
- 任意のイベント・プロパティーによるサマリー・イベント表示のカスタマイズ
- サマリー・ビューの行選択および展開による全 Common Base Event 属性の表示
- 収集したイベントのタイム･ゾーンおよびフォーマットのオンデマンド変換
- HTTP、FTP、または IBM® Tivoli® Common Event Infrastructure によるリモート・イベント・ソースへのアクセス・サポート
- さらに高度な相関付けおよび連携を行うための別の LTA へのイベント (分析結果) 転送
LTA-JD の機能を説明するのに最もふさわしいシナリオとして、エンド・ユーザーが Microsoft Windows® XP 環境で DB2® データベースを使用した WebSphere® Application Server アプリケーションである PDWebApp を実行しているとします。午前10時頃になるとサーバーへのアクセスに問題が生じるのですが、ユーザーにはその理由がわかりません。
複数コンポーネントから構成されるソリューションで問題が発生すると、「責任のなすりつけ合い」が起こりがちです。そのような事態を避けるために使えるのが LTA-JD です。LTA-JD を使うと、PDWebApp、DB2、そして Windows Application/System Events によって生成されたログ・イベントを分析するだけで、問題の原因を特定することができます。
まず、問題の原因として考えられるコンポーネントの診断ソースからのイベントを最初に調べます。調査の対象には、WebSphere Application Server のログ・ファイルである activity.log も含まれます。このファイルには、アプリケーション・サーバーと該当する環境で実行されているアプリケーションが生成した操作イベントが記録されています。さらに、DB2 の診断ログと Windows のイベント・ログで、データベース・マネージャーやネットワークに異常があるかどうかも調べなければならない場合もあります。
上記のイベント・ソースをインポートするには、メニュー・バーで File > Add/Remove Event Sources を選択します。次に Add/Remove event source ウィンドウで Import Event Source を選択して Add event source ウィンドウを表示します。このウィンドウで、それぞれのログ・ファイルにインポートするイベント・ソースのタイプに該当する Event source type を選択します。選択したイベント・ソース・タイプは Generic Log Adapter が提供するアダプターに関連付けられ、このアダプターが製品固有のログ・フォーマットを統一イベント・フォーマットである Common Base Event フォーマットに変換します。
図 1 に、WebSphere Application Server の activity.log ファイルの例を示します。DB2 ログおよび Windows イベント・ログに対しても同じ手順を繰り返します。
図 1. イベント・ソースのインポート (WebSphere Application Server の activity.log ファイル)
さらに、フィルターを定義したり、イベント・ソースごとにイベントのタイムスタンプを調整することも可能です。図 2 に、フィルターまたはイベント・タイムスタンプを指定する方法を示します。フィルターはフィルター・エントリー・フィールドに直接入力することも、プルダウン項目から選択することもできます。また、図 2 のように Rule Builder を使用してフィルターを構成するという方法もあります。この場合、Result ビューに定義されているフィルターによって、個別のイベント・ソースがフィルタリングされます。
図 2. イベント・ソースのフィルターおよびデルタ時間
デルタ時間を追加して、受信したイベントのタイムスタンプを調整することもできます。これによって受信したイベントの元のタイムスタンプが変更されることはありませんが、Result ビュー上に表示されるイベントのタイムスタンプが変更されます。フィルターとデルタ時間はイベント・ソースごとに設定することができます。
すべてのイベント・ソースについての設定が完了すると、イベント・ソースが Common Base Event フォーマットでインポートされ、フィルタリングおよびマージが行われてから LTA-JD のメイン・ビューに表示されます。
次に必要なのは、対象のイベントを特定するための単純なルールを定義することです。単純なルールを定義することで、シンプトン・ルールを特定しやすくなると同時に、該当するイベントを強調表示するという方法でシンプトン・ルールをよりはっきりと視覚化することができます。一般にこれらのルールを定義するのは、問題に関する専門家または問題判別を行うサポート・エンジニアです。シンプトン・ルール/強調表示機能を定義する方法については、前回の記事の「シンプトン定義と各種要素の視覚化」セクションで説明しました。このシナリオでは、Rule Builder を使用して定義した以下の 4 つのルールを基準に、シンプトン・イベントを以下のように強調表示します。
- アプリケーションの正常な Start Situation
- WebSphere Application Server の致命的接続障害 (赤)
- WebSphere Application Server の通信エラー (ピンク)
- 接続障害が発生しているアプリケーション (濃い黄色)
- DB2 Database Manager の停止状態 (黄色)
- ネットワーク接続障害 (オレンジ)
イベントは、指定されたイベント・ソース (ログ・ファイル) からインポートされるときにルールと照合され、ルールに適合することでシンプトンとして特定された場合には強調表示されます。図 3 に示しているのは前に指定したイベント・ソースのインポート結果で、発生した順にソートされています。イベントをソートするには、結果ビューに表示されている列を選択してクリックします。クリックするたびに昇順、降順、マージされたときのままという具合に並べ替えられます。また、複数の列を基準にソートするという方法もあります。それには、最初の列をソートしてから Ctrl キーを押したまま、ソート基準とする追加の列をクリックします。Result ビューの列をカスタマイズすることも可能で、View > Select result columns を選択して、Available Properties リストに表示された Common Base Event プロパティーを選択してカスタマイズすることができます。
図3. イベント/シンプトン・イベントを組み合わせた視覚化結果
図 3 では、複数のソース (WebSphere Application Server、DB2、および Windows) からのイベントが作成時刻を基準に昇順でソートされています。7,205 件の有効な Common Base Event イベント結果があり、2 件の無効イベントがあることに注目してください。エラーが発生すると、通常は何千ものイベントが生成されるからです。これでは解決にかかる時間のコストが非常に高くつきます。
マージされた 7,205 件のイベントは発生順にソートされています (時間相関としても知られています)。作成時刻を基準にイベントをソートするには、カーソルを作成時刻の列に置いてマウスの選択ボタンをクリックします。1 回目のクリックでは降順のソート、2 回目のクリックでは昇順のソートが行われ、3 回目のクリックではマージされた時点での順序に戻ります。個別の Common Base Event イベント詳細を調べる場合は、結果サマリー・エリアから対象のイベント (フィールドは任意) を選択します。結果サマリー・エリアでイベントを選択すると、そのイベントがイベント詳細エリアに表示されます。イベント詳細エリアをナビゲートするには、上部にあるタブを選択します。
エラーが発生した時間枠が分かったところで (この例では午前10時から午後2時の間)、今後は意味のあるイベントにのみ対象を絞ります (ノイズ除去としても知られています)。そのために使用するのがフィルターです。この例では作成時刻を基準としたフィルターを使用しますが、それには、フィルターのルールを Rule Builder を使って作成することができます (メニュー・バーから View > Add/Remove filter を選択し、Rule Builder ボタンを押します)。フィルターをすでに定義してある場合は、結果ビュー上部にある Filter フィールドで、プルダウン矢印を選択して目的のフィルターを選択します。この例では素晴しい成果がありました。7,200 件以上もあったイベントがフィルターによって 93 件まで絞り込まれています。図 4 を見てください。
図 4. 強調表示されたシンプトン・イベント
対象のイベントをさらに強調するため、LTA-JD の強調表示機能を使用して、問題のシンプトンを示していると考えられるイベントを特定して強調表示するためのルールを定義します。この強調表示機能ではさまざまな色を使用できるので、さらに高度なシンプトン・イベントと問題パターンの視覚化を実現できます (図 4 を参照)。強調表示機能のルール (シンプトン・ルールとも呼ばれます) は、Rule Builder を使って作成します (メニュー・バーから View > Add/Remove highlighters を選択し、Rule Builder ボタンを押します)。
図 4 には、強調表示機能ルールで定義したシンプトンに関連すると考えられるイベントや、同じ期間に発生したその他のイベントも多数表示されています。丸印で囲んだ1 から 5 の数字で示したイベントは同じ問題に関連するイベントとして見なされるため、根本原因 (高位レベル) の視覚化という点では重複します。そのため、すべてのシンプトン･イベントを単純なシンプトン・ルール・イベントに照合すると、これらの色が一斉に変わることになります。このような段階的色分けは、人間の管理者が手作業で診断するときに行う演繹的プロセスのようなものです。この例ではまさにその方法で、アプリケーション・サーバー (WebSphere Application Server) とデータベース・サーバー (DB2 Universal Database) のインスタンスのなかから実際のインシデントを特定しています。
結果/サマリー・エリアの個々のイベントをクリックすると、Event Detail Area の表示セクションでその詳細を確認することができます。また、強調表示されたイベントにカーソルを重ねるとツールチップが表示されます。このツールチップに、その色に関連付けられたルールについての説明が表示されます。
この時点で、選別された (つまり強調表示された) イベントの分析を開始することもできますが、強調表示されたイベントのみを表示し、必要に応じて管理しやすいイベント数にまで減らすために、イベントをさらに折りたたんで切り分けることもできます。
以下は、図 4 に番号で示した 5 つのイベントそれぞれの分析結果です。
- このイベントは、アプリケーション PDWebApp が起動したことを示します (この他にも、PDWebApp 以外のアプリケーションの起動を示す、緑色で強調表示されたイベントがあります)。
- このイベントは、アプリケーションの障害が始まったことを示します。アプリケーションが 7 回復旧を試みたことがわかります。
- このイベントは、WebSphere Application Server と DB2 との通信エラーを示します。
- このイベントは、WebSphere Application Server と DB2 との「致命的な」通信障害を示します。
- アプリケーションに問題が発生した時期に発生したその他のイベントです。ここで特定の対象となるのは、DB2 データベースの停止です (自然の成り行きで停止した可能性もあります)。
一連のイベントを分析した結果として、何が問題の原因だと思いますか? (答は「まとめ」にあります。)
必要であれば、イベントの集合をさらに絞り込んで、強調表示されたイベントだけを表示することもできます。それには、イベントが表示されているメイン・ビューから、View > Show highlighted events を選択します (この操作についての詳細は、LTA-JD のオンライン・ヘルプを参照してください)。この例では図 5 に示すように、7,200 件以上あったイベントが見事に 18 件まで絞り込まれています。
図 5. 強調表示されたイベントの切り分け
さらに Analyze 機能を使って目的とするイベントを分析することができます。この機能は IBM Symptom Catalog 2.0 を使用して、選択されたイベントごとに、問題の詳細説明、推奨事項、そして問題の解決につながる可能性のある是正措置を示します。この機能を使うには、まず 1 つ以上のシンプトン・カタログを LTA-JD にインポートし、それからイベントが表示されているメイン・ビューの File メニュー・バーから、あるいはビュー内の対象イベントを右クリックすることによって、いずれかの分析機能 (Analyze selected events (選択イベントの分析)、Analyze highlighted events (強調イベントの分析)、または Analyze all events (全イベントの分析)) を選択します。図 6 を参照してください。
図 6. イベントの分析結果
LTA-JD は、時刻を基準とした相関関係 (時間シーケンス) の表示や、個々のイベントに対する単純な分析機能を提供するということを念頭に置いてください。そのため、LTA-JD が視覚的に相関関係を示したとしても、人間のオペレーターが優先順位付けされたイベントを視覚化して相互に関連付ける必要があります。さらに詳細な分析が必要な場合は、1 つ以上のイベントまたは強調表示されたすべてのイベントを選択してファイルに保存し、的確な担当者が対処できるように、そのファイルを E メールなどで送信するという方法があります。あるいは、IBM Log and Trace Analyzer for Eclipse などの別の LTA ツールにイベントを直接送信して、さらに詳細な相関付けと分析のために役立てることも可能です。イベントを送信するには、イベントが表示されているメイン・ビューで File > Save selected events to Analyzer を選択するか、他の 3 つの Save 機能のいずれかを選択します。これらの操作についての詳細は、LTA-JD オンライン・ヘルプを参照してください。
ここで、今回の問題判別のシナリオにおいて、LTA-JD がどのように役立ったかをまとめてみましょう。
- 最初に、着信イベント・ソースのフォーマットを再構成して標準化することにより、問題の診断と検出にかかる時間が短縮されます。異なるログのマージと時間を基準とした相関付け、そして関連イベントのフィルタリングと強調表示は簡単な操作で行えるため、プログラミング・スキルがなくてもイベントを 75 パーセントも削減できました (7,200+ -> 93 -> 18)。
- 二番目に、既知の問題は、詳細な問題説明と解決策の情報が含まれた、既知の問題のシンプトン・カタログによって認識され、迅速に解決されます。
- 三番目に、LTA-JD によって連携、フィルターの共有、強調表示機能、シンプトン・カタログ、そしてナレッジの共有が容易に行われるようになり、強化されます。連携、エクスポートおよびインポート機能の詳細は、LTA-JD のオンライン・ヘルプを参照してください。
まとめ
この記事では、一般的な問題判別タスク (多くの環境では、通常まだ人間によって行われています) を自動化するために必要な、問題判別の基本とオートノミック・コンピューティングの成果物のいくつかについて説明しました。そして、連携による一層複雑な分析 (個別の、あるいは人間による監理では通常は把握不可能なもの) を行うために必要な一般的なインフラについて説明しました。さらに、人手による操作を融合させるための手段とアプリケーションについて説明し、連携した複雑な分析に必要な共通インフラの詳細について解説しました。
このシリーズの目標は、LTA-JD には問題の切り分けと診断を可能にする優先順位付けの分析に必要なインフラが整っていること、そして LTA-JD では極めて簡単かつ統一されたシンプトン分析により、問題判別の優先順位付けを容易にできると証明することです。その目標のため、追加の回避ルールとアクションを既存のシンプトンのコンポーネントとして加えると、高度な予測分析と事前回避が可能になることを説明しました。
IT システム管理者が共通タスクをオートノミック要素に任せられるだけの自信を得た暁には、この記事で説明したような複雑なタスクに必要となるコンテンツの作成に専念し、すべてを共通の視覚化および実行環境に統合できるようになります。また、LTA-JD が提供する双方向性が、シンプトン、ルール、そしてアクションというオートメーション要素を作成するのにふさわしい手段であることも実感することでしょう。オートメーション要素を作成するのに必要なインフラはすでに整っています。このインフラを実行可能にするには、より優れた予測および回避コンテンツに取り組めばいいだけの話です。
ところで、図 4 の問題はデータベースがうっかり停止されてしまったことが原因だったようです。
参考文献 学ぶために
製品や技術を入手するために
議論するために
著者について  | 
| | Marcelo Perazolo は、IBM のオートノミック・コンピューティング・アーキテクチャー・チームのメンバーです。シンプトンや、その他のナレッジ・フォーマットに関するアーキテクトであり、オートノミック・コンピューティングに関連した管理統合分類法 (Management Integration Taxonomies) を定義しています。1990 年から IBM で働いており、ネットワーク管理やシステム管理に関する様々な業務を行ってきました。1994 年に電子工学で修士を取得しています。関心を持っている領域としては、問題の判別や予測、プロセス最適化手法、セキュリティー、相関技術、ナレッジ表現などがあります。 |
| 
| | Abdi Salahshour is a Senior Software Engineer, problem determination architect, Master Inventor at IBM's Autonomic Computing Technology and Development, and is currently an architect for the Plug and Manage architecture. He began working for IBM in 1982 and served in many roles -- from design and development of database diagnostic tools to system management and self-healing architecture and enablement in heterogeneous and distributed environments. He was a member of IBM Problem Determination Council, is one of the authors of the IBM Common Base Event specification, one of the principal designers and implementers of the Generic Log Adapter, and the architect and designer of the Log and Trace Analyzer for Java Desktop. |
記事の評価
| 
