レベル: 初級 Abdi Salahshour (abdis@us.ibm.com), Problem Determination Architect, IBM
Kalpana Doraisamy (kdoraisa@in.ibm.com), Staff Software Engineer, IBM
Ajay G Rengasayee, Software engineer, Freelance
2007年 8月 07日 この 4 回シリーズでは、Log and Trace Analyzer for Java<trade/> Desktop の概要、インストール・プロセスについてのアドバイス、ツールを正しく構成する方法などについて包括的に説明します。また、パフォーマンス向上のヒント、統合方法、ハンズオン・シナリオに加え、IBM Tivoli Monitoring 6.1 Events Tool に関する情報も紹介します。データを使いやすいものにする方法を見つけ出し、問題判別や保守のコストを削減する方法を学んでください。第 3 回では、テクノロジーを紹介するビジュアル・ツアー で、トラブルシューティングのヒントを得て、LTA-JD のパフォーマンスを最大限引き出す方法をご紹介します。長い文章による説明よりも 1 つのスクリーン・ショットのほうが簡単に理解いただけると思います。
この記事のシリーズは、データの利用性を最大限に高めるために参考となる一連のリソースを 1 カ所にまとめ、問題判別と保守のコストを削減する方法を示すことを目的としています。
シリーズ第 1 回の記事では、現在、効果的なデータ収集を阻む以下の 3 つの主要な阻害要因を解決するのに役立ちます。
-
e-ビジネス・システムの複雑さ。今日のビジネス・システムは、分散環境にある異種のソフトウェア/ハードウェア・コンポーネントから構成されています。
-
多種多様なデータとコレクター/アダプター。コレクターの多様さと収集データの膨大さのために、いくつかの問題が引き起こされます。例えば、独自のデータ・フォーマットをどのように使用して公開するのか、異なる設計や標準をどのように共存させるのか、臨時のコードや製品固有のコードをどのように統合するのか、さまざまなシステムの構成・保守・調整に必要となる各種スキル・セットをどのように統合するのか、企業間の問題診断を相関させることの困難さをどのように克服するのかといった問題が存在します。
-
インスツルメンテーションの違いの克服。インスツルメンテーションの違いにより、標準への準拠、お客様の利便性、所有コストなどが問題となっています。さらに、標準化が欠如している場合は、やり取りする管理対象リソース (プロデューサー) ごとに管理ツール (コンシューマー) を準備する必要があります。これではコストもかかり、効率も悪くなります。
第 2 回の記事では、LTA-JD の概要、ツールのインストールと構成のガイド、およびツールの主な機能の一覧を紹介しました。
第 4 回では、LTA-JD の IBM Tivoli Monitoring Events Toolについて解説します。
今回の記事は、LTA-JD を紹介するビジュアル・ツアーです。
グランド・ツアー
当ツアーは、ツールの機能や、外観、操作感を知るのに役立ちます。以下の項目を取り扱います。
- LTA-JD の Viewer 画面
- ダイアログ: 利用可能なイベント・ソース・タイプの選択
- ダイアログ: すべてのイベント・ソースに対して定義されたフィルターよりも優先される、イベント・ソース毎のフィルター選択
- 複数のソースからのイベント作成時刻によるソート
- フィルターの使用と作成
- Viewerのハイライト機能
- 単純な XPath Rule Builder
- 潜在的イベントがハイライト機能のルールにより定義されたシンプトンにおいてどのような役割を果たしているか
- 強調表示イベント・ビューの切り出しや様々な視点からの分析
- シンプトン・カタログ準拠フォーマットのインポート
- 選択したシンプトン・カタログに対する、イベントの分析と視覚化
この記事では基本的に、第 2 回の表 1 に記載されている LTA-JD の主要機能ツールについて詳細を説明します。
LTA-JD の Viewer 画面
図 1 は、LTA-JD Viewer の画面です。
図 1. LTA-JD Viewer の画面
以下の手順に従います。
- イベント・ソース・ボックスに表示されているログ・ファイルのドライブ文字が、参照しているログの実際のソースと一致しない場合は、ステップ 2 に進みます。一致している場合は、ステップ 3 に進みます。
- メニュー・バーで、「File」、「Add/Remove Event Source」の順に選択します。
- 「Add/Remove Event Source」ダイアログで、「Select All」をクリックします。すべてのログがハイライトされます。
-
「Remove」をクリックします。選択したログがすべてリストから削除されます。
-
「Browse」をクリックします。
- 「Browse」ダイアログで、「Up One Level」をクリックすると、お使いの機器の構成によってルート・ディレクトリーの C: または D: に移動します。イベント・ソース・ファイルの完全な URI または FTP パスを指定すると、http サーバーまたは FTP サーバーからファイルをインポートできます。
- PDLogs フォルダーを見つけて、シングル・クリックします。ファイル名を入力するフィールドに PDLogs が表示されます。
-
「Select」をクリックします。表示される「Add/Remove Event Source」ダイアログには、4 つのログ・ファイルが含まれています。
-
「OK」をクリックし、ファイルまたは URL を削除するかどうかを確認するメッセージに「Yes」と答えます。このとき、「Summary/Results」エリアにはログ・イベントが表示されています。次の画面に移動します。
-
「Reset and Filter」をクリックします。ステップ 2 を実行した場合は、この操作は不要です。このとき、「Summary/Results」エリアにはログ・イベントが表示されています。
ダイアログ: 利用可能なイベント・ソース・タイプの選択
図 2 は、イベント・ソース (WebSphere Application Server、DB2、および Windows など) からイベントをインポートする際に使用するダイアログを示しています。
図 2. イベント・ソースからイベントをインポートするダイアログ
イベント・ソースをインポートする場合は、利用可能なイベント・ソース・タイプ (GLA、つまりCBEへのイベント・コンバーター・アダプターに対応しています) から選択することができます。お気付きのように、インポート時に表示されるパラメーターは、サーバー名、ユーザー ID など、イベント・タイプによってそれぞれ異なります。個々のイベントの詳細を確認するには、「Results/Summary」エリアで目的のイベント (フィールドは任意) を選択します。「Events detail」エリアに、結果が表示されます。「Events detail」エリア内を移動するには、エリア上部に表示されているタブを選択します。
ダイアログ: 個々のイベント・ソースに対するフィルターを選択
図 3 は、イベント・ソースからイベントをインポートする際に使用するダイアログを示しています。
図 3. イベント・ソースからイベントをインポートする際のフィルターの選択
すべてのイベント・ソースに対して定義されたフィルターよりも優先される、イベント・ソース毎にフィルターを選択 できます。イベント・ソースが生成された機器の異なるクロック・タイムを補正すべく、イベント・ソースのタイム・スタンプを調整できます。
作成時刻によりソートされた複数のソースのイベント
図 4 は、作成時刻により昇順にソートされた複数のソースによるイベントを示します。
図4. 作成時刻によりソートされた複数のソース
有効な Common Base Event が 7,205 個、無効なイベントが 2 個あることがわかります。通常、エラーが発生すると、数千個のイベントが生成され、解決までに多大な時間を要することになります。
イベントを作成時刻でソートするには、「Creation Time」列にカーソルを置いてマウスの選択ボタンをクリックします。マウスを 1 回クリックすると昇順にソート、2 回クリックすると降順にソートされ、3 回クリックするとイベントがマージされた時点の表示順に戻ります。
また、例えば、Situation Category、Creation Time、および Severity のような属性によるマルチレベルのソートも可能です。最初の属性でソートした後、その後の属性に対して単純なマルチレベル・ソートを実行する場合は、CTL キーを押したまま、対応する列の最上段を選択し、クリックします。属性は、この操作を繰り返していくつでも追加できます。
個々のイベントの詳細を確認するには、「Results/Summary」エリアで目的のイベントを選択します (選択するフィールドは任意)。「Events detail」エリアに、結果が表示されます。「Events detail」エリア内を移動するには、エリア上部に表示されているタブを選択します。
フィルターの使用と作成
エラーがいつごろ発生したのかがわかれば、重要なイベントのみに対象を絞り込むことができます。フィルターを使用すれば、これが可能になります。図 5 は作成時刻によるフィルタリングの例です。
図 5. 作成時刻によるフィルタリング
素晴らしい効果がありました。7,000 件超あったイベントが 93 件に絞り込まれています。
フィルターの作成手順は、次のとおりです。
- メニュー・バーで「View」を選択します。
-
「Add and Remove Filters」を選択します。
- 熟練のユーザーであれば、「Add and Remove Filters」ダイアログの「New Filter」ボタンを使ってルールを直接指定することができます。初級ユーザーの場合は「Rule Builder」を利用できます。Rule Builder は、本格的なルール作成ツールではなく、XPath に不慣れなユーザーもフィルターを手早く作成できるように機能を簡素化したツールです。
- 「Property Name」フィールドのプルダウン・メニューで、目的とするフィルターに相応しい Common Base Event プロパティーを選択します。
- 同様の手順で、「Relational Operator」と「Value」を指定します。さらに複雑なフィルタリング条件を指定する場合は、「Boolean Operator」フィールドを使用します。
フィルタリング条件を入力すると、XPath 式を用いたフィルタリング・ステートメントが生成されることがわかります。
次に、問題のあるイベントを迅速に視覚化する方法を説明します。
Viewer のハイライト機能
図 6 は、Viewer のハイライト機能を表しています。
図 6. 強調色によるハイライト
興味あるイベントをさらに見やすく強調するには、Viewer のハイライト機能を使用して、ユーザー定義の単純なシンプトン・ルールに基づきイベントを色分けして表示することができます。ハイライトのルールは、一般的に技術顧問 (SME) などの製品知識を持つ人が指定しますが、一般のユーザーも指定することができます。
独自のハイライトの定義 (単純なシンプトン・ルール) も、次のようなわかりやすい手順で行うことができます。
- メニュー・バーで「View」を選択します。
-
「Add and Remove Highlighters」を選択します。
- 熟練のユーザーであれば、「Add and Remove Highlighters」ダイアログの「New Highlighter」ボタンを使ってルールを直接指定することができます。初級ユーザーの場合は「Rule Builder」を利用できます。
- 「Property Name」フィールドのプルダウン・メニューで、目的とするフィルターとして適当な Common Base Event プロパティーを選択します。
- 同様の手順で、「Relational Operator」と「Value」を指定します。さらに複雑なフィルタリング条件を指定する場合は、「Boolean Operator」フィールドを使用します。
フィルタリング条件を入力すると、XPath 式を用いたフィルタリング・ステートメントが生成されることがわかります。
次に、問題について説明します。
単純な XPath Rule Builder
単純な XPath Rule Builder (図 7) は、強力な作成ダイアログを備えていますが、熟練ユーザーの場合は完全な XPath 構文を使用して表示することも可能です。Rule Builder は、本格的なルール作成ツールではなく、XPath に不慣れなユーザーもフィルターを手早く作成できるように機能を簡素化したツールです。
図 7. XPath Rule Builder
図 8 は、XPath Rule Builder の「Event Property」、「Relational Operator」、および「Boolean Operator」のプルダウン・メニューです。
図 8. XPath Rule Builder によるXpath Rule作成方法
それでは、潜在的イベントがハイライト機能により定義されているシンプトンにおいてどのような役割を果たしているかを確認します。
ハイライト・ルールで定義されているシンプトン
図 9 は、ハイライト・ルールにより定義されているシンプトンにおけるすべての潜在的イベント、およびほぼ同時刻に発生するその他のイベントを示しています。
図 9. 関連が疑われるイベントの概観
次の点に注意してください。
- 「Result/Summary」エリアで各イベントをクリックすると、「Event Detail Area」に詳細が表示されます。
- 強調表示されているイベントにカーソルを合わせると、ツールチップを見ることができます。このツールチップには、その色に対応するルールによって特定されたシンプトンの説明が表示されます。
以下は、この機能についての考察です。番号は、図中に青い丸印で示された番号に対応しています。
- イベント 1 は、アプリケーションの PDWebApp が起動したことを示しています。(ほかにも緑色で強調表示されたイベントがありますが、いずれもアプリケーションが起動したことを示しています)。
- イベント 2 は、アプリケーションの障害が始まったことを示しています。アプリケーションは 7 回にわたって回復を試みたようです。
- イベント 3 は、アプリケーションの問題発生とほぼ同時刻に発生したその他のイベントです。特に注目される点として、DB2 データベースが停止しています (自然に停止した可能性もあります)。
- イベント 4 は、WebSphere Application Server と DB2 間で通信エラーが生じたことを示しています。
- イベント 5 は、WebSphere Application Server と DB2 間で「致命的な」通信エラーが生じたことを示しています。
一連のイベントを分析すると、データベースが誤って停止されたことが問題の原因になっているものと考えられます。さらに詳細な分析が必要な場合は、これらのイベントを選択してファイルに保存することができます。IBM Autonomic Log and Trace Analyzer for Eclipse (LTA for Eclipse) などのツールでは、このファイルを使用して詳細な相関分析を行うことができます。
対象のイベントを保存するには、次の手順に従います。
- イベントを選択します。
- メニュー・バーで「Save selected events」を選択します。
- 「Save」ダイアログで、ファイル名と保存先を選択します。
強調表示イベント・ビューの切り出しや様々な視点からの分析
強調表示機能では、ビューの切り出しや様々な視点からの分析を実行して、無関係のイベントを除外して目的のイベントだけを表示することにも柔軟に対応することができます (図 10 を参照)。
図 10. 無関係のイベントの除外
図 11 は、以下の操作でさらに切り分けを行い、強調表示されているイベントのみを表示させた例です。
- メニュー・バーで「View」を選択
-
「Show Highlighted events」を選択
図 11. 不要なイベントのさらなる切り分け
これにより、7,207 件あったイベントが 16 件に絞り込まれ、はるかに管理しやすくなりました。
シンプトン・カタログ準拠フォーマットのインポート
図 12 は、Symptom Catalogs 2.0 に準拠したフォーマットをインポートする際に使用するダイアログを示しています。
図 12. Symptom Catalogs 2.0 準拠フォーマットのインポート
シンプトン・カタログは、既知の FTP/HTTP サイト、その他の既知の IBM のシンプトン・カタログ (WebSphere、DB2、HTTP サーバーなど)、およびローカル・マシン (カスタム・カタログ/ユーザーが作成したカタログ) からインポート可能です。また、必要に応じて更新を行ったり、検索順序を整理したりすることもできます。
シンプトン・カタログに対するイベントの分析と視覚化
図 13 から 図 15 は、シンプトン・カタログに対するイベントの分析と視覚化について示しています。図13 では、任意のイベントを選んで右クリックするか、またはメニュー・バーの「View」から適切な分析機能を選択できます。
図 13. イベントの分析
図 14 は、分析のためのイベントの関連付け、視覚化を行う方法を示しています。
図 14. イベントの関連付けと視覚化
さらに詳細なヘルプが必要であれば (LTA for Eclipse がインストールされている場合は)、必要に応じて、選択したイベントを送信して詳細な分析を行うことができます。
図 15. 詳細な分析のためのイベントの送信
トラブルシューティング
LTA-JD に関して困ったことがある場合にはどうすればよいでしょう。記事には、そのためのヒントも含まれています。
もっとも役立つリソースは、「インストール・ガイド」とオンライン・ヘルプです。また、図 16 に示されているトラブルシューティングのためのロギング構成の選択とダイアログもご確認ください。
図 16. トラブルシューティングのためのロギング構成
また、図 17 は、メモリー・モニターの選択とダイアログを示しています。
図 17. トラブルシューティングのためのメモリー・モニター
LTA-JD は、内部エラーや例外ログを分析する目的でも使用できることを覚えておいてください。
パフォーマンス向上のためのヒント
このセクションは、説明を簡潔にまとめます。このツールのパフォーマンスを向上させ、より良い結果を得るための最良の方法は次のとおりです。
- フィルターの精度を高める
- JVM ヒープ・サイズを増加させる
- IBM JDK 1.5 を使用する (約 50 % のパフォーマンス向上が見込まれます)
まとめ
次回の記事では、LTA-JD の IBM Tivoli Monitoring Events Tool ビューについて解説します。ITM と LTA がどのように統合されているのか、ツールのセットアップ方法、およびツールを有効活用するためのカスタマイズ方法について説明します。
参考文献 学ぶために
製品や技術を入手するために
議論するために
著者について  | 
| | Abdi Salahshour は IBM Autonomic Computing Technology and Development のシニア・ソフトウェア・エンジニアであり、問題判別のアーキテクトやMaster Inventor でもあります。現在は Plug and Manage アーキテクチャーのアーキテクトとして活躍しています。1982年に IBM に入社して以来、データベース診断ツールの設計開発からシステム管理自己修復アーキテクチャー、そして異種分散環境でのイネーブルメントまでさまざまな職務を経験してきました。彼は IBM Problem Determination Council のメンバーで、IBM Common Base Event 仕様の作成にも参加しています。また、Generic Log Adapter の主任設計者およびインプリメンターの一員、Log and Trace Analyzer for Java Desktop のアーキテクト兼設計者でもあります。 |
| | | 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 人でもあります。 |
記事の評価
| 
