4.5.2. ログ監視機能について

本章ではログ監視機能の動作や、制限事項について説明します。

4.5.2.1. システム(OS)ログの監視について

本バージョンでは、次のファイルについてはデフォルトでは監視を行っていません。必要に応じてログ監視の設定を行ってください。

　　　Windows ：イベントログ(アプリケーション，システム，セキュリティログやその他カスタムイベントログ)

　　　UNIX/Linux ：OS障害監視用ログファイル

注釈

UNIX/Linux におけるOS障害監視用ログファイルを取得するには、 /etc/syslog.conf または、/etc/rsyslog.conf の編集が必要です。

出力先ファイルは <千手ホームディレクトリ>/log/senju_syslog とし、下記のように設定して下さい。

*.err;user,local0,local1,local2,local3,local4,local5,local6,local7.none <千手ホームディレクトリ>/log/senju_syslog

ログ監視の設定は以下として下さい。

　監視対象ファイルパス：/etc/

　監視対象ファイル名　：senju_syslog

　正規表現の使用　　　：しない

　監視方法　　　　　　：sjsyslog　（その他のログフィルタを設定することも可能です）

4.5.2.2. リブート時における監視の継続

ログ監視では千手システムが再起動した場合、ログ監視機能が稼働した後に出力されたログを監視しますが、システム(OS)ログファイルについては千手システムが停止したときに監視していた位置から継続して監視を行います。

これによりマシンリブート時など、千手システム停止時にシステム(OS)ログファイルに出力されたログを起動後に継続して監視することができます。

その他のログは、ノードモニタの[ログ監視]タブより、ログ監視の一時停止・再開を行うことで、ログ監視漏れを防止することができます。詳細は ログ監視の再開ダイアログ を参照して下さい。

注釈

• OSを起動させたまま長時間千手システムを停止させた状態で放置すると、千手システム起動時に大量のログを検知する事があります。

• UNIX/Linuxにおいて、千手システムの停止／起動が午前０時７分をまたがった場合、監視対象となるのはこの時刻以降に出力されたログのみです。この時刻以前に出力されたログは監視されません。
  Windowsにおいて、イベントログが上書きされた場合、監視対象となるのはログ監視機能が稼働した後に出力されたログのみです。

4.5.2.3. 様々なファイルのシフト方法におけるログの監視設定

ログ監視機能では、ログを出力するアプリケーションが行う様々なファイルシフト方法に対応しています。

4.5.2.3.1. 監視対象のログについて

監視対象ファイル内で監視対象となるログは、千手システムの起動、反映（監視属性）の実施、及びログ監視の再開コマンド(sjANM_startlog)の実施でログ監視を開始した後に出力されたログのみです。

ログ監視を継続している場合は、前回のログ監視以降に出力されたログを監視します。また、ログ監視の継続中に監視対象ファイルが切り替わった場合は、切り替え前のログを最後まで監視した後に新しいファイルの先頭から監視を行います。

注釈

ログ監視の再開コマンド(sjANM_startlog)では、前回のログ監視以降に出力されたログからの再開を指定できます。コマンドについては デベロッパーズガイド「千手コマンドの一覧」 の sjANM_startlog－ログ監視の再開－ を参照して下さい。

4.5.2.3.2. 監視対象ログファイルのシフト方法について

ファイルのシフト方法により、以下の様に監視の設定を行って下さい。

• ログファイルをリネームしてシフトする場合

  これはアプリケーションがログをシフトする際、今までログを出力していたファイルをリネームして別ファイル名とし、リネーム前のファイル名と同名ファイルを新たに作成し、このファイルにログを出力する場合です。

  この方式では、ログの出力先ファイル名は常に固定になりますので、このファイルを監視対象とします。

  例えばファイルパスを /tmp/log/ とし、ログファイル名が aplog である場合、ログ監視の定義は以下の様になります。

  　　・監視対象ファイルパス：/tmp/log/

  　　・監視対象ファイル名　：aplog

  　　・正規表現の使用　　　：しない

  この場合、ログ監視の動作は以下の様になります。

  表 4.283 ログがリネームによりシフトする場合

  シフトの状態	ログファイルの状態	ログ監視動作
  ファイルシフト前	aplogにログを出力。	aplogを監視。
  ファイルシフト時	aplogをaplog.1にリネーム。その後、新たにaplogファイルを作成。	監視対象ファイルがリネームされた事を検知。aplog.1の最後まで検査した後、監視対象を新たに作成されたaplogへ切り替え。
  ファイルシフト後	新たに作成したaplogファイルにログを出力。	aplogをファイルの先頭から監視。

  注釈

  シフト後の監視タイミング到来時に、監視対象ファイル(aplog)が作成されていない場合、「!ANM266 監視するログファイルが存在しません。」メッセージが出力されます。そのため、シフトのタイミングでファイル(aplog)を作成されることを推奨します。Windowsの場合 注意事項 も参照してください。

  【UNIX/Linux千手センサー】

  UNIX/Linux千手センサーの場合、ログ監視の動作は以下の様になります。

  表 4.284 ログがリネームによりシフトする場合

  シフトの状態	ログファイルの状態	ログ監視動作
  ファイルシフト前	aplogにログを出力。	aplogファイルからtailコマンドにてプローブノードのログ監視用ファイル($SENJUHOME/log/RmtLog/センサーノードID/配下)に取得しログ監視用ファイルを監視。
  ファイルシフト時	aplogをaplog.1にリネーム。その後、新たにaplogファイルを作成。	監視対象ファイルがリネームされた事を検知。tailコマンドを停止しプローブノードのログ監視用ファイルをシフト。ログ監視用ファイルの最後まで検査した後、監視対象を新たに作成されたログ監視用ファイルへ切り替え。
  ファイルシフト後	新たに作成したaplogファイルにログを出力。	ログ監視用ファイルの先頭から監視。

  注釈

  ファイルシフト時にtailコマンドを停止しますが、tailコマンドでファイルを取得中であっても停止されます。大量のログが出力された直後にログファイルがシフトされた場合、検査のタイミングによっては出力されたログの取得が完了する前にtailコマンドが停止されることでログが監視されない場合があります。

  大量にログが出力される場合は検査間隔を長めに設定するなどの調整を行って下さい。

