レベル: 初級 Kalpana Doraisamy (kdoraisa@in.ibm.com), Staff Software Engineer, IBM
Ajay G Rengasayee, Software engineer, Freelance
Abdi Salahshour (abdis@us.ibm.com), Problem Determination Architect, IBM
2007年 6月 19日 この 4 回シリーズでは、Log and Trace Analyzer for Java™ Desktop の概要、インストール・プロセスについてのアドバイス、ツールを正しく構成する方法などについて包括的に説明します。また、パフォーマンス向上のヒント、統合方法、ハンズオン・シナリオに加え、IBM Tivoli Monitoring 6.1 Events Tool に関する情報も紹介します。データを使いやすいものにする方法を見つけ出し、問題判別や保守のコストを削減する方法を学んでください。第 1 回では、データ収集の課題を明確にするとともに、その課題に対処していくうえで共通イベント・フォーマットとシンプトン・リポジトリーがどのように役立つのかを説明します。
シリーズの第 1 回目の本記事では効果的なデータ収集に対する現在の阻害要因を説明します。次回以降は以下の内容を取り上げます。
- Log and Trace Analyzer for Java Desktop (LTA-JD) のアーキテクチャーと機能について概説し、インストール手順を確認。
- テクノロジーについて視覚的に解説し、トラブルシューティングのヒントを提供し、LTA-JD から最大のパフォーマンスを引き出す方法を説明。
- LTA-JD の IBM Tivoli Monitoring Events Tool について説明。
データ収集の課題
問題判別とは、ビジネス・アプリケーションの運用状況や可用性に影響を与える状態を検出して診断することです。データ収集における課題の 1 つは、問題判別の実行に要する時間です。例えば、製品は独自のフォーマットを使用して書き込みを行います。同様に、アプリケーション、データベース、ネットワークなども、それぞれ特有のフォーマットで特定の内容を書き込みます。データベース・アクセス用のネットワーク障害が原因でアプリケーションに問題が発生した場合、アプリケーション、データベース、ネットワークからの状況をユーザーがすべて把握し、さまざまなフォーマットのログを手動で相関しなければならないため、問題判別に伴う複雑さは増大します。アプリケーションが多くの製品と情報をやり取りしているため、それぞれの製品で障害が発生した場合、より複雑さが増大する一因となっています。
そのためシステムの可用性に影響を与える状態から最小限の時間で回復し、ビジネスや IT システムの可用性を最大化することが課題となっています。これを実現するには、監視情報を収集するとともに、ツールを使って重要な状況を素早く検出し、根本に潜む問題を診断し、利用可能なナレッジを適用し、通常のビジネス・オペレーションや IT システム運用を回復することが必要です。
多くの場合、複数の観察対象イベントが組み合わさっているために問題が複雑化し、人間による分析が困難で時間のかかるものになっています。監視ソリューションはこのような問題を自律的に相関させて対応する機能を備えており、状況に応じて、単純なイベント優先順位付けを行ったり、一連のイベントに対する複雑な根本原因の分析を行ったりします。その結果、オペレーターが調査や対応を要するタスクははるかに少なくなります。
Log and Trace Analyzer (このシリーズの目的では Java Desktop 版) をシンプトン・イベント・ビジュアライザーとして使用すれば、効果的なデータ収集を阻む以下の 3 つの主要な阻害要因を解決するのに役立ちます。
-
e-ビジネス・システムの複雑さ。今日のビジネス・システムは、分散環境にある異種のソフトウェア/ハードウェア・コンポーネントから構成されています。
-
多種多様なデータとコレクター/アダプター。コレクターの多様さと収集データの膨大さのために、いくつかの問題が引き起こされます。例えば、独自のデータ・フォーマットをどのように使用して公開するのか、異なる設計や標準をどのように共存させるのか、臨時のコードや製品固有のコードをどのように統合するのか、さまざまなシステムの構成・保守・調整に必要となる各種スキル・セットをどのように統合するのか、企業間の問題診断を相関させることの困難さをどのように克服するのかといった問題が存在します。
-
インスツルメンテーションの違いの克服。インスツルメンテーションの違いにより、標準への準拠、お客様の利便性、所有コストなどが問題となっています。さらに、標準化が欠如している場合は、やり取りする管理対象リソース (プロデューサー) ごとに管理ツール (コンシューマー) を準備する必要があります。これではコストもかかり、効率も悪くなります。
こうした課題に対応するには、そのためのツールを定義する必要があります。
ツールの定義
前述の問題に対処するためには、製品間の分析と相関を可能にする、より表現力のある標準化された形式が必要となります。それは、効果的な根本原因分析と自動化のための前提条件です。また、この種のデータには標準も不可欠です。標準がなければ、問題判別と対応処置を自動管理するうえでイベント・データはほとんど役に立ちません。
この問題の解決方法の 1 つは、イベント・データを 4 つのカテゴリーに分類することです。
- 「ソース」は、状態の影響を受ける、または状態に直面しているコンポーネントです。
- 「レポーター」は、状態を報告するコンポーネントです。これは状態の「ソース・コンポーネント」とも呼ばれます。
- 「状態」データは、状態を記述するプロパティーまたは属性です。
- 「コンテキスト/相関」データは、状態をその他の情報と相関させるためのプロパティーまたは属性です。
Common Base Event フォーマット/WSDM Event Format の適合性
この点において、Common Base Event フォーマットと WSDM Event Format は現状に適合しています。Common Base Event はイベント定義であり、IBM による WSDM Event Formal (WEF) の最初の実装です。Common Base Event フォーマットと WEF では、ログの記載方法に関する共通の構造が提供されるため、ユーザーは「すべての製品ログ用の 1 つのフォーマット」だけを理解すればよいようになっています。多様なログ・フォーマットは、アダプターを活用して標準フォーマットに変換されます。Common Base Event フォーマットと WEF 標準は、問題判別の単純化と迅速化を目指して設計されました。発生イベントの詳細情報を提供するために各種の要素が用意されているほか、Common Base Event フォーマットを表示する際に利用できるツールもあるため、システム障害状況の理解が容易になります。
Common Base Event フォーマットは、IT システムの稼動中に生じたイベントを表現する共通フォーマットです。企業はロギング、管理、問題判別、オートノミック・コンピューティング、オンデマンド・ビジネス機能などをさまざまな異種コンポーネントでサポートしていますが、この共通フォーマットを使用すれば、コンポーネント間での効果的な相互接続が容易にできるようになります。
Common Base Events は、以下のものを提供します。
- さまざまな領域 (ビジネス、セキュリティー、ネットワーク、システムなど) の正規化イベント定義とログ情報に関する、一貫した仕様
- イベントやログの交換フォーマット
- コンポーネントの外部操作機能に関する状態記述
- コンポーネント内の実行情報を収集するデータ
- コンテキスト・データ
シンプトンの定義
「シンプトン (症状)」は知識の形式の 1 つであり、管理対象環境における、起こりうる問題や診断状況を示しています。シンプトンは、監視対象データ がシンプトンの定義と一致したときに認識されます。
オートノミック・コンピューティングの定義はもう少し複雑で、「複数の管理可能リソースとの関連において起こりうる問題・状態の特徴的な兆候」と定義されています。これは以下の 3 つに分類されます。
- オートノミック・システムにおいて問題や状態を解決するための、知識の一形式
- 未加工情報や複合情報のパターンを組み合わせて構成される、複合的な情報記録
- 他のシンプトンの合成
定義の結び付け: イベントからシンプトンへ
ここで、「どのようにしてイベントからシンプトンを導きだすのか」という疑問が出てきます。次の定義を思い出してください。「イベント」とは何らかの監視対象の状況を示すものであり (例: メモリー使用量がしきい値を超えた)、「シンプトン」とは、複数の管理可能リソースとの関連において起こりうる問題や状態の特徴的な兆候です。この 2 つは次のように関連付けられます。
イベント x (および y (および...) ) が (一定の条件の下で) 発生した場合、その発生回数と可能な解決処置を報告する
例えば「メモリー使用量が 10 分間に 3 回、しきい値を超えた」という場合は、バッファー・サイズを増やすという対応によって問題を解決することが可能になります。
この情報の使用方法
LTA-JD によるイベントの視覚化では、オートノミック・コンピューティングの概念 (例えば、IT インフラストラクチャーの管理・運用に関連するインシデントや問題を表現、検出、評価、解決するためのシンプトンなど) が適用されます。さらに、こうしたインシデントや問題を事前に回避するための効果的な予防策として、シンプトンの視覚化と処理方法が提案されます。
さて、ここからは「バリュー・プロポジション (価値の提案)」です。
この記事で提案した情報は、以下の 3 つの点で役立ちます。
- 管理データがエンド・ユーザーにとってさらに使いやすいものになります。
- 問題判別ツール内から製品のシンプトンが視覚的に提供されます。
- シンプトン (パターン) は個々のイベントよりも確定的です。
- 問題判別コストの削減に役立ちます。
- 管理者は、自動イベント相関機能を使ってシステムの状態 を認識できます。
- サポート担当者は、問題判別ツールからシンプトン・データベースを直接利用できます。
- 製品横断的なシンプトン・カタログが提供されるため、既知のエラーを素早く診断できます。
- 保守コストの削減に役立ちます。
- シンプトンの活用により、レベル 1、2、3 のサポートの依頼がいずれも減少します (レベル 1 (L1) はお客様からの電話に応答する最初のサポートです。レベル 2 (L2) は L1 で問題が解決されない場合に関与するもので、通常はより知識のあるサポート・エンジニア、例えば各製品のエキスパートなどが関わります。レベル 3 (L3) は一般に、コード変更を行って修正版を提供する、変更チームや開発メンバーです)。
ツールの紹介
この実現を支援するツールがシンプルで容易に活用が可能なJava イベント・ビューアー、Log and Trace Analyzer for Java Desktop (LTA-JD) です。LTA-JD は、問題の切り分けや問題分析の優先順位付けのために、共通イベント・フォーマット (Common Base Event) のマージ、フィルタリング、ソート、分析、表示を実施することが可能です。LTA-JD が提供する優れた視覚化メカニズムは、根本原因分析、問題予測、解決のプロセスにかかる時間を短縮します。業界標準の XPath 式を利用したシンプトンとのマッチングが可能です。分析機能とユーザー・スキルという 2 つの軸で捉えた Log and Trace Analyzer 製品ファミリーのマトリックスを、図 1 に示します。
図 1. Log and Trace Analyzer ファミリー
Log and Trace Analyzer for Java Desktop はベーシックな問題判別のツールとして位置づけられていますが、低く評価してはいけません。この製品は異機種混合環境のイベント・ソースをエンド・ツー・エンドで表示できるほか、カスタマイズ可能なサマリー・ビューを提供します。また、サマリー・ビューから任意の行を選択して展開し、Common Base Event の属性をすべて表示することもできます。この製品を使用すれば、任意のイベント・プロパティーに基づくマルチレベルのフィルタリングやソート、イベントのハイライティング、構成設定を保存・共用することが可能になります。
次回の記事では、Log and Trace Analyzer for Java Desktop のアーキテクチャーと機能について概説し、インストール手順を確認します。
参考文献 学ぶために
- developerWorks の「Autonomic computing」ゾーンには、システム・イベント (レポート/ビュー) や Log and Trace Analyzer の使い方についての「ライブラリー」があり、常に拡充されています。
- W3C 仕様「XML Path Language (XPath) バージョン 1.0」で、XPath に関する貴重な情報を入手してください。
- XPath の詳細情報と、XPath が Web サービス標準の WS-* ファミリーにどのように適合するかについては、以下の「仕様を知る」シリーズを参照してください。
- developerWorks の「Autonomic computing」ゾーンには、Common Base Event フォーマットに関する充実した「ライブラリー」があります。
- developerWorks の「シンプトン（症状）の深層を探る」シリーズでは、オートノミック・コンピューティングにおけるシンプトンのアーキテクチャーとフォーマットを紹介し、シンプトンの表現方法や識別方法、標準的なシンプトン表現を使う利点、システム管理戦略の一部に採用する方法など、シンプトンに関する情報を詳しく説明しています。
- WSDM や WEF のリソース、および他のオートノミック・コンピューティング・テクノロジーに関する最新情報については、developerWorks の「Autonomic computing」ゾーンにアクセスしてください。
-
テクノロジーのブックストアで、これらのテクノロジーやその他の各種技術に関する文献を探してください。
製品や技術を入手するために
議論するために
著者について  | | | Kalpana Doraisamy は、IBM のスタッフ・ソフトウェア・エンジニアであり、現在は主に Lightweight Infrastructure for Systems Management に取り組んでいます。以前の任務では、2年以上にわたって Log and Trace Analyzer for Autonomic Computing を担当していました。また、Log and Trace Analyzer for Java Desktop の上級開発者の 1 人であり、インドのコインバトールにある Government College of Technology で情報工学の学士号を取得しました。 |
| | | Ajay G Rengasayee は、IBM India Software Lab (IBM インド・ソフトウェア研究所) でオートノミック・コンピューティングを担当するシステム・ソフトウェア・エンジニアであり、Log and Trace Analyzer for Autonomic Computing とその関連技術の開発者です。彼はまた、Log and Trace Analyzer for Java Desktop の開発者 の 1 人でもあります。 |
| | | 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 との共同作業の中で、オートノミック環境に新しい技術やデータ・マイニングを活用し、適用することでした。
|
記事の評価
| 
