ログファイルトラップは，サイズが2ギガバイトまでのログファイルを監視できます。また，さまざまな形式のログファイルを監視できます。監視対象のログファイルの形式を確認して，ログファイルトラップ動作定義ファイルにログファイルの形式を指定します。監視できるログファイルの形式を説明します。

• シーケンシャルファイル（SEQ）
  一つのログファイルに追加書き込みし続けるファイル，または，ログファイルが一定の容量に達すると，別のファイル名で新たにログファイルを作成して書き込むファイルです。ログファイルトラップ動作定義ファイルには「SEQ」と指定します。シーケンシャルファイル（SEQ）の動作を次の図に示します。
  

  図1-11　シーケンシャルファイル（SEQ）の動作

  

• シーケンシャルファイル（SEQ2）
  
  • Windowsの場合
    同一ボリューム内でファイル名を変更したあと，変更前のファイル名と同じ名称のファイルを作成して新たにログを書き込むファイルです。
    
  • UNIXの場合
    ファイル名を変更，またはファイルをいったん削除したあと，変更／削除前のファイル名と同じ名称のファイルを作成して新たにログを書き込むファイルです。
    
  ログファイルトラップ動作定義ファイルには「SEQ2」と指定します。シーケンシャルファイル（SEQ2）の動作を次の図に示します。
  

  図1-12　シーケンシャルファイル（SEQ2）の動作

  

• シーケンシャルファイル（SEQ3）
  
  • Windows限定
    ファイルをいったん削除したあと，削除前のファイル名と同じ名称のファイルを作成して新たにログを書き込むファイルです。
    Windowsでは，この形式のログファイルを監視する場合，ログファイルトラップ動作定義ファイルには「SEQ3」と指定します。Windowsでログファイルトラップ動作定義ファイルに「SEQ2」を指定しても，この形式のログファイルは監視できません。
    シーケンシャルファイル（SEQ3）の動作を次の図に示します。
    

    図1-13　シーケンシャルファイル（SEQ3）の動作

    

• ラップアラウンドファイル（WRAP1）
  ログファイルが一定の容量に達すると，ラップアラウンドして，再び先頭からデータを上書きする形式のファイルです。ログファイルトラップ動作定義ファイルには「WRAP1」と指定します。
  なお，WRAP1の形式のログファイルを監視する場合，監視するファイルの容量と同じサイズの空きディスク容量が必要です。ラップアラウンドファイル（WRAP1）の動作を次の図に示します。
  

  図1-14　ラップアラウンドファイル（WRAP1）の動作

  

• ラップアラウンドファイル（WRAP2）
  ログファイルが一定の容量に達してラップアラウンドするとき，データを削除して再び先頭からデータを書き込む形式のファイルです。ログファイルトラップ動作定義ファイルには「WRAP2」と指定します。ラップアラウンドファイル（WRAP2）の動作を次の図に示します。
  

  図1-15　ラップアラウンドファイル（WRAP2）の動作

  

• マルチプロセス対応トレースファイル（HTRACE）
  Cosminexusなどの日立のミドルウェア製品が出力するログファイルの形式の一つで，複数のプロセスが一組のトレースファイルを共有するメモリマップドファイルを使用した固定サイズのファイルです。ログファイルトラップ動作定義ファイルには「HTRACE」と指定します。ログファイルの書き込み方法はWRAP1と同様で，ログファイルが一定の容量に達すると，ラップアラウンドして，再び先頭からデータを上書きします。データの書き込み時にファイルの更新日時は更新されません。監視対象のログファイルがマルチプロセス対応トレースファイルかどうかは，各製品のマニュアルを参照してください。マルチプロセス対応トレースファイル（HTRACE）の動作を次の図に示します。
  

  図1-16　マルチプロセス対応トレースファイル（HTRACE）の動作

  

• UPDタイプのログファイル
  ファイル名に日付など不定な文字列が設定されるログファイルを監視するときに使用します。不定な文字列部分は，ワイルドカードで指定します。
  ログファイルトラップ起動時には，ワイルドカードの指定に該当するファイルのうち，最新の更新日時のログファイルを監視対象とします。また，ログファイルトラップ起動中（監視中）は，監視中に新規作成されたワイルドカードの指定に該当するファイルのうち，最新の更新日時のログファイルへと監視を切り替えます。したがって，ログが書き込まれたときにファイルの更新日時情報が更新される必要があります。
  一つのログファイルに追加書き込みし続けるファイル，または，ログファイルが一定の容量に達すると，別のファイル名で新たにログファイルを作成して書き込むファイル（シーケンシャルファイル）を継続して監視できます。
  ログファイルトラップ動作定義ファイルには「UPD」と指定します。UPDタイプのログファイルの動作を次の図に示します。
  

  図1-17　UPDタイプのログファイルの動作

  

  1. 起動コマンド（jevlogstartコマンド）実行時，監視対象ファイル名はワイルドカードを含むように指定する。
  2. ワイルドカード指定に該当するファイルだけ（上限1,000）が監視対象の候補となる。
     起動時に上限を超えていた場合，起動エラーとなります。また，監視中に上限を超えた場合，エラーメッセージを出力して，ログファイルトラップを停止します。
     
  3. 起動時は，監視対象候補のファイルの中から最新更新日時のログファイル一つを決定して，監視を開始する。
  4. 起動中は，監視間隔ごとに監視対象ログファイルの見直し（新規ファイルが作成されているかどうか）をする。
  5. 新規にファイルが作成されていた場合，監視中の未処理分のログを処理したあと，監視対象のログファイルを切り替える。
     新規に作成されたファイルだけが監視の切り替えの対象であり，そのほかのファイルの最終更新日時が更新されても監視の切り替えはしません。新規ファイルが複数個あった場合は，その中から最新更新日時のファイル一つを決定して，切り替え対象とします。
     