• ログファイルのバックアップを取り、同じファイルの先頭より上書きする場合

  これはアプリケーションがログをシフトする際、ログの内容を別名ファイルにコピーしてバックアップを取得した後、今までログを出力していたファイルの先頭から、再度上書きしてログを出力しつづける場合です。

  この方式では、ログの出力先ファイル名は常に固定になりますので、このファイルを監視対象とします。

  (なお、この方法では監視タイミングとファイルのシフトタイミングにより、出力されたログが監視されない場合があります。そのため、監視対象ログファイルのシフト方法としては、他の方式でのファイルシフトを検討願います。)

  例えばファイルパスを /tmp/log/ とし、ログファイル名が aplog である場合、ログ監視の定義は以下の様になります。

  　　・監視対象ファイルパス：/tmp/log/

  　　・監視対象ファイル名　：aplog

  　　・正規表現の使用　　　：しない

  この場合、ログ監視の動作は以下の様になります。

  表 4.285 ログファイルのバックアップを取得後、同じファイルの先頭から上書きする場合

  シフトの状態	ログファイルの状態	ログ監視動作
  ファイルシフト前	aplogにログを出力。	aplogを監視。
  ファイルシフト時	aplogファイルの内容をaplog.1にコピー。この時、新たなログはaplogの先頭から上書きする。	ファイルサイズの減少により、aplogが上書きされたことを検知。
  ファイルシフト後	aplogに引き続きログを出力。	aplogをファイルの先頭から再度監視。

  注釈

  • この方式では、以下のように処理が実施された場合、2で出力されたログは、5の監視タイミングが到来する前に、4で上書きされるため監視されません。
    また、4で出力されたログがシフト前の2のサイズより多い場合、増加分のみを監視します。（ 注意事項 も参照してください。）

    1. 監視タイミング到来

    2. 監視対象ファイル(aplog)へのログ出力

    3. 監視対象ファイル(aplog)のシフト
       ・aplogファイルの内容をaplog.1にコピー

    4. 監視対象ファイル(aplog)へのログ出力(先頭から上書き)

    5. 監視タイミング到来

  そのため、監視対象ログファイルのシフト方法としては、他の方式でのファイルシフトを検討願います。

• 固定ファイル名の複数ファイルを循環させてログを出力する場合

  これは固定ファイル名のログファイルを予め複数作成しておき、アプリケーションはこれらのファイルを循環させてログの出力先を変更していく場合です。

  この方式ではログの出力先ファイル名は固定ですが、タイミングにより出力されているファイル名は変動しますので、すべての出力先ファイルを監視対象とします。

  例えばファイルパスを /tmp/log/ とし、ログファイル名が aplog1 、 aplog2 の２ファイルである場合、ログの出力先ファイル名は、 aplog1 → aplog2 → aplog1 → aplog2 と変わりますのでログ監視の定義は以下の２つが必要になります。

  設定.a

  　　・監視対象ファイルパス：/tmp/log/

  　　・監視対象ファイル名　：aplog1

  　　・正規表現の使用　　　：しない

  設定.b

  　　・監視対象ファイルパス：/tmp/log/

  　　・監視対象ファイル名　：aplog2

  　　・正規表現の使用　　　：しない

  この場合、ログ監視の動作は以下の様になります｡

  表 4.286 固定ファイル名の複数ファイルを循環させてログを出力する場合

  シフトの状態	ログファイルの状態	ログ監視動作
  ファイルシフト前	aplog1にログを出力。	aplog1、aplog2を監視。
  ファイルシフト時	ログ出力先をaplog1からaplog2に切り替え。この時、新たなログはaplog2の先頭から上書きする。	aplog2のファイルサイズの減少により、aplog2が上書きされたことを検知。
  ファイルシフト後	aplog2に引き続きログを出力。	aplog2はファイルの先頭から再度監視。
  次のファイルシフト時	ログ出力先をaplog2からaplog1に切り替え。この時、新たなログはaplog1の先頭から上書きする。	aplog1のファイルサイズの減少により、aplog1が上書きされたことを検知。
  ファイルシフト後	aplog1にログを出力。	aplog1はファイルの先頭から再度監視。

  注釈

  監視タイミング到来時に、定義した監視対象ファイルが作成されていない場合、「!ANM266 監視するログファイルが存在しません。」メッセージが出力されます。そのため、監視対象となるファイルは、最初に全て作成されることを推奨します。
  また、この方法では、ログ出力先の切り替え後に監視対象ファイルのファイルサイズが減少していることをログ監視で認識することが重要です。 注意事項 も参照願います。

