JP1/Base 運用ガイド

7.2.1　ログファイルトラップ機能によるイベント変換の仕組み

アプリケーションプログラムのログファイルの内容をJP1イベントに変換してイベントデータベースに登録する流れを次の図に示します。

図7-1　アプリケーションプログラムのログファイルの変換から登録までの流れ

ログファイルトラップ機能は，ログファイルトラップ管理サービス（デーモン）を基盤として動作し，ログファイルを監視します。そして，監視条件に一致するログデータをJP1イベントに変換してイベントデータベースに登録します。

ログファイルトラップの動作は，動作定義ファイルとログファイルトラップ開始コマンド（jevlogstart）のオプションで決定します。動作定義ファイルは，ログファイルトラップの起動時に読み込まれます。

ログファイルトラップ機能の処理の仕組みと，監視の開始位置と終了位置および監視間隔について次に説明します。

＜この項の構成＞

(1)　ログファイルトラップ機能の処理の仕組み

(2)　監視の開始位置と終了位置および監視間隔

(3)　ログファイルの監視失敗時のリトライ

(4)　イベントサービスへの接続失敗時のリトライ

(5)　ファイル形式の指定を誤った場合の通知

(6)　クラスタシステムでの運用

(1)　ログファイルトラップ機能の処理の仕組み

ログファイルトラップ機能の処理の仕組みを次の図で説明します。

図7-2　ログファイルトラップ機能の処理の仕組み

ログファイルトラップ機能では，ログファイルトラップ管理サービス（UNIXの場合，ログファイルトラップ管理デーモン）を基盤として，監視するログファイルごとにログファイルトラップが生成されます。複数のログファイルトラップを同時に起動できるため，さまざまなログファイルを異なる条件で監視できます。また，一つのログファイルトラップで複数のログファイルを監視することもできます。

ログファイルトラップ機能を使用するには，イベントサービス，ログファイルトラップ管理サービス（デーモン）の順番でサービス（デーモン）を起動したあとに，ログファイルトラップを起動します。

イベントサービスとログファイルトラップ管理サービス（デーモン）の起動と終了

Windowsの場合

イベントサービスとログファイルトラップ管理サービスは，JP1/Baseの起動時に自動で起動するようにデフォルトで設定されています。手動で起動または停止する場合は，コントロールパネルの［サービス］ダイアログボックスから「JP1/Base LogTrap」の名称のサービスを起動または終了します。

UNIXの場合

イベントサービスとログファイルトラップ管理デーモンは，jbs_startを編集すると自動起動できます。詳細は，「3.2.1　自動起動および自動終了の設定」を参照してください。手動で行う場合は，jevlogdstartコマンドで起動し，jevlogdstopコマンドで終了します。

ログファイルトラップの起動と終了

ログファイルトラップを起動および停止するには，jevlogstartコマンド，およびjevlogstopコマンドを使用します。ログファイルがまだ存在しない場合でも，jevlogstartコマンドに-rオプションを指定して起動すると，ログファイルが作成されるまでログファイルトラップを待機させることができます。

ログファイルトラップを個別に停止したり，個別に動作定義ファイルを再読み込みしたりする場合は，ログファイルトラップを起動したときに標準出力される識別用のID番号，またはログファイルトラップを起動したときに設定した監視名を指定してコマンドを実行します。

ログファイルトラップ機能を起動すると，ログファイルの監視を開始して，動作定義ファイルに定義した条件と一致するログデータをJP1イベントに変換します。JP1イベントとして登録できるメッセージは，デフォルトでは511バイトまでです。JP1イベントに変換するメッセージが511バイトを超えた場合，511バイト以降のメッセージを切り捨てます。JP1イベントとして登録するメッセージの長さを拡張したい場合は，jevlogstartコマンドで-mオプションに値を指定すると，1,023バイトまで登録できます。

ログファイルトラップ機能で変換されたJP1イベントの属性については，「14.3(8)　動作定義ファイルのACTDEFパラメーターで指定されたイベントIDの詳細」を参照してください。

(2)　監視の開始位置と終了位置および監視間隔

ログファイルの監視を開始するタイミングは，jevlogstartコマンドによってログファイルトラップが起動した時点です。起動後，ログファイルトラップは，ログファイルを一定の間隔で監視します。デフォルトの監視間隔は10秒です。監視間隔は，jevlogstartコマンドの-tオプションで変更できます。ログファイルの監視が終了するタイミングは，jevlogstopコマンドのオプションの指定によって異なります。ログファイルの監視が終了するタイミングの違いを次の図で説明します。

図7-3　ログファイルの監視が終了するタイミングの違い

jevlogstopコマンドで-wオプションを指定しなかった場合は，jevlogstopコマンド実行前の監視タイミングまで監視されます。この場合，jevlogstopコマンド実行前の監視タイミングから，jevlogstopコマンドの実行時までの期間のログは監視されません。