ログファイルトラップでは，シンボリックリンクが設定されたファイルも監視できます。ただし，リンク先の変更に対応できるログファイルの形式はSEQ2だけです。

なお，次に示すログファイルは監視できません。

• 毎回ファイルの先頭からログ情報が記録されるファイル
• データが書き込まれても日時が更新されないファイル，およびデータが書き込まれないのに日時が更新されるファイル
  ラップアラウンドファイル（WRAP1）およびUPDタイプのログファイルを監視する場合，ログファイルトラップがログファイルを読み込む際に，更新日時を参照します。このようなファイルを監視すると，ログファイルトラップが正常に動作しないことがあります。
  
• スペシャルファイル，デバイスファイル
  ログファイル中の1行の終了文字以外でバイナリーデータを含むレコードがあるファイルです。
  
• ファイル名が特定できないファイル
• ファイル名が特定できないファイル（UPDタイプのログファイルの監視を除く）
  プロセスIDなど，ファイル名にその時々に応じて値が変わるものを含んでいるファイルです。
  
• ネットワークファイル
  他コンピュータのファイルを，ファイル共有などでアクセスした場合，ネットワークの障害や遅延の際に動作を保証できません。
  
• 1行だけ出力されるログファイル
  ログファイルに常に1行しかログが存在しないファイルです。
  
• 排他されるファイル
  ログファイルトラップは，ログファイルを読み込みモードで開きます。このため，Windowsではログの出力プログラムが排他に失敗し，ログが出力されないことがあります。
  
• JP1/Baseがサポートしていない言語で出力されるファイル
  JP1/BaseがWindowsでサポートしている言語はMS932とCです。JP1/BaseがUNIXでサポートしている言語については「2.3.5(2)　言語種別の設定」を参照してください。
  

シーケンシャルファイル（SEQ3）を監視する場合，ログ出力側で次に示す条件を満たしていないと，ログを正しく監視できないおそれがあります。

• ログ出力側でログが出力された直後は，一定時間（監視間隔時間に1秒以上足した時間）経過したあとに，ログファイルが削除されること。
  ログが出力された直後にログファイルが削除された場合，図1-18に示すように，削除前に蓄積されていたログを読み込めないおそれがあります。
  
• ログ出力側でログ切り替え（ファイル削除および再作成）をする場合，ファイル削除または再作成のエラー発生時にリトライ処理をしていること。
  Windowsでは，ログファイルトラップがログファイルを読み込んでいる（ファイルの状態がOPEN）ときは，ログ出力側によるログ切り替えに失敗することがあります。
  ログファイルトラップは，監視間隔中はログファイルの状態をCLOSEにしているため，ログ出力側は一度ログ切り替えに失敗しても，リトライ処理をすることでログ切り替えができるようになります。したがって，ログ出力側でログ切り替えの際にリトライ処理が組み込まれていないと，ログ出力に失敗するおそれがあります。
  

  図1-18　シーケンシャルファイル（SEQ3）でログ出力を監視できないケース

  

WindowsおよびUNIXで監視できるログファイル数の目安を次に示します。

Windowsの場合

監視できるログファイル数の最大値は次の式に従います。

（凡例）

a：監視するログファイルの総数（同一ファイルでも加算する）

b：JP1/AJSのログファイル監視ジョブで監視するログファイルの総数（同一ファイルでも加算する）

m：jevlogstartコマンドの実行数

n：JP1/AJSのログファイル監視ジョブの実行数

UNIXの場合

一つのログファイルトラップで監視できる監視ファイルの最大数は100ですが，UNIXのシステム上で監視できる監視ファイルの最大数は，カーネルパラメーターの設定（ファイルオープン数の設定）次第となります。

ログファイルの監視は，jevlogstartコマンドを実行してログファイルトラップが起動した時点で開始し，一定の間隔で監視を続けます。監視間隔は，jevlogstartコマンドの-tオプションで変更できます。jevlogstartコマンドの-tオプションを省略した場合，監視間隔は10秒です。ログファイルの監視が終了するタイミングは，jevlogstopコマンドのオプションの指定によって異なります。コマンドの詳細については，「13.　コマンド」を参照してください。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ログファイルトラップがイベントサービスに接続できなかった場合，接続をリトライするかどうかは，ログファイルトラップ動作定義ファイルの設定によります。接続をリトライしたい場合は，ログファイルトラップ動作定義ファイルに，ログファイルトラップごとに設定します。指定した回数リトライが行われてもイベントサービスに接続できなかった場合，ログファイルトラップは起動に失敗，または停止します。ログファイルトラップ動作定義ファイルでログファイルトラップごとの接続のリトライ回数を省略したときは，接続はリトライされないで，ログファイルトラップは起動に失敗または停止します。

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

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