• 毎回新たなファイルを作成してログを出力する場合。

  これはアプリケーションがログをシフトする際、毎回新たなファイル名のログファイルを作成して出力する場合です。

  この方式では、ログの出力先パスは常に固定ですが、監視対象ファイル名は動的に変化しますので、変化するファイル名がすべて監視対象に含まれるよう正規表現を使用します。

  例えばファイルパスを /tmp/log/ とし、ログファイル名のネーミング規則に日付を用いて aplog.YYYYMMDD (YYYYMMDDには年月日が入る)となる場合、ログ監視の定義は以下の様になります。

  　　・監視対象ファイルパス： /tmp/log/

  　　・監視対象ファイル名　： ^aplog\.[0-9]

  　　・正規表現の使用　　　： する

  監視対象ファイル名の ^aplog\.[0-9]* において、^ はファイル名の先頭が、 aplog で始まる事を示しており、 \ は次の文字の . が正規表現と解釈されないようにエスケープしていることを意味します。また、 [0-9]* は任意の数字の繰返しにマッチします。このように、意図しないログファイルが監視対象とならないように、できる限り条件を絞り込んで監視対象ファイル名を設定して下さい。

  この場合、ログ監視の動作は以下の様になります。

  表 4.287 毎回新たなファイルを作成してログを出力する例

  シフトの状態	ログファイルの状態	ログ監視動作
  ファイルシフト前	aplog.20050401にログを出力。	aplog.20050401を監視。
  ファイルシフト時	新たにログファイルaplog.20050402を作成。	正規表現にマッチする新しいファイルが作成された事を検知。 aplog.20050401の最後まで検査した後、監視対象を新たに作成されたaplog.20050402へ切り替え。
  ファイルシフト後	aplog.20050402にログを出力。	aplog.20050402をファイルの先頭から監視。

  注釈

  • 監視対象ファイル名に使用する正規表現には、ノードのプロパティの[ログ監視]タブより、「基本正規表現」の「高度な正規表現」のどちらを使用するか指定できます。ログファイル名は、指定した正規表現で表現できる一定のネーミング規則に沿って作成されるようにして下さい。

  • 監視対象ファイルの決定方法については 監視対象ファイル正規表現指定時の監視対象ファイル決定方式 を参照して下さい。

4.5.2.3.3. ログ監視できないログの出力方法について

ログ監視は「 監視対象のログについて 」に記載の動作となりますので、ログは監視対象ファイルへ追加出力されている必要があります。ログが追加出力されていない場合は千手システム側では対応できません。
ログの出力例と動作を以下に示します。

• （例.1）監視対象のログファイルを上書きする

  アプリケーションがログをいったんメモリなどに出力し、その後、メモリなどの内容を監視対象ファイルに上書き出力する場合です。なお、ログをいったんメモリなどに出力してもその内容を監視対象ファイルに追加で出力する場合は正常にログ監視できます。

  この方式では以下の動作となりますので、監視が行われない場合があります。

  • ファイルサイズが前回の監視時より減少した場合

    ファイルがシフトされたと判断されますので、ファイルの先頭より監視します。

  • ファイルサイズが前回の監視時より増加した場合

    前回監視時のファイルサイズより増加した部分を監視しますので、前回監視時のファイルサイズに該当する部分は監視されません。

• （例.2）ログを出力する際に、古いログを削除する

  アプリケーションがログを出力する際、古いログを削除する場合です。（監視対象ファイルに出力されているログの行数やファイルサイズを一定量に保つ場合などが考えられます。）

  この方式では以下の動作となりますので、監視が行われない場合があります。

  • ファイルサイズが前回の監視時より減少した場合

    ファイルがシフトされたと判断されファイルの先頭より監視しますので、一度検知されたログが再度検知されます。

  • ファイルサイズが前回の監視時より増加した場合

    前回監視時のファイルサイズより増加した部分を監視しますので、前回監視時のファイルサイズに該当する部分は監視されません。

4.5.2.4. 監視対象ファイル正規表現指定時の監視対象ファイル決定方式

ログ監視の監視対象ファイル名に正規表現を使用する事により、例えばログファイル名に日付が入っている場合など、動的にファイル名が変更されるログファイルを監視することができます。

この際、ファイル名は部分一致で判断します。また、マッチするファイルのうち監視対象となるファイルは次のように決定されます。

