• 検索結果がありません。

First Failure Data Capture (FFDC)

ドキュメント内 IBM Workload SchedulernguVeBOEKCh (ページ 78-121)

製品コンポーネントが自動的にデータ・キャプチャー・ツールを使用して、製品の ログ・ファイル、トレース・ファイル、および構成ファイルの First Failure Data

Capture を作成する仕組みについて説明します。

トラブルシューティングを支援するために、製品のいくつかのモジュールでは、障 害発生時に First Failure Data Capture を作成することができます。この機能では、

データ・キャプチャー・ツール tws_inst_pull_info ( 51 ページの『データ・キャ プチャー・ユーティリティー』を参照) を使用して、ログ、トレース、構成ファイ ル、およびデータベース・コンテンツ (データベースが DB2 上で実行されている場 合) をコピーし、IBM ソフトウェア・サポートに送るための圧縮ファイルを作成す ることができます。

このツールは、以下の状況で実行されます。

jobman に障害が起きたとき

batchman が jobman の障害を検出すると、スクリプトを実行し、その出力 を <TWA_home>/stdlist/yyyy.mm.dd/collector/JOBMAN に格納します。

batchman に障害が起きたとき

mailman が batchman の障害を検出すると、スクリプトを実行し、その出 力を <TWA_home>/stdlist/yyyy.mm.dd/collector/BATCHMAN に格納します。

mailman に障害が起きたとき

mailman がそれ自身にターミナル・エラーによる障害が起きたことを検出

すると、スクリプトを実行し、その出力を <TWA_home>/stdlist/

yyyy.mm.dd/collector/MAILMAN に格納します。プロセスのハード・ストッ プ (例えば、セグメンテーション違反) は、mailman 自身では追跡できない ことに注意してください。

netman 子プロセスが失敗したとき

netman が、自分の子プロセスの 1 つで障害が起きたことを検出すると、

スクリプトを実行し、その出力を <TWA_home>/stdlist/yyyy.mm.dd/

collector/NETMAN に格納します。

1 日に保持されるデータ収集は 1 つだけです。毎日、新しいデータ収集によって前 日の収集が上書きされます。

各ターゲット出力ディレクトリー内で、出力ファイルは /tws_info/

TWS_yyyymmdd_hhmmss ディレクトリーに格納されます。

FFDC を実行するために、tws_inst_pull_info スクリプトが、collector.sh (.cmd) というスクリプトによって実行されます。このスクリプト (<TWA_home>/TWS/bin に ある) をカスタマイズして、使用可能な任意のモジュール

(jobman、mailman、batchman、および netman) 用の tws_inst_pull_info スクリ プトに異なるパラメーターを適用することができます。

アプリケーション・サーバーのメモリー・ダンプの作成

WebSphere Application Server がハングし、IBM ソフトウェア・サポートに連絡 して支援を求めることにした場合、ハング時に取得した 1 つ以上のメモリー・ダン プを提供していただければ、問題の診断に役立ちます。次の手順を使用して、メモ リー・ダンプを作成します。

1. WebSphere Application Server 管理者としてログオンします。

2. ディレクトリー WAS_profile_path/bin に移動し、スクリプト wsadmin.sh/bat を実行して管理シェルを開きます。WAS_profile_path は、インストール時に指 定した WebSphere Application Server プロファイル・パスに相当します。デ フォルトのパスは TWA_home/WAS/TWSprofile です。

3. jvm 変数を以下のように設定します。

set jvm [$AdminControl completeObjectName type=JVM,process=<server_name>,*]

ここで、<server_name> は、WAS_profile_path/config/cells/

TWSNodeCell/nodes/TWSNode/servers ディレクトリーを調べて決定します。

コンピューター上の IBM Workload Automation の各インスタンスに対して、

<server_name> という名前のディレクトリーが 1 つ存在します。 2 つ以上のデ

ィレクトリーが存在する場合は、どのインスタンスをダンプするか決定する必要 があります。

4. 以下のようにメモリー・ダンプを実行します。

$AdminControl invoke $jvm dumpThreads

これにより、WAS_profile_path/bin ディレクトリー内に、次の名前のコア・ダ ンプが作成されます。

Windows および Linux

javacore.<yyyymmdd>.<hhmmss>.<pid>.txt (yyyy = 年、mm = 月、dd

= 日、ss = 秒、pid = プロセス ID)

