レベル: 中級 Bob Moore (remoore@us.ibm.com), Advisory Software Engineer, FIT Team, IBM China Development Lab
2007年 10月 30日 IBM® Support Assistant Lite ツールの重要な拡張機能である、拡張分析について見てゆきましょう。拡張分析機能の動作を探り、独自のコレクションに対する拡張分析の設定方法を、チェックリストを使用して進めます。
はじめに
この記事では、IBM Support Assistant Lite ツールが初めてリリースされて以来、分析機能の中で最も重要な拡張機能である拡張分析について説明します。この拡張機能により、分析レポートの内容は、コレクション動作中にターゲット・システム上で収集された情報に限定される必要が無くなります。ターゲット・システム上で収集された情報に加えて、分析レポートには、インターネット上に公開されている様々なタイプの情報への URL ハイパーリンクや、分析対象のログ・ファイルで報告されている状況についての情報も収録されるようになります。この記事では、拡張分析機能の動作を中心に説明し、独自のコレクションに対する拡張分析の設定方法に関するチェックリストを提供します。
 | |
この記事は、IBM Support Assistant Lite ツールに関するシリーズの 6 回目に当たります。2007 年 10 月版がリリースされる以前、このツールは自動問題判別（AutoPD）ツールと呼ばれていました。このシリーズの他の developerWorks 記事は以下の通りです:
-
第 1 回 ツールの概要について説明します。
-
第 2 回 製品と問題シナリオの追加に対応したツールの拡張方法を示します。
-
第 3 回 ログ・ファイル分析の自動化について説明します。
-
第 4 回 分析についての説明を、Common Base Event などの XML 形式のログ・ファイルにまで拡張します。
-
第 5 回 コレクション・スクリプト内の複数のポイントで分析が実行され、最後に結果を 1 つの分析レポートにまとめる方法について説明します。
|
|
拡張分析は、これまでに説明した基本分析機能および増分分析機能に基づいているため、独自のコレクション・スクリプトに拡張分析を追加したい場合には、これら 2 つの機能について理解している必要があります。したがって、拡張分析の実装を目的としている場合、この記事以外に、本シリーズの第 3 回および第 5 回を参照するとよいでしょう。
2007 年 10 月版のツールでは、拡張分析機能は、第 3 回で説明した非 XML ログ・ファイルに対してのみ利用可能です。ただし、今後の拡張で、第 4 回で説明した XML 形式のログ・ファイルに対しても利用可能となるかもしれません。
自動問題判別（AutoPD）ツールは、その類似性の高さから、IBM Support Assistant ファミリーに採用され、名前も IBM Support Assistant Lite に変更されました。この記事で説明する機能は、いずれの製品ファミリーにおいても利用可能です。これらの機能の他に、IBM Support Assistant ツールには、拡張検索機能や、無料のトラブル・シューティング・ツール等が追加されています。
拡張分析の概要
IBM Support Assistant Lite ツールの拡張分析機能の主要な目的は、分析レポートを関連性のあるログ・レコードの一覧を表すものから、ログに含まれている関連性のあるコンテンツの要約と、そのコンテンツに関する詳細情報へのリンクに変更することです。
図 1 は、AutoPD ツールのバージョン 1.2.3 によって生成された分析レポートであり、関連性があると見なされたログ・レコードが一覧表示されているにすぎません。これらのログ・レコードでは、タイム・スタンプやエラー・コードまたは警告コードなどの特定のフィールドが個別に表示され、分かりやすくなっています。しかし、ログ・レコードに含まれている情報以外の内容は示されていません。最新リリースのツールでは、ログ・レコードの内容を一覧表示する機能も引き続きサポートされており、実際に WebSphere® Portalの ConfigTrace.log などの特定のログには非常に役に立ちます。しかし、拡張分析により、WebSphere Portalの SystemOut.log や SystemErr.log などのログの分析レポートは、大きく改善されました。
図 1. ログ・ファイルの関連性のあるログ・レコードの一覧
図 1 を、IBM Support Assistant Lite ツールのバージョン 1.2.4 によって生成された図 2 と比べてみてください。分析レポートでは、関連性のあるログ・レコードが個別に一覧表示されるのに代わって、ログ内のすべての関連性のあるレコードが要約されて表示されています。レポートには、個々のレコードについて、レコード内のエラー・コードを使用して組み立てられたURL リンクが含まれています。 この記事では、これらの URL がどのようにして組み立てられるのか、および、ツールに含まれているXML 文書を編集することによりURL フォーマットを調節する方法について詳細に検証します。
図 2. 関連性のあるレコードの要約と詳細情報へのリンクの表示
図 2 に、図 1 の SystemOut-00.log で使用されたのと同じログ・ファイルの分析結果の一部を示します。 それぞれの結果には、以下のフィールドが示されています。
| |
なぜ WebSphere Portalなのか？
拡張分析機能は全ての製品でスクリプト作成時に利用可能ですが、この記事の例はすべて WebSphere Portalのコレクションが引用されています。 なぜでしょうか？ これには 2 つの大きな理由があります。 まず、現時点ではWebSphere Portalのコレクションの拡張分析の完成度が最も高いためです。 第 2 に、参考文献に記載したダウンロード・サイトからダウンロード可能なツールには、WebSphere Portal向けに開発されたコレクション・スクリプトと XML 文書が含まれています。 したがって、これらのスクリプトとXML文書を独自の拡張分析コンテンツを作成する際の出発点として使用することができます。
|
|
- ログ・ファイルに含まれるエラー・コード。 このツールのマッチング・アルゴリズムでは、特定のログ・レコードで最初に現れるエラー・コードを常に利用します。 このエラー・コードには、コードに関連した製品のオンライン文書へのハイパーリンクが含まれています。 オンライン文書には、通常はオンライン・メッセージ・カタログなどが収録されています。
- 完全なログ・レコードへのリンク。 このリンクは、図 1 の右側の列の代わりとなるものです。分析レポートでは、エラー・コードを含むログ・レコードの全ての内容が表示されています。
- このエラー・コードを含んでいるログ・ファイル内で見つかったログ・レコードの数と、最も古いエラー・コードと最も新しいエラー・コードのタイム・スタンプ。ログ・レコードにタイム・スタンプが設定されていないログ・ファイルでは、タイム・スタンプは省略されます。
- エラー・コードに関連した IBM サポート技術情報へのリンク。
- エラー・コードに関連した IBM プログラム診断依頼書（APAR）へのリンク。
最後に示した 2 つのリンクは、拡張分析機能のカスタマイズ可能な要素であり、この記事でも詳細に説明していきます。
分析機能の構成
拡張分析を構成するための最初の手順は、基本分析を構成することです。 この作業の概略は第 3 回で説明したものと同じですが、詳細な点がいくつか異なっています。 第 3 回で詳細に説明しているとおり、基本分析の構成方法は 2 つの段階から成ります。1つめは、対象となる製品でサポートされる、製品バージョン、ログ・ファイル、および問題のタイプの各組み合わせに対応した <analysisProfile> 要素を含むパターン文書を作成することです。2つめは、コレクション・スクリプト内で、パターン文書に含まれている <analysisProfile> 要素の1つをパラメータとして指定して分析処理を呼び出すことです。 これらのパラメータは、第 3 回では「スコーピング変数」と呼んでいます。
第 3 回から変更されたのは、分析処理を呼び出す際にスコーピング変数を指定するカスタム Ant タスクです。 これまで <infocollect> タスクを使用してスコーピング変数を指定していた、第 3 回のリスト 1 を、次に示すリスト 1 と比べてみてください。ここでは、拡張分析機能の呼び出しに使用される <analyze_files_v2> タスクを使用して、同じ内容が実行されています。 増分分析機能に関連した新しい属性がいくつかありますが（第 5 回で詳細に説明）、問題のタイプ、製品名、製品バージョン、ログ・ファイル・セットに対応する 4 つのスコーピング変数が、<infocollect> タスクの場合と同じように指定されています。
リスト 1. <analyze_files_v2> タスク
<analyze_files_v2
problem="${collect_wps_information_common_ProblemType}"
patternFile=
"${portal.shared.targets.bundle.basedir}/properties/wps/${wpsCommonPatternFile}"
productname="${wps.product.name}"
productversion="${wps.product.version}"
includeType="link"
fragmentTitle="Basic WebSphere Portal Analysis"
timeout="${infocollector.timeout}">
<autopdfileset filesetName="wpslog" filesetDir="${portal.latest.file}"/>
<autopdfileset filesetName="tracelog" filesetDir="${trace.log.file}"/>
<autopdfileset filesetName="tracelogtimestamped"
filesetDir="${trace.log.latest.timestamped.version}"/>
<autopdfileset filesetName="systemoutlog" filesetDir="${systemout.log.file}"/>
<autopdfileset filesetName="systemerrlog" filesetDir="${systemerr.log.file}"/>
</analyze_files_v2>
|
リスト 1 を見ると、パターン文書を指定する方法が少し変更されているのがわかります。 この変更は必須ではなく、また、ベスト・プラクティスのレベルのものではありません。 しかし、プラクティスとして参考にするとよいでしょう。 これまでは、分析作業に使用するパターン・ファイルは、分析処理の呼び出しに使用されるカスタム Ant タスクでファイル名を使用して明示的に指定されていました。 例えば、第 5 回の図 4 から抜粋した以下の内容を見てください。
<analyze_files problem="${collect_wps_information_common_ProblemType}"
patternFile=
"${portal.shared.targets.bundle.basedir}/properties/wps/pattern_template.xml"
...
|
この場合、パターン・ファイル /properties/wps/pattern_template.xml は、ファイル名で明示的に指定されています。 これをリスト 1 から抜粋した次の内容と比べてみてください。
<analyze_files_v2 problem="${collect_wps_information_common_ProblemType}"
patternFile=
"${portal.shared.targets.bundle.basedir}/properties/wps/${wpsCommonPatternFile}"
...
|
ここでは、使用するパターン・ファイルが Ant のプロパティ値によって指定されています。 参照されている wpsCommonPatternFile プロパティは、ツールに含まれている properties/wps/portal-script-initialization.properties ファイルで以下のように設定されています。
wpsCommonPatternFile=pattern_template_E.xml |
この方法を用いる理由は、各種の異なるパターン・ファイルを切り替えやすくするためです。 拡張分析では、パターン・ファイルは以前よりもかなり柔軟になっています。 分析の動作を変更するために、わざわざパターン・ファイルを編集しなくても、手持ちのコレクション・スクリプトに複数のパターン・ファイルを用意して、この Ant のプロパティ値のみを変更するだけで、パターン・ファイルを切り替えることができます。
この例にあるように、WebSphere Portalのスクリプトには、pattern_template_E.xml、pattern_template_EW.xml、pattern_template_EX.xml といった複数のパターン・ファイルが含まれています。 これらのパターン・ファイルの違いは、それぞれが関連性を持つログ・レコードにあります。 pattern_template_E.xml の場合、関連性のあるログ・レコードは、エラー・メッセージ（「E」で終わるメッセージ ID を含むメッセージ）が含まれるレコードです。 pattern_template_EW.xml の場合、関連性のあるログ・レコードは、エラー・メッセージまたは警告メッセージ（「E」または「W」で終わるメッセージ ID を含むメッセージ）のいずれかが含まれるレコードです。 pattern_template_EX.xml の場合、関連性のあるログ・レコードは、エラー・メッセージまたは例外メッセージ（「E」または「X」で終わるメッセージ ID を含むメッセージ）が含まれるレコードです。 この場合、どのパターン・ファイルを使用するかの決定は、分析レポートにエラー以外に警告または例外を含めた場合、問題の診断の全体的なプロセスが簡単になるか、難しくなるかという判断如何になります。すなわち、主要な警告または例外を見逃さないようにするのか、警告を含めることでレポートが見難くなり、エラーが見つかりにくくなるのかどうかということです。 このようなパターン・ファイルの選択の影響を、図 1 と図 2 に示しています。図 1 では、レポート生成時に分析処理で警告とエラーの両方を選択しているのに対し、図 2 ではエラーのみを選択しています。
拡張分析拡張機能の指定
ログ・ファイルに対して拡張分析を有効にするためには、1 つまたは複数の拡張機能を指定して、分析処理に必要な構成情報を追加する必要があります。 拡張分析機能の XML 構成方法は、以下の 2 つからなります。
- パターン文書内の
<fileset> 要素には、1 つまたは複数の <additionalProcessing> 子要素が含まれ、当該ファイルセットに含まれるログ・ファイルに対して呼び出す必要のある、特定のタイプの追加処理を指定します。 これらの <additionalProcessing> 要素には、その特定のファイルセットに固有の構成値が含まれます。
-
<additionalProcessing> 要素は、それぞれ file 属性を使用して、拡張分析に関する詳細な情報を収めた 2 番目の XML 文書を指定します。 この 2 番目の文書の構成値は、より汎用的で、複数のファイルセットの拡張分析に使用されます。
リスト 2 に、図 2 のような結果を得るために拡張分析を構成したときの <fileset> 要素を例として示します。この要素は、名前が SystemOut で始まるログ・ファイルに対する処理命令となっています。図 2 の SystemOut-00.log に使用されるものです。 他の <fileset> 要素は、他の名前のログ・ファイルに対する処理命令となっています。
リスト 2. <additionalProcessing> 拡張機能を含む <fileset> 要素
<fileset name="systemoutlog" value="SystemOut.*\.log">
<delimiterid id="delimiter4"/>
<additionalProcessing
timeStampPattern="([0-9]{1,2}/[0-9]{1,2}/[0-9]{1,2}\ [0-9]{1,2}[:.]
[0-9]{1,2}[:.][0-9]{1,2}:[0-9]{1,3}\ [A-Z]{1,4})"
type="search"
indicatorPattern="[A-Z]{4,5}[0-9]{1,4}E"
searchStringPattern="([A-Z]{4,5}[0-9]{1,4}E)"
file="properties/wps/analysis/searchUrlSpecification-Portal_v6x.xml"/>
</fileset>
|
次に、この <additionalProcessing> 要素の属性を 1 つずつ見てみましょう。
- timeStampPattern
指定されたエラー ID を含むログ・レコードのうち、最も古いタイムスタンプを持つものと最も新しいタイムスタンプを持つものを表示するために、ログ・ファイルに含まれるタイムスタンプのエンコード方式をツールに指示する必要があります。 タイムスタンプが新しいログ・レコードの開始位置を指定するための区切り文字として機能している場合、一般的にタイムスタンプのエンコード方式は、ファイルセットに含まれる delimiterid 属性によって参照される <delimiter> 要素で定義されているものと同じパターンになります。 ただし、これら2 つの値は違っていてもかまいません。 ログ・レコードにタイムスタンプが含まれていないログ・ファイルもあるため、この属性はオプションです。 この場合、レポートには一番新しいログ・レコードへのハイパーリンクが示されますが、最も古いタイムスタンプを持つものと最も新しいタイムスタンプを持つものは示されません。
- type
この属性は、ファイルセットに含まれるログ・ファイルに対して実行される拡張分析のタイプを指定します。 ツールでは、現時点では search のみがサポートされています。
- indicatorPattern
この属性は、関連性のあるログ・レコードを定義するための正規表現パターンです。 このパターンにマッチするすべてのログ・レコードは、searchStringPattern 属性で定義される正規表現によって制御される、次の処理ステップに進みます。 このパターンにマッチしなかったログ・レコードは、以降の処理が行われません。pattern_template.E.xml、pattern_template_EW.xml、pattern_template_EX.xml の3つのパターン・ファイル間に違いが現れるのは、この箇所です。3つのパターン・ファイルでは、この属性にそれぞれ、[A-Z]{4,5}[0-9]{1,4}E、[A-Z]{4,5}[0-9]{1,4}[EW]、[A-Z]{4,5}[0-9]{1,4}[EX] という値が指定されています。
- searchStringPattern
このパターンは、インディケータ・パターンに一致したログ・レコードに対して適用されます。 ログ・レコードがこのパターンにマッチした場合、レコード内で最初にパターンに一致する部分文字列が分析レポートで使用されます。 リスト 2 の例では、indicatorPattern 属性と searchStringPattern 属性の両方が同じ正規表現パターンを含んでいます（しかしながら構文上は異なっています。searchStringPattern 属性では基本パターンが括弧で囲まれ、indicatorPattern 属性では括弧で囲まれていません）。 他の例の場合には、2 つの属性は異なる値となるでしょう。 ログ・レコードには、エラーを示すハイレベルの指標が最初に含まれている場合があり、エラーの詳細は、ログ・レコードの後の方に現れるより細分化された別のコードにより表されます。 このような場合、ハイレベルの指標部分のマッチングには indicatorPattern 属性が使用され、ログ・レコードで報告された特定の状況を表す細分化されたコードのマッチングには searchStringPattern 属性が使用されます。
- file
この属性は、SystemOut.log の拡張分析の構成に使用されるXML 文書を示します。
ツールはログ・ファイルに対して拡張分析を実施した後、<additionalProcessing> 要素で指定された構成情報を、参照されている文書で指定された構成情報に結合します。 特定のファイルセットに固有の（固有と思われる）値は、<additionalProcessing> 要素に属性値として示されます。 複数のファイルセットに適用される値は、参照されている文書内に示されます。
拡張機能固有の構成文書
引き続き 図 2 に示した例を使用して、<additionalProcessing> 要素の file 属性で参照される文書を検証します。 この同じ文書は、複数のファイルセット（SystemOut.log、SystemErr.log、wps_<timestamp>.log）で使用されています。これは、この文書には特定のログ・ファイルまたはログ・ファイル形式に固有の情報が含まれていないためです。
リスト 3 に、リスト 2 に示されている file 属性で参照されているsearchUrlSpecification-Portal_v6x.xml 文書の内容をすべて示します。
リスト 3. 拡張分析のための追加情報を含む XML 文書
?xml version="1.0" encoding="UTF-8"?>
<specificationList xmlns="http://www.ibm.com/autopd/SearchUrlSpec"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.ibm.com/autopd/SearchUrlSpec
../../analysis/searchUrlSpecification.xsd"
productName="IBM WebSphere Portal Server">
<searchUrlSpecification
hostName="www.ibm.com"
hostPage="support/search.wss"
presentationString="Technotes">
<trailingTerm termType="rs" termValue="688"/>
<trailingTerm termType="tc" termValue="SSHRKX"/>
<trailingTerm termType="word" termValue="aw"/>
<trailingTerm termType="wfield" termValue="!!SearchString!!"/>
<trailingTerm termType="nw" termValue=""/>
<trailingTerm termType="apar" termValue="exclude"/>
<trailingTerm termType="atrwcs" termValue="on"/>
<trailingTerm termType="rankprofile" termValue="8"/>
</searchUrlSpecification>
<searchUrlSpecification
hostName="www-111.ibm.com"
hostPage="search/SupportSearchWeb/SupportSearch"
presentationString="Known problems (APARs)">
<trailingTerm termType="action" termValue="search" />
<trailingTerm termType="pageCode" termValue="MPS" />
<trailingTerm termType="rsid" termValue="203" />
<trailingTerm termType="products" termValue="" />
<trailingTerm termType="sortBy" termValue="3" />
<trailingTerm termType="pageNumber" termValue="1"/>
<trailingTerm termType="searchTerms" termValue="!!SearchString!!"/>
<trailingTerm termType="searchLimitsFilter" termValue="DB550"/>
<trailingTerm termType="sortByFilter" termValue="3"/>
<trailingTerm termType="setFilter.x" termValue="13"/>
<trailingTerm termType="setFilter.y" termValue="13"/>
<trailingTerm termType="setFilter" termValue="submit"/>
</searchUrlSpecification>
</specificationList>
|
この文書の内容を図 2 と比べてみると、処理の内容が簡単にわかります。最初の <searchUrlSpecification> 要素は、レポートにIBM サポート技術情報を含む行を作成するための命令となっています。同様に、2 番目の <searchUrlSpecification> 要素は、IBM プログラム診断依頼書（APAR）を含む行を作成するための命令となっています。いずれの場合も、命令のほとんどは、該当するテキストにハイパーリンクするために使用される検索用 URL の具体的な組み立て方法を指定しています。特殊な文字列 !!SearchString!! は、検索に使用するためのエラー・コードを挿入する箇所をツールに知らせます。リスト4に示されているように、レポートに含まれている最初のIBM サポート技術情報の行にセットされている検索用 URLの値を調べれば、ツールが <trailingTerm> 要素の内容をどのように結合するのかがわかります。
リスト 4. 最初の IBM サポート技術情報に対する検索用 URL
http://www.ibm.com/support/search.wss?
rs=688&
tc=SSHRKX&
word=aw&
wfield=SECJ0369E&
nw=&
apar=exclude&
atrwcs=on&
rankprofile=8
|
検索スコープや検索結果の表示内容は、一連の条件を変更することにより簡単に変更することができます。 また、ホスト名またはホスト上のページを変更することで、検索に使用する検索エンジンをまったく別のものに切り替えることも可能です。 XML スキーマ・ファイル /properties/analysis/searchUrlSpecification.xsd はツールに含まれているため、独自に作成した XML文書が有効かどうかを検証することもできます。
メッセージ・カタログの検索
図 2 に示すログ・ファイルの各エントリーの最初の行には、ログ・レコードから抽出されたエラー・コードが含まれています。 ハイパーリンクをクリックすると、メッセージ・カタログなどを含む IBM 製品の文書に移動します。そこには、エラー・コードのメッセージ接頭辞に対する個々のエントリーが収録されています。 このハイパーリンクの形式は、現在ツール内にハードコードされているため、XML を使用して明示的に構成する必要はありません。 例えば、図 2 で最初に示されているエラー・コード（SECJ0369E）に対するハイパーリンクは、http://www.google.com/search?q=+SECJ0369E+site%3Aboulder.ibm.com&btnG=Search です。 これは、コロラド州ボールダーの IBM 製品サイトに対するエラー・コードを使用したGoogle サーチです。
このメッセージ・カタログの検索方法は、旧バージョンのツールで使用されていた限定的な検索機能を置き換えるものです。 以前の機能では、特定のメッセージ・カタログのコピーに対するメッセージ・エントリーへのローカル・リンクが示されており、それらは、ツールをターゲット・システム上に展開する際にツールのディレクトリ構造内に置かれていました。そのため、この機能は WebSphere Portalの特定の 2 つのバージョンに限定されたものでした。 新しいメッセージ・カタログ検索機能では、いくつかの点で、元の機能よりも改善されていますが、まだ不備な点も残されています。
新しいメッセージ・カタログ検索機能には、次のような長所があります。
- WebSphere Portalの限定された2つのバージョンの特定のエラー・コードだけではなく、すべての IBM ソフトウェア製品のすべてのエラー・コードに対して機能します。
- メッセージ・カタログのみでなく、エラー・コードに関連した他の製品文書にもリンクすることができます。
- ツールが最終的にリリースされた時点で取得された文書のスナップショットのみでなく、そのエラー・コードに対するIBM ボールダーの Web サイト上にある最新の文書にリンクすることができます。
新しいメッセージ・カタログ検索機能には、次のような短所もあります。
- 分析レポートを表示する際に、インターネット接続がアクティブになっている必要があります。
- オンライン・メッセージ・カタログに制限があるため、カタログ内の当該メッセージ・コードの箇所が表示されるのではなく、当該メッセージ・コードを含むカタログの先頭が常に表示されます。
拡張分析機能のスケーラビリティ
IBM Support Assistant Lite ツールの拡張分析機能を設計する際に設計者が注意しなければならない問題の 1 つに、スケーラビリティがあります。 スケーラビリティの問題により、設計者は、ログ・ファイルに報告された問題に対する詳細情報を探すという課題に対する、ある意味で最も自然なアプローチを断念せざるを得ませんでした。それは、問題のタイプごとに独立した正規表現パターンを用意し、現在のログ・ファイルで該当する問題のタイプであることが検出された場合に、その問題のタイプにふさわしい情報へのリンクを提供するということです。
このアプローチには、問題のタイプ別に異なる正規表現パターンが必要になるという欠点があります。10 種類の問題のタイプに対して 10 個のパターンが、100 種類の問題のタイプに対して 100 個のパターンが必要になります。 このようなパターン数の正比例的な増加以外に、1 つのログ・ファイルに含まれるログ・レコードの数や、これらのログ・レコードとパターンが一致する可能性がまったく未定であるという事実、また、正規表現処理に特有のパフォーマンス上のオーバヘッドの問題などを考えると、設計者は、このアプローチはうまくいかないことにすぐに気付きました。
代わりに設計者が採用したのは、1 つの正規表現パターンを使って、ログに報告されているすべての問題を特定するアプローチです。このアプローチでは、ログ・レコード当たりの正規表現処理が 1 回のみであり（indicatorPattern の値に基づいてログ・レコードが関連性のあるものかどうかを事前審査するため）、この後、数が絞り込まれた、事前審査されたログ・レコードに対して 2 回目の操作が適用され、searchStringPattern の値とマッチするかどうかが確認されます。 このアプローチを使用することで、ログ・ファイルの拡張分析は、以前からある基本分析に比べても、それほど時間がかからないものとなりました。
独自のコレクションで拡張分析機能を使用するためのチェックリスト
最後に、独自のコレクションに対して拡張分析を追加する際に従う必要がある手順のチェックリストについて説明します。 このリストを見てゆく際には、WebSphere Portalのコレクションで拡張分析機能を構成するために必要なXML 文書やコレクション・スクリプト、その他関連するファイルを目の前に用意しておくとよいでしょう。WebSphere Portal向け IBM Support Assistant Lite ツールでは、これらのファイルは以下に示す 3 つのサブディレクトリに含まれています。
- /properties/wps
- /properties/wps/analysis
- /scripts/wps
IBM Support Assistant Lite ツールでは、これらのサブディレクトリはすべて WebSphere Portal用プラグインに含まれています。 これらのファイルは直接変更しないほうが良いでしょう（WebSphere Portalのコレクションの動作が変更されてしまうためです）。 代わりに、独自のプラグインを用意して内容をコピーすることで、自分独自の構成を用意する際のスタート・ポイントとして使用するとよいでしょう。
- この記事と、このシリーズの第 3 回および第 5 回にある説明に従って、基本分析を行うための独自のコレクション・スクリプトとパターン・ファイルを用意します。用意するスクリプトでは、分析タスクの新しいバージョンである
<analyze_files_v2> を使用する必要があることに注意してください。
- 拡張分析を実行したい分析プロファイルに対して、各 <fileset> 要素内に
<additionalProcessing> 子要素を追加して、そのファイルセットで拡張分析を実行する方法をツールに指定します。<additionalProcessing> 要素の type 属性は search に設定し、正規表現パターンを使用した 3 つの属性の値を、ファイルセットに含まれるログ・ファイルの内容に対応させる必要があります。 最後に、file属性が、同じ IBM Support Assistant プラグイン内にある文書を参照するようにセットし、プラグインに独自のパターン・ファイルが含まれるようにします。 すべての <additionalProcessing> 要素が、同じ拡張文書を示すのが一般的ですが、必要であれば、それぞれ異なる拡張文書を示すことも可能です。
- WebSphere Portal用の文書である/properties/wps/analysis/searchUrlSpecification-Portal_v5x.xml または /properties/wps/analysis/searchUrlSpecification-Portal_v6x.xmlのいずれかを利用して独自の拡張文書を作成します。 独自に作成した文書は、ツールに付属している/properties/analysis/searchUrlSpecification.xsdスキーマを使用して検証できます。 IBM Support Assistant 環境では、このスキーマ文書は共有要素(shared elements)プラグインに収録されています。独自の拡張文書の内容を用いて、検索用 URL のフィールドをどのように組み合わせると希望する結果が得られるかを、いくらか実験してみる必要があります。
まとめ
IBM Support Assistant Lite v 1.2.4 でリリースされた拡張分析機能により、ツールを使用して以前よりも有益な情報を提供できるようになりました。 ターゲット・システム上で発生したエラーの情報を含んだIBM 製品およびサポートのページへのハイパーリンクを通じて、現在の問題に対する解決策を見つけるために必要な情報を、カスタマー管理者と IBM サポート・エンジニアの両方に対して提供します。
拡張分析機能の設計と実装は、ツールが元々持っていた分析の実装に基づいています。
それは、XML 文書を編集するだけで簡単に構成できる非常に汎用的な方法です。 このため、コレクション・スクリプトの開発者は、手軽に拡張分析機能を活用することができます。
参考文献
著者について | 
| | Bob Moore は、ノースキャロライナ州 Research Triangle Park にある IBM の Software Group Advanced Design and Technology チームの Advisory Software Engineer です。1977年に Duke University にて哲学の博士号を取得しています。1983年に IBM に入社して以来、SNA/Management Services や CMIP、SNMP、DMTF CIM など、ネットワークやシステム管理に関する様々なアーキテクチャーや標準に携わってきました。 |
記事の評価
| 