• 千手システム起動時(sjANM_logwatchd起動時)

  以下の条件で決定されます。

  • ファイルのタイムスタンプが最新のファイル

  正規表現でマッチするファイルにタイムスタンプが同じファイルが複数存在する場合、ファイル名で昇順にソートした場合に最後になるファイル名を監視します。

  その後、下記の「検査間隔経過による監視タイミング」の条件で監視対象ファイルが決定されます。

  注釈

  • タイムスタンプは、UNIX/Linuxでは「最終更新日時」になります。Windowsでは「更新日時」になります。

  • Windowsの場合、OS動作によりタイムスタンプが同じになる場合があります。（ 注意事項 を参照願います。）

• 「反映(監視属性)」実施時

  上記、「千手システム起動時(sjANM_logwatchd起動時)」 と同じです。

• ログ監視の一時停止／再開(sjANM_stoplog/sjANM_startlog)時

  再開されたときは、一時停止する際に監視対象としていたファイルを監視します。

  新たなファイルが作成されていた場合は、下記の「検査間隔経過による監視タイミング」と同じ動作になります。

• 検査間隔の経過による監視タイミング

  検査間隔が経過する度に指定された監視対象パスに新たなファイルが作成されていないか検査を行い、作成を検知すると監視対象ファイルを切り替えるかどうかを下記条件にて自動的に判定し、常に最新の１ファイルを監視します。

  1. ファイルのタイムスタンプが最新のファイル

  2. タイムスタンプが全く同じ場合は、ファイル名で昇順にソートした場合に最後になるファイル名

4.5.2.4.1. 正規表現ファイル名指定時のファイルの検査

ファイル内で監視対象となるログは、 監視対象のログについて と同じです。また、検査間隔内に監視対象となる条件を満たすファイルが複数作成された場合、ファイルのタイムスタンプが最新(同じ場合はファイル名の昇順で最後)の１つのファイルを検査します。

4.5.2.5. 文字コード変換における特殊処理

UTF-8以外の文字コードをログ監視定義で指定した場合、文字コード変換を行います。文字コード変換を行う前に、特定の範囲の文字コードに関しては事前に ? に変換し、文字コードの変換でエラーが発生するのを防ぐ処理を行っています。以下の範囲が、事前に ? に変換される文字コードの範囲です。

表 4.288 事前に ? に変換する文字コード範囲

文字コード	? に変換する文字コードの範囲
Shift JIS	第1バイト 第2バイト
	0xF0-F9　　0x40-FF
EUC	第1バイト 第2バイト
	0xFF 　0xA1-FE
	0x80 　0xA1-FF
	0x80 　0x80-81
	0x81 　0xA1-FE
	0x82 　0xA1-FF
	0x82 　0x80-81
	0x83 　0xA1-FE
	0x84 　0xA1-FF
	0x84 　0x80-81
	0x85 　0xA1-FE
	0x86 　0xA1-FF
	0x86 　0x80-81
	0x87 　0xA1-FE
	0x88 　0xA1-FF
	0x88 　0x80-81
	0x89 　0xA1-FE
	0x8A 　0xA1-FF
	0x8A 　0x80-81
	0x8B 　0xA1-FE
	0x8C 　0xA1-FF
	0x8C 　0x80-81
	0x8D 　0xA1-FE
	0x8E 　0xE0-FF
	0x8E 　0x80-81
	0x8F 　0xA1-FE
	0x90 　0xA1-FF
	0x90 　0x80-81
	0x91 　0xA1-FE
	0x92 　0xA1-FF
	0x92 　0x80-81
UTF-8	第1バイト 第2バイト 第3バイト 第4バイト
	0xEE 0x80-BF 0x80-BF
	0xEF 0x80-A3 0x80-BF
	0xF3 0xB0-BF 0x80-BF 0x80-BF
	0xF4 0x80-8F 0x80-BF 0x80-BF
UTF-16LE(※)	最初の2バイト 次の2バイト
	0xE000-F8FF
	0xDB80-DBFF 0xDC00-DFFF

※Big Endianで記載しているため、実際には１バイト目と2バイト目が逆になります。

Unix/Linux版にてUTF-8以外のファイルをログ監視する場合には、OSのシステム関数であるiconv関数を用いて文字コードの変換を行います。

iconv関数で文字コード変換に失敗した場合、失敗した個所を ? に変換し、次の文字からコード変換を継続しますが、デフォルトでは、1行につき10回までとなります。

1行のコード変換エラーが11回目となった場合、 ? の変換処理は行われず、「!ANM292 文字コード変換に失敗しました。」メッセージが出力されます。このメッセージは、１つの監視対象毎に、１回の監視間隔内で複数行が11回目となった場合でも、1度だけ表示されます。

なお、変換エラーが11回目となった行は、以下のように扱われます。

• 以降の文字については、文字コードの変換処理は行われません。

• 監視は、11回目となった直前の文字までで行われます。

• 付加メッセージには、11回目となった直前の文字までが出力されます。

コード変換エラー回数の変更方法については、 テキストログ監視で、iconvによる文字コード変換が失敗した際のリトライ回数の設定 を参照して下さい。

Windows版の場合はこの制限がありません。そのため、文字コード変換による特殊処理にて文字コード変換に失敗した場合、全て ? に変換されます。