UNIX javacore<pid>.<time>.txt (pid = プロセス ID、<time> = 1/1/1970 以降の秒数)

5. 手順 4 (63 ページ) を繰り返します。取得できたダンプの数が多いほど、サポ

ート・チームが使用できる情報が多くなります。

6. ダンプ、アプリケーション・サーバー・ログ・ファイル、および実行していた操 作の詳細な説明を、IBM ソフトウェア・サポートにお送りください。

4 章 エンジン用インフライト・トレース機能

IBM Workload Scheduler エンジンのトラブルシューティング用トレース機能につ いて説明します。この機能は、インフライト・トレースと呼ばれます。

本書では、バージョン 8.6 以降で Autotrace から置き換わった、IBM Workload

Scheduler サーバー・トレース機能について説明します。この機能は、IBM ソフト

ウェア・サポートが使用することを目的としていますが、IBM ソフトウェア・サポ ートから要請があった場合にお客様が使用法を理解できるよう、詳しく説明してい ます。

IBM Workload Scheduler サーバー・トレース機能 (以後、インフライト・トレー スと呼びます) は、IBM ソフトウェア・サポートが IBM Workload Scheduler の 問題を解決するために使用する機能です。最も詳細なトレースでは、すべての IBM

Workload Scheduler 機能の入り口と出口だけでなく、その他多数のイベントもト

レースできます。また、現在 CCLog 機能で発行されているすべてのログ・メッセ ージおよびトレース・メッセージが含まれます。

インフライト・トレースは、マルチ製品ツールとして作られていますが、本書で は、IBM Workload Scheduler での使用に焦点を当てています。

次のように機能します。

Existing trace calls (既存のトレース呼び出し)

インフライト・トレースでは、CCLog のログおよびトレース・メカニズム で現在も使用されている、ログおよびトレース機能を使用しています。この 機能は、8.6 より前のリリースの Autotrace 機能でも使用されていました。

Function entry and exit (機能の入り口および出口)

さらに、IBM Workload Scheduler エンジン製品のビルドでは現在、コー ドにトレース呼び出しが挿入されていて、すべての機能の入り口と出口を記 録し、各機能に、連続する数値の機能 ID を割り当てます。トレース呼び出 しは、これらの ID を使用して機能を識別します。

Building the xdb.dat symbols database (xdb.dat シンボル・データベースの作 成) 同じプロセスで、ビルドによって、各機能の名前と機能 ID を関連付ける

xdb.data シンボル・データベースが作成されます。これにより、トレース

は可能な限り最小限の情報 (機能 ID) をトレース・レコードに書き込み、

後から表示のためにそれを機能名に展開することができます。

ビルドではまた、各機能のソース・ファイルと行番号も、データベースに格 納されます。

さらに、機能を「所有」するコンポーネントの名前も格納されます。1 つの プログラムには多数のコンポーネントが含まれ、各コンポーネントには多数 の機能が含まれます。

トレースの活動化/非活動化、およびフィルター処理を管理するうえで、シ ンボル・データベースは重要です。その内容は暗号化されています。

Tracing in shared memory (共有メモリー内のトレース)

トレースは共有メモリーに書き込まれます。共有メモリーはセグメントに分 割されていて、各セグメントに書き込まれることが指定されているトレース は、エンドレス・ループで書き込まれます。最も詳細なトレース (すべての 機能のすべてのイベントをトレースする) では数分毎にループする場合があ りますが、最も単純なトレース (使用頻度の低い機能を 1 つだけトレース する) では、何カ月もループしない場合もあります。

Segments (セグメント)

任意の数のセグメントを使用することができます (各セグメントは固有の番 号により識別される)。また、各セグメントに対して、そのセグメントで使 用する共有メモリーの量を決定することができます。多数の大きなセグメン トを使用すると、より多くのメモリーが消費され、一般的な問題が発生しま す。

Programs (プログラム)

任意の数の IBM Workload Scheduler プログラムを同一セグメントに保存 するよう構成することができます。基本構成を変更することにより、どのプ ログラムをどのセグメントにトレースし、そのセグメントのトレースを有効 化するかどうかを決定します。任意の IBM Workload Scheduler プログラ ムおよびユーティリティーをトレースするように構成できます。

Basic configuration (基本構成)

基本構成は、どのセグメントのトレースを有効化するかを決定し、特定のプ ログラムのトレースを活動化するかどうかについて最初の決定を行います。

