レベル: 中級 Abdi Salahshour (abdis@us.ibm.com), Problem Determination Architect, IBM
Marcelo Perazolo (mperazol@us.ibm.com), Autonomic Computing Architecture, IBM
2007年 3月 27日 問題判別の「優先順位付け」の設定は、どのように行うのでしょう。この記事では、問題判別を優先順位付けするための、イベントの視覚化に関するさまざまな側面について説明します。こうした視覚化の側面では、オートノミック・コンピューティングの概念 (例えば LTA-JD (Log and Trace Analyzer for Java Desktop) や、ビジネスにおけるミッション・クリティカルなインフラ管理やオペレーションに関連するインシデントや問題を表現し、検出し、評価し、そして解決するためのシンプトン (症状) を使用します。この 2 回シリーズの記事ではそうしたインシデントや問題を効果的に事前回避するために、LTA-JD を使ってイベントとシンプトンを視覚化し、処理する方法についても説明します。この第 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 回では詳細をご紹介する予定です。
問題判別
問題判別というのは、ビジネス・アプリケーションの運用状況あるいは可用性に影響を与える状況の検出と診断のことを言います。問題判別の目標は、システムの運用や可用性に影響を与える状況からの回復に要する時間を最小化することによって、ビジネスと IT システムの可用性を最大にすることです。これを実現するためには、重要な状況を素早く検出するためにツールを使って監視情報を収集し、根本に潜む問題を診断し、利用可能なナレッジを適用して通常のビジネス・オペレーションや IT システム・オペレーションを回復する必要があります。問題のあるシンプトンが検出されるのは、多くの場合、そのシンプトンに対する判断基準を満足するすべてのイベントが観測された場合です。この記事では、以下の内容について説明します。
- シンプトン・イベントのインクリメンタルな検出と視覚化を容易に行う方法
- イベントとシンプトンを視覚的に表したものとを効果的な方法で組み合わせ、人間のオペレーター同士の間でドメイン・ナレッジを共有するための方法
問題判別イベントは、特に問題判別プロセスをサポートするために使われることを目的としたイベントです。問題判別イベントはさまざまな種類のデータを含んでいますが、そのデータとしては次のような情報があります。
- 運用状況
- 状態変化
- リクエスト処理
- パフォーマンス・メトリックあるいは障害情報
問題判別に関するオートノミック機能を有効にするためには、正規化されたイベント・フォーマットが必要です。そのうちの 1 つは、既に Common Base Event として利用可能です。Common Base Event は、オートノミック機能を実現する構成要素の間で問題判別の状況を伝達するための、イベントの正規化表現であり、オートノミック・コンピューティングによる自己管理システムを実現するための基本的な要素です。Common Base Event の標準化に関する情報は、「参考文献」を参照してください。
オートノミック・コンピューティングでは、構成要素同士が頻繁に通信し、データと知識を交換します。多くの場合、この知識には、単純なイベントから合成したパターンや、状況を説明する情報、その状況を解決するための推奨アクションなどが含まれます。正規化されたフォーマットに記述された知識であるシンプトンは知識の 1 つの形式であり、管理対象の環境における、問題の可能性、あるいは診断された状況を表します。
問題判別を実行する方法には、次のように 2 つの異なる方法があります。
- 人手による方法では、インシデントと問題はドメイン・エキスパートによって直接処理されます。
- オートノミック・システムの方法では、自動的に検出、診断、回復、解決をするための情報を提供するには、シンプトンが絶対に必要です。
オートノミック・システムの成熟レベルに応じて、イベント監視アプリケーションの人間による監視機能を、シンプトンを処理できるオートノミック・マネージャーの機能と組み合わせます。これによって、人間のオペレーターとオートノミック・マネージャーとが共存することになり、オートノミック・マネージャーが力仕事をすべて行う一方、オートノミック・マネージャーの判断のレビューと承認は、人間が専門知識を使って行います。
LTA-JD、イベントとシンプトンの視覚化ツール
LTA-JD はイベントとシンプトンの監視アプリケーションを合わせて実装しています。LTA-JD はスタンドアロンで使いやすい Java イベント・ビューアーであり、非常に多くの製品からのログ・ファイルの内容やイベントを 1 つのビューの中で収集し、マージし、フィルターし、ソートし、表示し、そして分析することができ、それによって問題の切り分けと問題分析の優先順位付けを行うことができます。LTA-JD は、Common Base Event を含むイベント・データを、標準のイベント・フォーマットを使って集約します。こうした機能をいくつかの Tivoli® 製品 (IBM® Tivoli Monitoring など) に統合し、これらの製品の問題分析機能全体を拡張することができます。実際このツールによって、キャプチャーしたイベント・データに対して、問題の根本原因を判別するための詳細な分析を行うことができます。
LTA-JD では、問題判別タスクを人間が手動で管理することができ、また問題の収集、検出、分離、(回復のための) 診断、そして解決を支援するオートノミック・コンピューティング機能と統合することができます。LTA-JD が提供する、優先順位付け機能と優れた視覚化機構を組み合わせることによって、根本原因の分析と問題の解決を行う能力を向上させることができます。また業界標準の XPath 式を使うことで、ドメイン固有情報と単純なシンプトン・イベント選択ルールを容易に見つけ出すことができるため、シンプトン・イベントを素早く検出し、視覚化することができます。
イベントが収集されてまとめられると、一連のイベントの中の、あるイベントに一致するそれぞれのシンプトンに対して、そのシンプトンに関連する推奨アクションが、引き出されたり作成されます。そして視覚化された特徴が、ツールによって収集されたイベントに関連付けられ、また関連するシンプトンの視覚化された特徴にも関連付けられます。同様に、ツールによって収集されたイベントのテキスト情報は、そのイベントに対応する関連シンプトンへの推奨アクションに関連付けられます。すると、ある基準を満たすイベントの集合に含まれるイベントをグループ分けすることによって、イベントとシンプトンのデータが処理されます。その基準とは、人間のオペレーターがツールのエンド・ユーザー・インターフェースを使って設定した基準です。このようなイベントとシンプトンの集合は、エンド・ユーザーが処理すべき情報の量を絞り込むために役立ちます。
- LTA-JD のアプリケーションは、次のような主な機能から構成されます。
- イベント正規化モジュール。このモジュールではさまざまな種類の情報が収集され、そしてシステムが理解できるフォーマットに変換されます。
- イベント・フィルタリングと視覚化モジュール。このモジュールでは管理対象リソースからの情報が収集され、システム管理者やサポート要員に対して表示されます。
- 単純なシンプトン定義モジュール。このモジュールではシンプトンが作成され、視覚化パラメーターと関連付けられます。
- 統合シンプトン視覚化モジュール。このモジュールは、シンプトンを視覚化したものとイベント (これが今度はシンプトンのコンポーネントとなります) を視覚化したものとを重ねてシンプトンを表示します。
- 動的シンプトン回避モジュール。このモジュールではシンプトンの傾向が検出され、管理者に対して、シンプトンそのものが出現するのを回避する (問題の発生前に問題を回避する) ために行うべき推奨事項が表示されます。
図 1 は、LTA-JD の主なアーキテクチャー要素を示しています。
図 1. Log and Trace Analyzer for Java Desktop の主なアーキテクチャー要素
LTA-JD のデータ正規化機能は、LTA-JD と緊密に統合された GLA (Generic Log Adapter: 汎用ログ・アダプター) フレームワークによって実行されます。GLA は現在、(アプリケーション・ログ・ファイルの形式での) アプリケーション特有の情報を標準の Common Base Event フォーマットに変換する、既製のアダプターを数多く提供しています。
LTA-JD のイベント・フィルタリングと視覚化モジュールは、単純なビジュアライザーによって提供されています。ユーザーは、このビジュアライザーを使って、不要なイベントや重要ではないイベントをフィルターで取り除き、実際に問題に関与するイベントのみに集中することができます。
図 2 は LTA-JD のメイン画面を示しています。このビューは、イベントが表の形式で配置される様子と、従来のイベントの監視作業を行うための選択とフィルタリングの機構があることを示しています。また、特定のイベントを詳細に調べ、そのイベントの属性や値を検証するための方法も用意されています。そして最後に、正規化されたさまざまなイベント・ソースを統合するための方法も用意されており、管理対象システムの中に存在する多種多様なイベント全体の姿を包括的に見ることができます。
図 2. LTA-JD に表示されたイベント
典型的な場合では、IT 管理者はこのフィルタリングした情報を視覚化し、イベント・フローに対して手動で分析を行います (フィルタリングの適用と、視覚による検査を行います)。そして、どんな問題が起きているのか、またその問題を解決するために何をすべきかを判断します。
LTA-JD のフィルタリング機能は、Fast XPath と呼ばれる、強化された特別な XPath プロセッサーによって提供されます。このプロセッサーは、大量のイベントとフィルター式を処理するよう、また素早く一致結果を返すように最適化されています。
シンプトン定義と各種要素の視覚化
多くの場合、シンプトンは手動で作成されるか、あるいは次のようなシンプトンを構成する主なサブ・コンポーネントを半自動的に取得することで作成されます。
- メタデータはメインの属性の値を含みます。
- スキーマは実行時にどのような情報を関連付けるかを定義します。
- シンプトン・ルールはシンプトンをどう認識するかを定義します。
- シンプトン効果はシンプトンにどう反応すべきかを定義します。
(「参考文献」にはシンプトンの標準化に関する情報があり、またシンプトン効果の概念が説明されています。)
LTA-JD の現行の機能は、(Rule Builder を使って) シンプトン・ルールの作成に使用でき、これによって、シンプトンを認識し (つまり情報、例えばシンプトンのコンポーネントであるイベントなどに対する問題の切り分けと診断を行い)、シンプトン・イベントを特定するための、単純な方法を定義することができます。このシンプトン・ルールとしては、任意のルールを作成可能です。LTA-JD は、さまざまな管理環境で定義されるシンプトンの相互運用性を容易に高められるという理由から、標準式やルール構文 (XPath など) を使います。
Rule Builder によって作成されるルールには、追加のプロパティーとして、シンプトンを詳細に記述するテキストである description (一般的には、そのシンプトンに関するエキスパートが提供します) や、そのルールに一致するイベントを強調するための highlighter (色はカスタマイズできます) などを加えることができます。highlighter は、シンプトン・イベントの視覚化の効果を高め、問題の検出や分析を行いやすくします。
図 2 は、LTA-JD のメイン画面を示しており、ユーザーが定義した特定のルールに一致した、いくつかのイベントが強調されています。また、ツールチップが提供されており、強調されているイベントの上にマウス・カーソルを置くと、その highlighter (ルール) に関連付けられた description が表示されます。
LTA-JD は、ルール (selection criteria としても知られています) の作成を簡単にするために、単純な Rule Builder を提供しています。Rule Builder は単純なルール・エディターであり、XPath 言語に慣れていない人でもすぐに、以下の 3 つを目的とした単純ながらも複数の要素からなるルールを作成することができます。
- ルールに一致するイベント (シンプトン・イベントと認識されるイベント) を特定する
- シンプトン・イベントの視覚化効果をもっと高めるために、(さまざまな色を使って) 対象とするイベントを強調する
- 強調されているイベントのみが表示されるように、イベント群を容易に折りたためるようにする
従って、XPath の構文の知識がまったくない人でも、単純にイベントのプロパティーと比較演算子あるいはブール演算子を使って、ルールを作成することができます。図 3 は、単純な Rule Builder ウィンドウを示しています。
図 3. 単純な XPath Rule Builder
図 4 は、LTA-JD の Add/Remove highlighter ウィンドウを示しています。このウィンドウで視覚化情報がシンプトン定義と関連付けられています。図を見るとわかるように、このウィンドウは、識別子 (シンプトンの作成者が提供するか、あるいはシンプトン定義から抽出され、ここでは description がそれに相当します) と、シンプトン・コンポーネント (そのシンプトンを構成する相関イベント群) をペイントするために使われる背景色と前景色 (文字色)、そして highlighter のフィルター (単純なシンプトン・ルールとしても知られています) から構成されています。こうしたイベントの決定は、実行時にシンプトン・ルールを適用することで行われます。
図 4. 視覚化パラメーターをシンプトン・ルールに関連付ける
こうした情報が LTA-JD で利用できるようになると、LTA-JD は処理対象のイベントが到着するごとに、この情報を使って実行時に優先順位分析を行い、それをエンド・ユーザーに表示します。
さらに、LTA-JD は IBM の Symptom 2.0 フォーマットをサポートしており、IBM 提供の既存のシンプトン・カタログやユーザーから提供されるカタログ (既知の問題を含んでいます) を活用します。シンプトンは、オートノミック・コンピューティングのナレッジ・コンポーネントの 1 つの形式であり、ログ分析に使用されます。そのため、LTA-JD や他の LTA の中で、システム・エラーの条件を特定する際にも、またその問題を解決するためのアクションをとる際にも活用することができます。
カタログは、ローカル・システムから、あるいは ftp サイトや http サイトから、1 つあるいは複数選択することができます。IBM は現在、WebSphere® Application Server や DB2® Universal Database Manager など、いくつかの主要な IBM 製品のためのシンプトン・カタログを 10 種類提供しています。これらのシンプトン・カタログは、IBM Tivoli の OPAL (Open Process Automation Library) から入手することができます。また、カタログ・アドレスは Add/Remove symptom catalog ウィンドウからも提供されています。
LTA-JD の分析機能を使う場合、ユーザーは 1 つ以上のイベントを選択し、そしてプルダウン・メニューから Analyze を選択します。選択されたイベント群のリストの各イベントは、選択されたカタログのリストに対してチェックされ、1 つ以上の一致があるかどうかを調べられます。これをもっと単純に、強調されたイベントの中から 1 つを選択して Analyze を選択する方法もあります。この場合、強調されたすべてのイベントが分析されます。
選択されたイベントに対するシンプトン・カタログが検索され、シンプトンが発見されると (複数発見される場合もあります)、各イベントに対して別々にシンプトン定義がレポートされます。分析の結果を見るためには、LTA-JD のメイン・ビューの一番下の部分にある、イベントの詳細ビューの Analysis タブを選択します。一致が発見された場合の分析結果には、シンプトンの名前と description、シンプトンへの対応として考えられる推奨事項、そして考えられる推奨アクションが含まれます。図 5 は、分析されたイベントのビューを示しています。
図 5. シンプトンの分析結果のビュー
まとめ
この記事では、一般的な問題判別タスク (多くの環境では、通常まだ人間によって行われています) を自動化するために必要な、問題判別の基本とオートノミック・コンピューティングの成果物のいくつかについて説明しました。そして、連携による一層複雑な分析 (個別の、あるいは人による管理では通常は把握不可能なもの) を行うために必要な一般的なインフラについて説明しました。
この記事の第 2 回では、手動操作を調和させるための方法とアプリケーションについて、そして連携による複雑な分析を行うために必要な一般的なインフラについて説明する予定です。
私達の目標は、次のことを実証することです。それは、LTA-JD が、優先順位付けの分析を行うために必要な、そして問題の切り分けと診断を行うことを可能にしてくれるインフラを提供していることと、LTA-JD は、シンプトンを分析できるため、非常に容易でしかも統一された方法によって、問題判別の優先順位付けを進めることができるということです。
またここでは、既存シンプトンのコンポーネントとして回避ルールやアクションを追加することによって、高度な予測分析や事前の回避動作も行えることを示しました。
IT システム管理者が、自信を持って、一般的なタスクをオートノミック要素に託すことができるようになれば、彼らは、ここで説明した複雑なタスクに必要なコンテンツを (すべてが統合された共通の、視覚化および実行環境の中で) 作成する作業に集中することができます。それを行うために必要なインフラは既に整っています。必要なことは、この機能を有効に生かし、予測と回避のための、より良いコンテンツに取り組むことだけなのです。
参考文献 学ぶために
製品や技術を入手するために
議論するために
著者について  | 
| | Abdi Salahshour は、ノースキャロライナ州 Research Triangle Park にある IBM の Autonomic Computing Technology and Enablement のシニア・ソフトウェア・エンジニアであり、また問題判別アーキテクト、実用化スペシャリストとして、オートノミック・コンピューティング技術と実用化ツールに関する業務を行っています。彼は 1982年に IBM に入社し、データベース診断ツールの設計と開発からシステム管理、そして異機種混成かつ分散環境における自己修復アーキテクチャーと実用化まで、さまざまな業務を担当してきました。また、問題判別成果物のモデリングとアーキテクチャーに焦点を絞った IBM Problem Determination Council のメンバーを務めたこともあります。彼は IBM の Common Base Event 仕様の作成者の 1 人であり、ジェネリック・ログ・アダプターを設計、実装した 1 人でもあります。この 2 年半の彼の中心業務は、IBM Research との共同作業の中で、オートノミック環境に新しい技術やデータ・マイニングを活用し、適用することでした。
|
| 
| | Marcelo Perazolo は、IBM のオートノミック・コンピューティング・アーキテクチャー・チームのメンバーです。シンプトンや、その他のナレッジ・フォーマットに関するアーキテクトであり、オートノミック・コンピューティングに関連した管理統合分類法 (Management Integration Taxonomies) を定義しています。1990 年から IBM で働いており、ネットワーク管理やシステム管理に関する様々な業務を行ってきました。1994 年に電子工学で修士を取得しています。関心を持っている領域としては、問題の判別や予測、プロセス最適化手法、セキュリティー、相関技術、ナレッジ表現などがあります。 |
記事の評価
| 