4.5.2.6. メッセージ出力した行のログファイル出力

テキストやJSON形式のファイルをログ監視で監視した結果、ログフィルタまたはJSONログフィルタの条件に該当した場合、ログの内容がメッセージモニタに出力されます。

また、イベントログ監視の結果、イベントログフィルタの条件に該当した場合、イベントログの内容がメッセージモニタに出力されます。

しかし、メッセージで出力可能な文字数は3160byteが最大となります。ログの行がさらに長い場合にはメッセージに表示しきれないため、ログの内容の全てを確認できません。

メッセージモニタではログの内容が確認できない場合でもこのテキストファイルを確認することにより検知したログの内容を確認できます。メッセージモニタにメッセージを出力する際にシーケンス番号を付与していますので、確認する際にご利用ください。(※イベントログ監視のメッセージには、シーケンス番号は付与していません)

監視対象ノード(千手センサーの場合はプローブ)の以下のファイルに、ログ監視の結果メッセージ出力することになったログの内容が記録されます。

UNIX：$SENJUHOME/log/logwatch.d/sjANM_logwatchd_msg_(番号)_(ノードID).log

Windows : %SENJUHOME%\log\logwatch.d\sjANM_logwatchd_msg_(番号)_(ノードID).log

注釈

• ファイル名の中の(番号)は、ログ定義毎に番号が自動的に割り振られたものです。ログ定義を削除し反映(監視属性)を実施した際には、削除されたログ定義に該当するファイルは削除されます。

このファイルは、1MBを超えると、自動的に切り替えられ、新しいログ情報ファイルに更新されます。

古いログ情報ファイルは"sjANM_logwatchd_msg_(番号)_(ノードID).log.1"のファイル名で保存されます。以降、"sjANM_logwatchd_msg_(番号)_(ノードID).log.2"，"sjANM_logwatchd_msg_(番号)_(ノードID).log.3",…へ保存され、最大"sjANM_logwatchd_msg_(番号)_(ノードID).log.7"まで7世代分のファイルが保存されます。7世代より前のファイルは順次削除されます。

メッセージにシーケンス番号を付加するかは、以下の千手システムの環境変数で変更することができます。

• メッセージへのシーケンス番号付加

  環境変数名：sjANM_logmsg_seq

  メッセージ出力時にシーケンス番号をメッセージの付加文言に出力するかを設定します。環境変数を設定していない場合は、シーケンス番号が付加されます。デフォルトでは、環境変数は設定されていないため、シーケンス番号が付加されます。環境変数に"0"を設定するとシーケンス番号が付加されなくなり、"0"以外の数値を設定した場合は、シーケンス番号が付加されます。

ファイルの容量、保存するファイル数はそれぞれ以下の千手システムの環境変数で変更することができます。

• ファイルの容量

  環境変数名：sjANM_logmsg_size

  ファイルの容量が、環境変数に指定した値(単位：MByte)を超えると新しいログ情報ファイルに更新されます。

• 保存するファイル数

  環境変数名：sjANM_logmsg_shift

  古いログ情報ファイルは、"sjANM_logwatchd_msg_(番号)_(ノードID).log.1"から、最大"sjANM_logwatchd_msg_(番号)_(ノードID).log.[環境変数に指定した値]"まで、[環境変数に指定した値]世代分のファイルが保存されます。

環境変数の設定は、以下の手順にて実施します。

1. 千手稼働アカウント権限

   管理対象ノードに、千手稼働アカウントでログインして下さい。

2. 環境変数の設定

   • ＜UNIX＞

     ターミナルから以下のコマンドを実行して下さい。(大文字、小文字に注意して下さい)

     % sj_source.com -csjANM_logmsg_size=n (nは環境変数の値)
     success
     % exit
     

     ※(nはファイル容量　単位：MByte)

     設定した環境変数を確認するには、千手稼働アカウントで再ログインした後、以下のコマンドを実行して下さい。

     % env | grep sjANM_logmsg_size
     

     環境変数や値が誤っていたときは、再度、正しく設定し直して下さい。（無効な、または誤った値が設定されているときは、デフォルトの値になります。また、設定により有効になった値は、常に最新の設定値になります。）

   • ＜Windows＞

     コマンドプロンプトから以下のコマンドを実行して下さい。(大文字、小文字に注意して下さい)

     $ sj_source -csjANM_logmsg_size=n (nは環境変数の値)
     環境変数反映コマンドは正常に終了しました。
     $ exit
     

     ※(nはファイル容量　単位：MByte)

     設定した環境変数を確認するには、コマンドプロンプトを再起動後、以下のコマンドを実行して下さい。

     $ sj_getenv sjANM_logmsg_size
     

     環境変数や値が誤っていたときは、再度、正しく設定し直して下さい。（無効な、または誤った値が設定されているときは、デフォルトの値になります。また、設定により有効になった値は、常に最新の設定値になります。）

3. 千手プロセスのダウン／アップ

   ノードモニタから管理対象ノードのログ監視プロセス（sjANM_logwatchd）を再起動して下さい。

以下のフォーマットで出力されます。