この処理は、構成ファイルをテキスト・エディターで編集して行います。変 更を有効にするためには、IBM Workload Scheduler エンジン (製品) を再 始動する必要があります。構成は、以下のセクションに分かれています。

Global (グローバル)

このセクションは、製品コードやセグメント・サイズなどの一般情 報を含むだけでなく、すべてのプログラムの「受け皿」のような役 割を果たし、個別に構成されていないプログラムのトレースもここ で構成されます。

<program>

あるプログラムを「global」セクションでトレースしない場合、固 有のプログラム・セクションを構成して、そのプログラムをどのセ グメントでトレースするかなどの基本情報を定義する必要がありま す。プログラム・セクションの情報は、そのプログラムについての み、グローバル・セクションの情報をオーバーライドします。

Activating and deactivating traces (トレースの活動化および非活動化)

有効化されているセグメントでは、特定のプログラムのトレースは、コマン ド行からオンザフライで活動化または非活動化できます。これは、これらの フラグがメモリーに保持されるためです。

Trace levels (トレース・レベル)

コード内のイベントにはトレース・レベルが割り当てられています。レベル が低いほど、イベントの頻度は大幅に増加します。レベルには、復旧不能エ ラーのみのレポートから、復旧可能エラー、警告、通知メッセージ、3 種類 のデバッグ・レベル、および、機能の入り口イベントと出口イベントまで記 録される最大レポート・レベルまでが含まれます。

トレース・レベルもまた、コマンド行を使用して、オンザフライでエンジン を再始動せずに変更できます。

Snapshots (スナップショット)

インフライト・トレースでは、プログラムまたはセグメントのトレースの現 行コンテンツのスナップショットを作成して、ファイルに保存できます。オ プションで、スナップショット作成後に、セグメント内のメモリーをクリア できます。スナップショット・ファイルの形式は内部フォーマットで、機能 ID などが含まれていますが、簡単に読むことはできません。読むために は、フォーマット設定が必要です。

Formatting the snapshot (スナップショットのフォーマット設定)

コマンド行オプションを使用して、スナップショット・ファイルを標準出力 用にフォーマット設定できます。出力は CSV 形式または XML 形式に設定 可能で、ソース・データに関する情報 (ファイル名および行番号) が自動的 に挿入されます。または、標準トレース形式 (トレース・レコード毎に 1 行) を選択して、ソース情報を含めるかどうか選択することもできます。最 後に、ヘッダー情報を含める (印刷出力に最適) か含めない (プログラムで 分析するためのファイルを作成する場合に最適) かを選択できます。

Filtering (フィルター処理)

コードの作成は完全に自動化されたプロセスなので、出来上がったトレース に、現在問題を起こしていない使用頻度の高いコンポーネントや機能が含ま れている場合があります。それらをトレースから除外する場合は、コマンド 行を使用してフィルター・ファイルを作成します。このファイルで、最初に すべてが含まれるように指定してから、特定のコンポーネント、機能、およ びソース・ファイルの任意の組み合わせを除外することができます。また は、最初にすべてを除外してから、特定のコンポーネント、機能、およびソ ース・ファイルの任意の組み合わせを含めることもできます。機能 ID の範 囲を指定することによって、機能を含めたり除外したりすることもできま す。

フィルター・ファイルを作成したら、構成ファイルのグローバル・セクショ ンまたはプログラム・セクションのいずれかで、そのファイルを宣言しま す。さまざまなプログラム用に複数のフィルター・ファイルを作成すること ができますが、フィルターはセグメント・レベルで適用されることに注意し てください。これは、同一のセグメントに書き込む 2 つのプログラムがあ る場合、どちらか一方のみにフィルターが指定されていても、両方のプログ ラムにフィルターが適用されることを意味します。

既存のフィルター・ファイルをコマンド行から変更することができます。

Products (製品)

インフライト・トレースは、マルチ製品機能として作られています。それぞ れの製品には固有の構成ファイルがあります。この機能の複数のインスタン スを、同一システム上で相互に完全に独立して実行することができます。た だし、コマンドを適用する製品を識別することにより、1 つの製品を別の製 品のトレース機能から制御することもできます。例えば、2 つのバージョン の IBM Workload Scheduler が同一システム上で実行されている場合、コ マンド構文上必要な場合に適切な製品コードを挿入して、両者のインフライ ト・トレース機能を同じ場所から制御できます。

ドキュメント内 IBM Workload SchedulernguVeBOEKCh (ページ 78-121)