-wオプションを指定した場合は，jevlogstopコマンド実行時に，監視間隔にかかわらず一度ログファイルを読み込むため，jevlogstopコマンドを実行した時点まで監視されます。

ログファイルトラップを再起動した場合は，jevlogstartコマンドでログファイルトラップを起動した時点からログを監視します。ログファイルトラップの停止後から，次に起動するまでの間に出力されたログは監視されません。

(3)　ログファイルの監視失敗時のリトライ

ログファイルの更新元プログラムがログファイルを更新するタイミングと，ログファイルトラップがログファイルを監視するタイミングが競合すると，ログファイルの更新元プログラムによってログファイルに排他が掛けられ，ログファイルのオープンや読み込みに失敗する場合があります。このように，一時的に監視に失敗した場合に，監視をリトライすることができます。

なお，一つのログファイルトラップで複数のログファイルを監視する場合，一つのログファイルの監視に失敗しても，ログファイルトラップは続行します。監視に失敗したログファイルに対してはリトライを行い，ほかのログファイルの監視は続行します。

リトライによって監視を回復できなかった場合は，該当のログファイルの監視を停止します。エラーメッセージで示されるログファイルに異常がないかどうかを確認してください。監視に失敗したログファイルを再度監視したい場合は，jevlogstartコマンドでログファイルトラップを新たに起動してください。

監視の開始時にログファイルをオープンできなかった場合と，監視中にログファイルの読み込みに失敗した場合のリトライの動作について次に説明します。

(a)　監視開始時にログファイルのオープンに失敗した場合

jevlogstartコマンドでログファイルトラップを起動するとき，監視対象のログファイルをオープンします。このとき，ログファイルの更新元プログラムなどによって排他が掛けられていると，ログファイルをオープンできないため監視を開始できません。このような場合，デフォルトでは1秒後に1回リトライします。リトライ間隔およびリトライ回数は，動作定義ファイルで設定できます。

リトライによってログファイルのオープンに成功した場合は，オープンに成功した時点から監視が開始されます。

指定した回数リトライが行われてもログファイルをオープンできなかった場合，およびリトライ開始から3,600秒経過しても回復できなかった場合は，エラーメッセージ，およびJP1イベント（00003A20）で通知します。JP1イベントの詳細については，「14.3(4)　イベントID：00003A20の詳細」を参照してください。

監視開始時に，一時的にログファイルのオープンに失敗した場合のリトライの例を次の図に示します。図の例では，リトライ回数が3回，リトライ間隔が1秒の場合の動作を示します。

図7-4　監視開始時にログファイルのオープンに失敗した場合のリトライの例

リトライによってログファイルのオープンに成功した場合は，ログファイルのオープンに成功した時点から監視が開始されます。リトライを3回行っても回復しなかった場合は，エラーメッセージ，およびJP1イベントで通知します。

(b)　監視中にログファイルの読み込みに失敗した場合

ログファイルの監視中にログファイルの読み込みに失敗した場合は，10ミリ秒間隔で5回リトライします。5回リトライしても回復しなかった場合は，次の監視のタイミングまで待機します。次の監視タイミングでも読み込みに失敗すると，再度10ミリ秒間隔で5回リトライします。リトライ間隔とリトライ回数は固定です。

10ミリ秒間隔で5回のリトライを1セットとしてカウントし，デフォルトでは100セットまでリトライを繰り返します。何セットまでリトライを繰り返すかは，リトライを継続する回数のしきい値として動作定義ファイルで設定できます。

指定した回数リトライが行われても回復しない場合は，該当のログファイルの監視が停止し，JP1イベント（00003A21）で通知します。JP1イベントの詳細については，「14.3(5)　イベントID：00003A21の詳細」を参照してください。

監視中にログファイルの読み込みに失敗した場合のリトライの例を次の図に示します。図の例では，リトライを継続する回数のしきい値を3回に設定した場合の動作を示します。

図7-5　ログファイルの読み込みに失敗した場合のリトライの例

10ミリ秒間隔で5回行われるリトライを1セットとカウントし，リトライを継続する回数のしきい値である3回目のリトライが行われても回復しなかった場合は，ログファイルの監視が停止し，エラーメッセージ，およびJP1イベントで通知します。

(4)　イベントサービスへの接続失敗時のリトライ

ログファイルトラップ機能がイベントサービスに接続できなかった場合に，接続をリトライするように動作定義ファイルに設定できます。イベントサービスへの接続のリトライの設定は，ログファイルトラップごとに設定できます。

リトライ中に変換されたJP1イベントは，指定した件数まで保留されます。指定した件数を超過してJP1イベントが発生すると，超過したJP1イベントは消去されます。

イベントサービスへの接続に成功すると，保留された順番にイベントサービスに送信されます。また，イベントサービスに接続できたことをJP1イベントで通知します。JP1イベントの詳細については，「14.3(3)　イベントID：00003A10の詳細」を参照してください。

指定した回数リトライが行われてもイベントサービスに接続できなかった場合，ログファイルトラップは起動に失敗，または停止します。