(シーケンス番号)<TAB>(ノードID)<TAB>(日時)<TAB>(メッセージID)<TAB>(監視対象ファイル名)<TAB>(内容)

以下の表は、各カラムの意味です。

カラム	内容
シーケンス番号	メッセージを識別するための10桁のシーケンス番号です。
ノードID	メッセージを発信したまたは対象となるノードIDが表示されます。
日時	メッセージが発信された日時が表示されます。
メッセージID	メッセージIDです。
監視対象ファイル名	ログ監視の監視対象ファイル名です。
内容	メッセージ出力対象となった、ログの内容です。

注釈

• UTF-8以外の文字コードをログ監視定義で指定した場合、文字コード変換を行います。ファイルに出力されるログの内容は文字コード変換後の内容が出力されます。

• ログ監視による大量メッセージ出力をまとめる場合の設定 にて、メッセージモニタへの出力が抑止されたメッセージもファイルに出力されます。

4.5.2.7. ログ監視による大量メッセージ出力をまとめる場合の設定

テキストやJSON形式のファイルをログ監視した場合や、イベントログ監視した結果、ログフィルタまたはJSONログフィルタ、イベントログフィルタの条件に該当した場合、ログの内容がメッセージモニタに出力されます。

大量にメッセージが出力された場合に、パフォーマンスに影響を与えることがあります。

この場合、監視対象ログに出力されるログを減らすか、不要なメッセージが送信されないようにフィルタ条件を変更して下さい。

さらにメッセージを減らす必要がある場合に、以下の３つの方法があります。

• 1回の監視間隔において送信するメッセージ数の上限を設定することで、設定値を上回った分のメッセージを抑止する方法。 ログ監視による大量メッセージ出力を抑止したい場合の設定 を参照して下さい。

• メッセージIDごとに、1回の監視間隔において送信するメッセージ数を設定し、メッセージを抑止する方法。 ログ監視による大量メッセージ出力抑止の方法を変更したい場合の設定 を参照してください。

• まとめるメッセージの条件を事前に設定し、1回の監視間隔において、その条件に合うメッセージが複数あった場合に、それらを1メッセージとして出力する方法。

ここでは、上記3番目の複数メッセージを1メッセージの出力にまとめる場合について説明します。

注釈

• 上記1,2番目の設定を行っている環境に、3番目の設定を行った場合、3番の設定が優先されます。

説明

事前にログ監視機能の拡張設定ファイルに、メッセージを１つにまとめる条件を設定しておくことにより、同一監視間隔内に発生したメッセージに対して、該当のメッセージを1つにまとめることができます。

ログ監視機能の拡張設定ファイルには、複数の適用対象（ログ種別、フィルタ名、ノードID）を指定可能で、それぞれの提供対象ごとに、メッセージをまとめる条件を設定できます。

メッセージをまとめる条件は、以下のいずれかから1つを指定できます。

• 以下の項目が同一のメッセージを１つにまとめます。

  • メッセージID

  • メッセージIDとノードID

  • メッセージIDと付加文言

  • メッセージIDとノードIDと付加文言

• 以下の項目に対して、部分一致する文字列を指定し、まとめることもできます。

  • メッセージID

  • ノードID

  • 付加文言

• メッセージの付加文言の中で、指定したカラムの文字列が同一の場合に、まとめることもできます。

動作例

例として、メッセージIDでまとめるように設定した場合に、1回の監視にて発生したメッセージが、実際にどのようにメッセージ出力されるかを説明します。

ログ監視機能の拡張設定ファイル(logwatch_Extension.json)は以下の様に設定 各項目の説明は、下記の「設定手順」で説明します。

[
        {
                "filtertype" : "text",
                "filtername" : "TEXTLOGFIL01",
                "nodeId" : "node1",
                "type" : "compaction",
                "conditions" : "msgid",
                "additional" : true
        }
]

以下の表に、ノード"node1"のテキストログ監視に、"TEXTLOGFIL01"フィルタを使用してログ監視している監視対象ファイルに、1回の監視間隔での監視にて発生したメッセージを記します。

メッセージID	ノードID	メッセージの内容
TEST001	nodeA	(0000000001)AAA 111
TEST003	nodeA	(0000000002)BBB 222
TEST002	nodeB	(0000000003)CCC 111
TEST001	nodeC	(0000000004)DDD 222
TEST002	nodeB	(0000000005)EEE 222
TEST002	nodeA	(0000000006)FFF 333
TEST001	nodeA	(0000000007)GGG 111

メッセージIDでまとめるように設定した結果、実際に出力されるメッセージは以下の様になります。

メッセージID	ノードID	メッセージの内容
TEST001	nodeA	(集約済み)GGG 111(該当数:3,シーケンス番号範囲:0000000001-0000000007)
TEST002	nodeA	(集約済み)FFF 333(該当数:3,シーケンス番号範囲:0000000003-0000000006)
TEST003	nodeA	(0000000002)BBB 222

注釈

• メッセージを１つにまとめた際には、最後のメッセージのノードIDや内容がメッセージに使用されます。上記例の"TEST001"のメッセージは3つ該当しますが、一番最後のメッセージのノードID"nodeA"とメッセージの内容"GGG 111"がメッセージの内容に表示されます。

• "additional" : true に設定した場合は、メッセージの内容に、「シーケンス番号範囲」が表示されます。このシーケンス番号の範囲は、上記例の"TEST001"のメッセージでは「シーケンス番号範囲:0000000001-0000000007」と表示されていますが、0000000002番や0000000003番などは"TEST001"のメッセージではありません。これは、TEST001の先頭から末尾のシーケンス番号の範囲を表しているためで、該当していないシーケンス番号も含まれます。

• "additional" : false に設定した場合は、メッセージの内容に、「(集約済み)」や「(該当数:3,シーケンス番号範囲:0000000001-0000000007)」は表示されなくなります。

設定手順

1. 千手稼働アカウント権限

   千手エージェントや千手センサーのプローブとして設定された千手エージェントに千手稼働アカウントでログオンして下さい。

2. 設定ファイルの作成

   • 設定ファイル(ログ監視機能の拡張設定ファイル)

     • 設定する場合は、以下のサンプルファイルをコピーしてサンプルファイルと同一ディレクトリ内にlogwatch_Extension.jsonを作成します。

     • 設定ファイルはJSON形式で記載します。適用対象の（ログ種類、フィルタ名、ノードID）と、メッセージをまとめる条件の各項目を、任意の内容に変更します。

     • ログ監視機能の拡張設定ファイル(logwatch_Extension.json)、BOMなしのUTF-8で保存してください。

   • パス(格納位置)

     • $SENJUHOME/dat/anm/logwatch_Extension.json.sample(UNIX/Linux)

     • %SENJUHOME%datanmlogwatch_Extension.json.sample(Windows)

   • 各項目の説明

     • "filtertype"

       適用対象の監視対象のログの種類を指定します。 "text"、"json"、"event"のいずれかを設定します。

     • "filtername"

       適用対象のフィルタ名を指定します。 ログ監視やイベントログ監視の監視方法を設定します。

     • "nodeId"

       適用対象の千手エージェントや千手センサーのノードIDを指定します。 千手センサーを適用対象にする場合、プローブの設定ファイルに設定します。

     • "type"

       メッセージ抑止の種類を指定します。 常に"compaction"を指定します。

     • "conditions"

       メッセージをまとめる項目を指定します。以下4つの中から、1つを指定します。

       • "msgid" メッセージIDが同一のメッセージをまとめます

       • "msgid+nodeid" メッセージIDとノードIDが同一のメッセージをまとめます

       • "msgid+content" メッセージIDと付加文言が同一のメッセージをまとめます

       • "msgid+nodeid+content" メッセージIDとノードIDと付加文言が同一のメッセージをまとめます

     • "extensioncond"

       "conditions"では項目ごとにまとめますが、以下の条件でまとめる場合に"conditions"の替わりに指定します。("conditions"と"extensioncond"の両方を同時に指定できません)

       以下2つの中から、1つを指定します。

       • "{condition_type}:search:{keyword}"

         • 指定した項目内に、指定した文字列が含まれているかでメッセージをまとめます。

         • {condition_type}には、"msgid"、"nodeid"、"content"のいずれかを指定できます。

         • {keyword}には、{condition_type}に指定した項目の値から部分一致検索し、一致したメッセージをまとめます。

       • "content:index:{index}"

         • 付加文言内の指定したカラムが同一内容のもので、メッセージをまとめます。

         • {index}で何番目のカラムかを指定します。カンマで区切ることにより10件まで指定することができます。複数指定した場合は「and」条件となります。(indexは 0 が付加文言の 1カラム目となります。カラム数の範囲は0～20です。)

     • "delimiter"

       "extensioncond"で、"content:index:{index}"で指定した場合のカラムの区切り文字を指定します。

       省略時は、テキストログの場合は半角スペースとタブ文字、JSONログの場合はカンマ、イベントログの場合は半角スペースが区切り文字となります。

       対象ログ内で区切り文字が連続している場合は、１つの区切り文字と判断されます。

       複数指定可能です。"abc ,\t\n\r"の様に指定します。

     • "additional"

       メッセージをまとめた場合に、そのことをメッセージの付加文言に記述するかを指定します。

       • false 付加文言に記述しません

       • true 付加文言に記述します

3. ログ監視プロセスの再起動

   上記設定ファイルを保存後に、千手ブラウザのノードモニタより、"sjANM_logwatchd"プロセスを再起動して下さい。

注釈

• "sjANM_logwatchd"プロセス起動時に、ログ監視機能の拡張設定ファイル(logwatch_Extension.json)を読み込みますが、以下の通り異常時にはメッセージを表示しますので、設定ファイルを確認・訂正後、再度"sjANM_logwatchd"プロセスの起動時を行って下さい。

  • ファイルアクセス権限のエラーやJSONフォーマット不正エラーの場合は、「!ANM298 ログ監視機能の拡張設定ファイルの読み込みに失敗しました。」メッセージを表示します。

  • JSON内に必須の情報がないなどのエラーの場合は、「!ANM299 ログ監視機能の拡張設定ファイルの指定に誤りがあります。」メッセージを表示します。

  • 同一の適用対象("filtertype", "filtername", "nodeId")が複数存在する場合は、「!ANM303 ログ監視機能の拡張設定ファイル内に定義の重複があります。」メッセージを表示します。