デフォルトでは，イベントサービスに接続できなかった場合は，接続のリトライ処理は行われず，ログファイルトラップは起動に失敗または停止します。

(5)　ファイル形式の指定を誤った場合の通知

ログファイルトラップ機能でログファイルを監視する際，動作定義ファイルでログファイルの形式を指定します。ファイル形式の指定を誤った場合は，エラーが通知されます。

次の誤りがある場合は，jevlogstartコマンド実行時にKAVA3646-Eのメッセージが標準エラー出力に出力され，ログファイルトラップの起動に失敗します。

• ログファイルがマルチプロセス対応トレースであるが，動作定義ファイルのファイル形式にHTRACEが指定されていない
• ログファイルがマルチプロセス対応トレース以外であるが，動作定義ファイルのファイル形式にHTRACEが指定されている

なお，jevlogstartコマンドに-rオプションを指定して実行した場合は，ログファイルトラップは，監視対象のログファイルが作成されるまで待機します。ファイル形式の指定に上記の誤りがある場合は，ログファイルが作成されたあとにKAVA3646-Eのメッセージがsyslog，イベントログ，および統合トレースログに出力され，ログファイルトラップが停止します。

このエラーメッセージが出力された場合は，動作定義ファイルのファイル形式を指定し直してからjevlogstartコマンドを再度実行してください。

このほかのケースでファイル形式の指定を誤った場合は，ログファイルトラップの起動後，ログファイルが一定量に達して切り替わった時に，エラーメッセージおよびJP1イベント（00003A22）で通知します。JP1イベントの詳細については，「14.3(6)　イベントID：00003A22の詳細」を参照してください。

JP1イベント（00003A22）が通知された場合は，エラーメッセージで示されるログファイルの状態を確認し，動作定義ファイルで指定したファイル形式を見直してください。

JP1イベント（00003A22）が通知されるケースを，ログファイルの形式ごとに示します。

動作定義ファイルに指定したファイル形式	異常となるケース
SEQ	ログファイルが削除された場合 ログファイルのサイズが小さくなった場合 ログファイルが削除されたあと，同じ名称で再作成された場合※
SEQ2	リネームして再作成される前に，ログファイルのサイズが小さくなった場合
WRAP1	ログファイルが削除された場合 ログファイルのサイズが小さくなった場合 ログファイルが削除されたあと，同じ名称で再作成された場合※
WRAP2	ログファイルが削除された場合 ログファイルが削除されたあと，同じ名称で再作成された場合※
HTRACE	ログファイルが削除された場合 ログファイルが削除されたあと，同じ名称で再作成された場合

注※　ログファイルの形式がSEQ2の可能性があるため，動作定義ファイルに指定したファイル形式を見直してください。

(6)　クラスタシステムでの運用

ログファイルトラップ機能は，物理ホスト単位での起動となります。論理ホスト単位での起動はできません。JP1イベントの登録先を論理ホストのイベントサービスにすると，論理ホストでJP1イベントを管理できます。運用方法に応じてJP1イベントの登録先を変更してください。

デフォルトでは，JP1イベントは物理ホストのイベントサービスへ登録されます。JP1イベントを論理ホストのイベントサービスへ登録したい場合は，jevlogstartコマンドの-sオプションに論理ホストのイベントサーバ名を指定して実行してください。

共有ディスク上のログファイルを監視する場合と，ローカルディスク上のログファイルを監視する場合の運用方法について次に説明します。

(a)　共有ディスク上のログファイルを監視する

共有ディスク上のログファイルを監視したい場合は，論理ホストの起動と停止に合わせて，ログファイルトラップ機能の起動と停止を行う必要があります。フェールオーバー時には，移動前のサーバのログファイルトラップ機能を停止して，新たに実行系となったサーバでログファイルトラップ機能を起動してください。

なお，共有ディスク上のログファイルの監視中は，共有ディスクを常にアクセスできるように割り当てたままにしてください。ファイル監視中に共有ディスクの割り当て状態を変更すると，共有ディスクの割り当てや割り当て解除の制御に失敗したり，監視処理がエラーになったりするなどの問題が生じるおそれがあります。

共有ディスク上のログファイルを監視する場合の構成例を次の図に示します。

図7-6　共有ディスク上のログファイルを監視する場合の構成例

(b)　ローカルディスク上のログファイルを監視する

実行系と待機系両方のローカルディスク上のログファイルを監視したい場合は，変換したJP1イベントをいったん物理ホストのイベントサービスに登録してください。そして，転送設定ファイルで論理ホストのイベントサービスに転送するよう設定してください。転送設定ファイルの詳細については，「6.5.2　転送設定ファイル（forward）の詳細」を参照してください。

ローカルディスクのログファイルを論理ホストで監視する場合の構成例を次の図に示します。

図7-7　ローカルディスクのログファイルを論理ホストで監視する場合の構成例

[目次][前へ][次へ]

All Rights Reserved. Copyright (C) 2006, 2008, Hitachi, Ltd.