4.5.2.8. 注意事項

• ログ監視の一時停止／再開コマンド(sjANM_stoplog/sjANM_startlog)で監視を一時停止し再開した際に監視対象ファイルへのアクセス権が無くなった場合、その後アクセス権が付与されたとき監視が再開される位置は、「停止位置から再開」を指定した場合はファイルの先頭から、「末尾から再開」を指定した場合はアクセス権が付与されたタイミングのファイルの末尾からになります。

• ログ監視の一時停止コマンド(sjANM_stoplog)で監視を一時停止した場合、監視対象ファイルの末尾までログ監視を行った後に監視を一時停止します。

• ログ監視では、ファイルサイズが前回の検査時点よりも減少している場合、「ファイルがシフトされた」と判断しファイルの先頭から監視を行います。しかし、シフト時に同じファイルの先頭より上書きする場合、検査間隔内に大量のログが出力されたことで前回検査時点よりもファイルサイズが大きくなったときは、ファイルの先頭からではなく前回のファイルサイズ以降のログが監視されます。ログを上書きしてシフトする場合は、検査間隔経過後にログを出力するなどの調整を行って下さい。

• ログ監視の監視対象ファイル名に正規表現を使用している場合に、正規表現にマッチするファイルのうちで監視対象となったファイルがフルパスで256バイトを超える場合、256バイトで切られたフルパスのファイル名で監視が行われます。一致するファイルが存在しない場合、「!ANM266監視するログファイルが存在しません。」メッセージが出力され、監視は行われません。一致するファイルがある場合は、監視が行われます。

• UNIX/Linux千手センサーのログ監視において、監視中は千手センサーとの接続状態の確認(ヘルスチェック)を実施しています。千手センサーとの接続が切れた場合、「!ANM287 監視対象ノードとの接続に失敗しました。」メッセージが出力され、監視が中断されます。千手センサーとの接続が復旧した場合、「!ANM267 ログファイルの監視を開始します。」メッセージが出力され、監視が再開されます。

• UNIX/Linux千手センサーのログ監視において、大量のログが出力された直後にログファイルがシフトされた場合、検査のタイミングによっては出力されたログの監視が完了する前に監視対象が新しいファイルに切り替わることがあります。大量にログが出力される場合は検査間隔を長めに設定するなどの調整を行って下さい。

• UNIX/Linux千手センサーのログ監視において、停止している千手センサー、telnetdの停止している千手センサー、sshdの停止している千手センサーの監視を実施すると、「!ANM287 監視対象ノードとの接続に失敗しました。」メッセージが出力され、監視は行われません。

• イベントビューアにて「ログの消去」を行う際に「保存と消去」を選択すると、その後に出力されたイベントログが検知されなくなります。

  「ログの消去」を行う際にはあらかじめ「イベントに名前をつけて保存」別途ログを保存した後、「ログの消去」で「消去」を選択してログを消去してください。なお、「保存と消去」を選択してログを消去したい場合には、以下手順で行ってください。

  1. 消去するイベントログの監視定義を削除し、反映(監視属性)を実行

  2. 「ログの消去」を「保存と消去」を選択して実施

  3. 消去したイベントログの監視定義を追加し、反映(監視属性)を実行

• Windowsの仕様により、ファイルの最終更新日時を記録する機能がデフォルトで無効となっています。このため、ファイルを削除して直ちにファイルを作成すると新しいファイルのタイムスタンプ(更新日時)は作成された日時ではなく削除されたファイルと同じ日時になります。（詳しくはマイクロソフト社にお問い合わせ下さい。）

  ログ監視の動作としては、正規表現にマッチするファイルの中で、ファイルのタイムスタンプが最新(同じ場合はファイル名の昇順で最後)の１つのファイルのログ監視を開始します。

• テキストログ監視では、32768文字(バイト)を超える内容のログ（行単位）の監視を読み飛ばさずに、32768文字（バイト）までの範囲で監視を行います。範囲の変更方法については、 テキストログ監視で、ログフィルタ検査を行う1行の範囲を変更したい場合の設定 を参照して下さい。

• テキストログ監視では、メッセージにログの内容を出力した際に、メッセージのログの内容に文字化けが発生する場合があります。これは、外字がログに含まれており、その部分が文字コード変換できていないためです。ログフィルタの定義にて、付加メッセージの出力内容を変更し、文字化けが発生する箇所を出力から外すようにすることで、文字化けがメッセージに表示されなくなります。

• JSONログ監視では、JSONのファイルの1行が65536文字(バイト)を超える場合、それ以降の行の内容は読み込まれません。そのため、JSONフォーマットが異常であると判断されるため「!ANM296 JSONログの解析に失敗しました。」メッセージが表示され、その行の監視は行われません。1行の範囲の変更方法については、 JSONログ監視で、1行の最大長を変更したい場合の設定 を参照して下さい。