15. ログ監視マニュアル

本書はX-MON4を用いたログ監視に関するリファレンスです。

基本的なOSやGUIの一般的な操作、用語などについては知識をご理解の上でお読みください。

また、X-MONの操作画面はお使いのOSやブラウザによって異なる場合がございます。

X-MONではログ監視を用いて、ログ（テキストファイル）内に指定の文字列が出現したことを検知できます。

ログ監視は３種類用意されています。

・ログ監視

X-MONサーバ自身のログを監視します。

監視するログファイルを任意に指定できます。

・NRPE経由でのログ監視

監視対象ホストのログをNRPEを用いて監視します。

監視するログファイルを任意に指定できますので、syslog転送出来ないアプリケーションのログも監視可能です。

・syslog管理

X-MONはsyslogサーバとしても動作しますので、監視対象ホストのsyslogをX-MONへ送って監視します。syslogのフォーマットは決まっていますので、プライオリティやファシリティ等をフィルターとして使用可能です。

syslogの設定によりX-MONに取り込まれるログが多くなる可能性もありますので、X-MONサーバの負荷は比較的高くなります。

15.1. ログ監視

監視グループ	チェックコマンド
ログ監視	ログ監視

X-MONサーバ内のテキストファイルに指定した文字列が出現するか監視します。

監視対象ファイルに指定した文字列が出現した場合、監視ステータスをCRITICALにします。監視対象ファイルが存在しない等正しく監視が実行できなかった場合、監視ステータスをUNKNOWNにします。

この監視では、「監視の詳細設定」タブ内の「試行回数」で「1」を入力して、指定した文字列が1度出現したらエスカレーションを実行するよう設定する必要があります。

また、必要に応じてサービス設定画面の「高度な設定」タブ内「volatileサービス」で「有効にする」を選択して、指定した文字列が出現する度にエスカレーションを実行するよう設定する必要があります。

■ ログ監視の設定について

altitude_reference_log01

15.1.1. ログの閲覧権限について

指定したログに対して、X-MONを実行するx-monユーザの読み取り権限が必要です。読み取り権限がない場合は適宜調整してください。

15.1.2. 設定項目一覧

項目	内容
対象ファイルパス	監視対象のテキストファイルのファイルパスを指定します。
一時ファイルパス	監視の際に生成する一時ファイルのファイルパスを指定します。
エラー文字列	検出したい文字列を指定します。監視対象のテキストファイルに指定した文字列が出現した場合、監視ステータスをCRITICALとします。

15.1.3. 監視設定例

例としてX-MONサーバの/var/log/messagesを監視対象とし、ログを比較するための一時ファイルのパスを/tmp/kanshi_messages_oldとします。

エラー文字列は「TEST」と指定します。

エラー文字列の指定は半角英数字で、大文字と小文字を区別します。

■ 監視設定例

altitude_reference_log4

監視の結果、1度でもエラー文字列を検知したら障害が確定するようにします。「volatileサービスの設定」は必要に応じて設定してください。

15.1.3.1. 試行回数の設定

対象サービスの監視設定画面にて、「監視の詳細設定」を開きます。デフォルトで試行回数は「３」になっていますので、「１」に変更します。

altitude_reference_log_retry

15.1.3.2. volatileサービスの設定

対象サービスの監視設定画面にて、「高度な設定」を開きます。この項目はデフォルトで「無効にする」となっていますので、必要に応じて「有効にする」へ変更します。

altitude_reference_log_volatile

設定が完了したら作成を行い、X-MONを再起動してください。

15.1.4. 監視結果例

ログ監視では比較に利用する一時ファイルを作成するため、サービス作成後の初回チェックのみ、ステータス情報が「Log check data initialized」となります。

■ 一回目の監視

altitude_reference_log_status

二回目以降は、前回のチェック以降に追記されたログのチェックが行われます。監視の結果、対象文字列が発見されなかった場合は下記のように「Log check ok - 0 pattern matches found」が表示されます。

■ 正常な場合

altitude_reference_log_status2

対象文字列を検知しCRITICALとなった場合は、下記のように検知した文字列を表示します。（セキュリティのため一部文字列を伏せております）

■ 異常の場合

altitude_reference_log_status3

対象のファイルに読み取り権限がない場合はUNKNOWNを検知します。

■ 権限がない場合

altitude_reference_log_status4

「ログの閲覧権限について」を参考に、監視対象ファイルへ読み取り権限を付与してください。

15.2. NRPE経由でのログ監視

監視グループ	チェックコマンド
ログ監視	NRPE経由でのログ監視

NRPEを利用して、監視対象ホストのテキストファイルに指定した文字列が出現するか監視を行います。

監視対象ファイルに指定した文字列が出現した場合、監視ステータスをCRITICALにします。監視対象ファイルが存在しない場合、監視ステータスをUNKNOWNにします。

この監視を設定する際には、サービス設定画面の「監視の詳細設定」タブ内「試行回数」に「1」を入力して、指定した文字列が1度出現したらエスカレーションを実行するよう設定する必要があります。

また必要に応じて、「高度な設定」タブ内「volatileサービス」で「有効にする」を選択して、指定した文字列が出現する度にエスカレーションを実行するよう設定する必要があります。

15.2.1. ログの閲覧権限について

NRPEを実行するユーザに、監視対象に指定されたログファイルの読み取り権限が必要です。

設定についてはNRPE導入手順 NRPE導入マニュアルをご参照ください。

15.2.2. 設定項目一覧

項目	内容
対象ファイルパス	監視対象ファイルのパスを指定します。
一時ファイルパス	監視の際に生成する一時ファイルのパスを指定します。
エラー文字列	検知する文字列を指定します。監視対象のテキストファイルに指定した文字列が出現した場合、監視ステータスをCRITICALとします。
NRPEタイムアウト(秒)	監視対象ホストから指定した秒数以上応答がない場合チェックを終了し、監視ステータスをCRITICALにします。

15.2.3. 監視設定例

例として監視対象ホストの/var/log/httpd/error_logを監視対象とします。ログを比較するための一時ファイルのパスを/tmp/httpd_errorとします。

エラー文字列には、「error」を指定します。

エラー文字列の指定は半角英数字で、大文字と小文字を区別します。

■ 監視設定例

altitude_reference_nrpelog_sample

監視の結果、1度でもエラー文字列を検知したら障害が確定するようにします。「volatileサービスの設定」は必要に応じて設定してください。

15.2.3.1. 試行回数の設定

下にある「監視の詳細設定」を開きます。ログ監視ではデフォルトの試行回数は「３」になっていますので、「１」に変更します。

altitude_reference_nrpelog_sample2

15.2.3.2. volatieサービスの設定

下にある「高度な設定」を開きます。デフォルトでは「無効」になっていますので、必要に応じて「有効」へ変更します。

altitude_reference_nrpelog_sample3

設定が完了したら作成を行い、X-MONを再起動してください。

15.2.4. 監視結果例

ログ監視では比較に利用する一時ファイルを作成するため、サービス作成後の初回チェックのみ、ステータス情報が「Log check data initialized」となります。

■ 一回目の監視

altitude_reference_nrpelog_status

二回目以降は、前回のチェック以降に追記されたログのチェックが行われます。正常に監視がOKの場合は下記のように「Log check ok - 0 pattern matches found」が表示されます。

■ 正常な場合

altitude_reference_nrpelog_status2

異常を検知しCRITICALとなった場合は下記のように検知した文字列を表示します。（セキュリティのため一部文字列を伏せております）

■ 異常の場合

altitude_reference_nrpelog_status3

対象のファイルに読み取り権限がない場合はUNKNOWNを検知します。

altitude_reference_nrpelog_status4

別途マニュアル「 NRPE導入マニュアル」をご参照ください。

15.3. 「ログ監視」及び「NRPEによるログ監視」の特徴

15.3.1. ログ監視のステータス情報について

ログ監視にて監視対象文字列を複数行検知した場合、ステータス情報の先頭に行数を表示しますが、ログそのものは1行しか表示されません。

そのため、ログ監視で障害を検知した場合は行数を確認し、必要に応じて監視ホストにてログを確認いただくようお願いします。

■ １行だけ検知している場合

altitude_reference_nrpelog_status5

■ 複数行検知している場合

altitude_reference_nrpelog_status6

また、下記のようなメッセージでUnknownを検知する場合があります。

CHECK_NRPE: Received 0 bytes from daemon. Check the remote server logs for error messages.

この場合は、サービス登録時の「検知文字列」に、検知対象に使用出来ない文字が含まれているため、監視ホストのNRPEプラグインでエラーが発生しています。

現状、X-MONの仕様により記号や漢字を検知文字列に指定しても入力エラーにならずに監視が登録出来てしまいます。大変恐縮ですが、検知文字列は半角英数字のみで指定してください。

15.3.2. ログ監視の正規表現について

ログ監視で検知文字列を指定する際、以下の正規表現が使用できます。

項目	内容
. (半角ドット)	任意の一文字
* (半角アスタリスク)	0回以上の繰り返し

15.3.2.1. ログでuserXXからアクセスがあった場合に検知する

サーバへのsshd接続やwebサービスで特定のユーザからアクセスがあった場合に障害としたい例です。user01やuser35などuserの後に数字が入ることが分かっていれば、検知文字列に「user*」とすることで検知できます。

「user3*」とすると「user300」など、３から始まるユーザ番号を検知できます。

15.3.2.2. 行に対するAnd検索

「.」と「*」を組み合わせると特定の1行に対してand検索が可能です。

例として下記のようなログがあるとします。

Dec 13 16:40:44 x-mon_manual xinetd[1085]: START: nrpe pid=22834 from=::ffff:192.168.19.201

Dec 13 16:40:44 x-mon_manual nrpe[22834]: Error: Request contained illegal metachars!

Dec 13 16:40:44 x-mon_manual nrpe[22834]: Client request was invalid, bailing out...

Dec 13 16:40:44 x-mon_manual xinetd[1085]: EXIT: nrpe status=0 pid=22834 duration=0(sec)

Dec 13 16:41:01 x-mon_manual xinetd[1085]: START: nrpe pid=22837 from=::ffff:192.168.19.201

このログの中から

Dec 13 16:40:44 x-mon_manual nrpe[22834]: Error: Request contained illegal metachars!

の行だけを検知させる場合、検知文字列として「nrpe.*Error」を指定します。

これにより、「nrpe」の文字列を検知した行に対して、その行の文字列nrpe以降に「Error」の文字列も検索し、一致した場合のみ障害を検知します。

この際、検知文字列の指定順に気を付ける必要があります。「Error.*nrpe」とした場合は、文字列「Error」を検知した行の「Error」以降を検索しますので、上記例のログでは検知しません。

15.4. syslog管理

syslog管理はX-MONをsyslogサーバにして、監視ホストからログを転送します。転送されてきたログに指定した文字列を検出した場合、予め指定したステータスを通知します。

その他のログ監視２種と比較して、複雑な正規表現の使用や複数の検知条件を指定できます。

また検知した際のステータスの種類も選択できるため、「検知すればCRITICAL(障害)」という条件と「検知すればOK(復旧)」を組み合わせると、自動で監視を復旧をさせるといったことも可能です。

15.4.1. ログ転送設定

altitude_reference_syslog

フィルターはrsyslogが実施するので、X-MONに登録されるサービスはパッシブチェック監視となります。

X-MONサーバではsyslog管理としてrsyslogを使用しています。

ここでは監視ホスト側のsyslog管理もrsyslogを例に使用します。ネットワーク機器のログ転送方法については各機器のマニュアルをご参照ください。

15.4.1.1. X-MONサーバ（転送先）の設定

X-MONではrsyslogを利用しています。

X-MONサーバのファイアウォール機能や監視経路中のファイアウォール機器にてポート制限を実施している場合は、下記ポートを許可してください。

TCP/UDP 514番

15.4.1.2. 監視ホスト（転送元）の設定

rsyslogの設定でX-MONサーバへログを転送する設定を登録し、rsyslogサービスを再起動します。

設定ファイルは/etc/rsyslog.conf、もしくは/etc/rsyslog.d/以下のファイルとなります。

下記は全てのログをX-MONサーバ(IPアドレスが192.0.2.1の場合）へ転送する設定です。（#はコメント行です）

#to X-MON

*.* @192.0.2.1

TCPを使って転送する場合は@を二つにしてください。また、明示的にポート番号を記載する場合はIPアドレスの後ろに「:」を付けてポート番号を記載してください。（#はコメント行です）

#to X-MON

*.* @@192.0.2.1:514

特定のログを転送する場合はファシリティ、プライオリティを設定し記載してください。例としてauthpriv.infoのみを転送する場合は下記のようになります。（#はコメント行です）

#to X-MON

authpriv.info @192.0.2.1

15.4.1.3. syslog転送設定時の注意点

rsyslogでは出力フォーマットをカスタマイズできます。

カスタマイズした出力フォーマットのままX-MONサーバへログを転送すると正常に検知しない場合がございます。

そのため、監視ホストでログの出力フォーマットをカスタマイズしている場合はX-MONサーバへ転送するログの出力フォーマットをrsyslogのデフォルトのフォーマットとなるように指定してください。

フォーマットの種類は「RSYSLOG_TraditionalFileFormat」を指定し、X-MONサーバのIPアドレス、もしくはポート番号の後ろに「;」を付けて記載します。

例：すべてのログを192.0.2.1のX-MONサーバのTCP/514番ポートへRSYSLOG_TraditionalFileFormatを指定して転送する

#to X-MON

*.* @@192.0.2.1:514;RSYSLOG_TraditionalFileFormat

15.4.1.4. ログ転送の確認

ログが正常に転送されているか確認してみましょう。

監視ホストで次のコマンドを発行し、監視ホストとX-MONサーバの/var/log/messagesをそれぞれ確認します。

# logger -i -t TEST -p user.warning "X-MON"

次のようなログが両サーバに記録されていれば、正常にログ転送が行われています。

Dec 20 16:27:09 man-x64 TEST[1401]: X-MON

15.4.1.5. X-MONでのログ検出の範囲

監視対象サーバからX-MONサーバへ転送されたログは、全てsyslog管理の監視対象となります。

検知させたくないログが含まれる場合や転送されるログ量が膨大な場合など、必要に応じてログ転送条件を絞り込んでいただくことをお勧めします。

15.4.2. syslog管理画面

syslog管理では通常の監視の追加方法とは異なり、syslog管理という独立したメニューが用意されています。

altitude_reference_syslog_menu

また、ログの検知方法としてプロパティベースフィルター、式ベースフィルターの２種類があります。

15.4.2.1. 新規作成

syslog通知条件一覧が開きます。

altitude_reference_syslog_menu2

何も設定していない場合は何も表示されません。

新規作成をクリックして、監視設定の作成を行います。検知するログの条件は、設定項目「フィルター」で設定します。

altitude_reference_syslog_menu3

項目	内容
登録ログ条件名	登録するログ通知条件コードの任意のIDを入力します。新規作成時のみ設定が可能であり、変更はできません。入力制限：入力必須、半角英数字、アンダーバー、ドット、ハイフンのみ、重複する名称の登録不可。
フィルター	フィルターをプロパティベースフィルター、式ベースフィルターから選択します。フィルターによって入力項目が変わります。
対象ホスト	検索対象となるホストを選択します。選択したいホストの頭文字を選択し、表示された選択肢からホストを選択し、選択ボタンをドラッグアンドドロップします。ホストを除外する場合は、任意のホストを選択後、選択ボタンをドラッグアンドドロップします。
通知先サービス名	ここで指定した名前で、対象ホストにサービスが登録されます。入力制限：入力必須、半角英数字、アンダーバー、ドット、ハイフンのみ。
通知ステータス	エスカレーションを実行する際に発行するステータスを選択します。

「登録ログ条件名」はsyslog管理画面に一覧で表示される名前です。

X-MONのサービス一覧表示などで表示させた際は「通知先サービス名」が使用されます。これらを同じ名前にしておくと視認性が向上します。

15.4.2.2. プロパティベースフィルター

単純な文字列、指定するファシリティやプライオリティを検知する場合はプロパティベースフィルターをお勧めします。

syslog管理では、指定文字列の検索範囲は行単位です。

そのため、or検索では、指定した単語が出た時点で検知します。

and検索をする場合は、一つ目に指定した単語が出現した時点で、その行に他の単語があるかを検索します。

altitude_reference_syslog_menu4

項目	内容
対象	検索する対象を選択します。選択された対象に検索文字列が含まれていた場合、通知を行います。ファシリティ、プライオリティ、メッセージ、タグが選択できます。
条件否定	「対象」に指定した条件を否定するか設定します。条件を否定しない場合、「なし」を選択します。
比較内容	指定した文字列の検索方法を選択します。部分一致、完全一致、前方一致、正規表現が選択できます。
詳細内容/正規表現	検索文字列を入力します。「比較内容」で正規表現を選択した場合、正規表現を入力します。

15.4.2.3. 式ベースフィルター

式ベースフィルターでは、複数の検索条件を設定できます。検索条件は「パネル」に登録し、パネルの組み合わせで複雑な検索条件を指定できます。

いずれかの条件に一致すれば検知したい(or検索)場合は、同じパネル内に条件を追加していきます。

全ての条件に一致した場合のみ検知したい(and検索)場合は、別のパネルに条件を追加します。

syslog管理では、指定文字列の検索範囲は行単位です。

式ベースフィルターの場合、設定により行全体での比較も可能です。

式ベースフィルターで設定する項目は、左端から、検索項目、検索内容、条件指示です。検索項目の説明は以下のとおりです。

altitude_reference_syslog_menu5

項目	内容
ファシリティ	ファシリティのステータスで条件を設定します。任意のステータスを選択し、そのステータスと一致するか一致しないかを選択します。
プライオリティ	プライオリティのステータスで条件を設定します。任意のステータスを選択し、そのステータスと一致するか一致しないかを選択します。
メッセージ	メッセージの内容で条件を設定します。入力文字列とメッセージが一致するかしないかを選択します。
タグ	syslogタグの内容で条件を設定します。タグが入力文字列と一致するか一致しないかを選択します。

15.4.3. 監視設定例（プロパティベースフィルター）

下記のサンプルネットワークを利用し、プロパティベースフィルター形式を例として解説を行います。

■ サンプルネットワーク

altitude_reference_syslog_property

※ 通知の設定はエスカレーション設定マニュアルをご参照ください。

15.4.3.1. 新規作成

[管理者メニュー]の[syslog管理]と進んで[新規作成]を開き、条件を入力します。

altitude_reference_syslog_formula3

下記の条件で設定してみます。

項目	内容
登録ログ条件名	LOG_X-MON-TEST01
対象	メッセージ
条件否定	なし
比較内容	完全一致
詳細内容/正規表現	X-MON-TEST
対象ホスト	ログサーバ01
通知先サービス名	LOG_X-MON-TEST01
通知ステータス	CRITICAL

■ 入力例

altitude_reference_syslog_property4

入力が完了したら一番下の[作成と承認] で反映後、X-MONを再起動します。

15.4.3.2. 確認

設定出来たか確認してみましょう。

syslog管理を開くと作成したLOG_X-MON-TEST01があります。

altitude_reference_syslog_property5

詳細表示を開くと設定が確認できます。

altitude_reference_syslog_property6

サービス一覧表示を見てみましょう。

altitude_reference_syslog_property7

監視が追加されています。

syslog管理では、X-MONサーバへ転送されてきたログをrsyslogがフィルターし、条件に合致するログを検知した場合はX-MONへ通知します。

この動作により、監視は パッシブチェックとなります。そのため画像のように「このサービスはチェックするようにスケジュールされていません。」となります。

15.4.3.3. 検知テスト

それでは検知するかテストしてみましょう。

監視ホスト側で下記コマンドを発行します。

# logger -i -t TEST -p user.warning "X-MON-TEST"

発行後サービス一覧表示画面を開くとCRITICALを検知していますので、正常に検知できたことが分かります。

altitude_reference_syslog_property8

15.4.3.4. 監視を復旧させる

手動で監視を復旧させるには手動で「パッシブチェックの結果を送信」します。

サービス一覧表示の監視名を開き、「このサービスのパッシブチェックの結果を送信」アイコン(以下画像赤枠部分)をクリックします。

altitude_reference_syslog_property10

下記のような画面となります。

altitude_reference_syslog_property12

チェック結果をOKにします（デフォルトで選択されています）。

チェック出力は任意ですが、サービスのステータス情報欄に表示されますので、例えば「ログ検知テストのためOK」や実際の運用では「ログ確認、対応完了」などを記載するといいでしょう。

altitude_reference_syslog_property13

入力出来たら実行を押すと、コマンドを正常に受け付けた画面となります。

altitude_reference_syslog_property15

サービス一覧表示画面を確認すると、ステータス情報が先ほど入力した「ログ検知テストのためOK」となり、正常（OK）で復旧しています。

altitude_reference_syslog_property16

以上が基本的な設定例とテストとなります。

15.4.4. プロパティベースフィルターの入力項目詳細

15.4.4.1. 「対象」の設定例

検知対象について、個別に設定例を記載します。

altitude_reference_syslog_property18

対象は図のようにファシリティ、プライオリティ、メッセージ、タグの中から選択できます。

ファシリティの一覧は下記の通りです。

kern

user

mail

daemon

auth

syslog

lpr

news

uucp

cron

authpriv

ftp

ntp

audit

clock

alert

local0～7

また、プライオリティの一覧は下記の通りです。

emerg

alert

crit

err

warn

notice

info

debug

メッセージとタグは任意の文字列を指定します。

どちらも[詳細内容/正規表現]の欄に、手動で検知文字列を指定する必要がありますので、スペル間違いにはご注意ください。

また、loggerコマンドでのテスト時、監視ホスト上で発行するコマンドオプションにファシリティとプライオリティを指定しても、転送されたX-MONサーバ上では違う値になる場合があります。

例えば、監視ホストにて、ファシリティにuser、プライオリティにwarningを指定した次のコマンドを発行します。

# logger -i -t TEST -p user.warning "X-MON-TEST"

監視ホスト上では下記のように出力されます。※(分かりやすいようにログ出力フォーマットをカスタマイズしています)

Dec 29 21:49:32 man-x64 TEST[1370]: [user.warning] : X-MON-TEST

しかし、X-MONサーバでは下記のようにプライオリティがnoticeとなります。

Dec 29 21:49:32 man-x64 TEST[1370]: [user.notice] : X-MON-TEST

そのため、サービスやアプリケーションでログを確認する際は、X-MONサーバ上でどのようにログが転送されているかも確認するようにしてください。

15.4.4.2. 「条件否定」の設定例

「条件否定」について個別に設定例を記載します。

altitude_reference_syslog_property19

条件否定は[詳細内容/正規表現]の記述内容の否定を検知対象とします。イメージとしては、それ以外が対象となる形です。

注意点として、[対象]をメッセージにしている場合、記述内容の否定になってしまうため検知する内容が多くなってしまいます。

そのため、ファシリティ、プライオリティに対する否定で使用する事をお勧めします。

例：daemon以外のファシリティを検知する。

■ 設定例

altitude_reference_syslog_property20

15.4.4.3. 「比較内容」の設定例

「比較内容」について個別に設定例を記載します。

altitude_reference_syslog_property21

比較内容は下記４つを選択できます。

部分一致

完全一致

前方一致

正規表現

・部分一致

指定した文字列を検索し、一部分でも合致した場合に検知します。

例えば、「X-MON-TEST」というメッセージを検知したい場合に「N-TES」と指定すれば検知できます。

altitude_reference_syslog_property22

・完全一致

指定した文字列と完全に一致する文字列を検知します。

例えば、「X-MON-TEST」というメッセージを検知したい場合に「X-MON-TEST」と指定すれば検知できます。

altitude_reference_syslog_property23

完全一致のため、「X-MON-TEST-ERROR」というメッセージに対して「X-MON-TEST」を指定しても検知はされません。その場合は部分一致もしくは前方一致を使用します。

・前方一致

指定した文字列の先頭から一致する部分が存在した場合に検知します。

例えば、「X-MON-TEST」というメッセージを検知したい場合に「X-MON」と指定すれば検知できます。

altitude_reference_syslog_property24

・正規表現

正規表現で検索し検知します。

一般的に多く用いられる「？」「＊」「＋」「 . 」、論理和である「｜」も使用できます。

また、先頭を表す「~」や文末の「$」も使用できます。

例：ファシリティがkernもしくはuserの場合に検知する場合は「kern|user」とします。

altitude_reference_syslog_property25

例：メッセージで「success」で終わる場合を検知するには「success$」とします。

altitude_reference_syslog_property26

例：AND検索（論理積）をしたい場合も正規表現で実現できます。

「 ^(?=.*文字列)(?=.*文字列).*$ 」を使います。たとえば、X-MONとTESTでAND検索したい場合は「 ^(?=.*X-MON)(?=.*TEST).*$ 」とします。ログの各行に対してAND検索を実行しますので、まず「X-MON」という文字列を検索し、更に該当行に文字列「TEST」が存在すれば検知する、という形となります。

altitude_reference_syslog_property27

実際の運用において、条件を複数設定したり正規表現を使用する場合は、事前に検証を行い、正常に検知されるか確認いただくことを推奨いたします。

15.4.5. 監視設定例（式ベースフィルター）

式ベースフィルター形式について、下記のサンプルネットワークを用いて解説を行います。

■ サンプルネットワーク

altitude_reference_syslog_formula

※ 通知の設定はエスカレーション設定マニュアルをご参照ください。

15.4.5.1. 新規作成

[管理者メニュー]の[syslog管理]内の[新規作成]を開き、条件を入力します。

altitude_reference_syslog_menu

altitude_reference_syslog_formula3

下記の条件で設定してみます。

項目	内容
登録ログ条件名	LOG_X-MON-TEST02
検索項目	メッセージ
検索内容	X-MON-TEST
条件指示	一致する
対象ホスト	ログサーバ02
通知先サービス名	LOG_X-MON-TEST02
通知ステータス	CRITICAL

式ベースフィルターでは、パネルを使って条件を作成します。

まずは、パネルに条件を追加します。「このパネルに条件を追加」を実行します。

altitude_reference_syslog_formula4

条件が追加されました。

altitude_reference_syslog_formula5

1パネルが1つの条件となります。例にそって入力します。

altitude_reference_syslog_formula6

altitude_reference_syslog_formula7

入力が完了したら一番下の[作成] で反映後、X-MONを再起動します。

15.4.5.2. 確認

設定出来たか確認してみましょう。

syslog管理を開くと作成したLOG_X-MON-TEST02があります。

altitude_reference_syslog_check

詳細表示を開くと設定が確認できます。

altitude_reference_syslog_check2

サービス一覧表示を見てみましょう。

altitude_reference_syslog_check3

監視が追加されています。

syslog管理では、X-MONサーバへ転送されてきたログをrsyslogがフィルターし、条件に合致するログを検知した場合はX-MONへ通知します。

この動作により、監視は パッシブチェックとなります。そのため画像のように「このサービスはチェックするようにスケジュールされていません。」となります。

15.4.5.3. 検知テスト

それでは検知するかテストしてみましょう。

監視ホスト側で下記コマンドを発行します。

# logger -i -t TEST -p user.warning "X-MON-TEST"

発行後サービス一覧表示画面を開きます。下記画像のようにCRITICALを検知しました。

altitude_reference_syslog_check4

正常に検知出来ている事が分かりました。

15.4.5.4. 監視を復旧させる

手動で監視を復旧させるには手動で「パッシブチェックの結果を送信」します。

サービス一覧表示の監視名を開き、「このサービスのパッシブチェックの結果を送信」アイコン(以下画像赤枠部分)をクリックします。

altitude_reference_syslog_check6

下記のような画面となります。

altitude_reference_syslog_check8

チェック結果をOKにします（デフォルトで選択されています）。

チェック出力は任意ですが、サービスのステータス情報欄に表示されますので、例えば「ログ検知テストのためOK」や実際の運用では「ログ確認、対応完了」などを記載するといいでしょう。

altitude_reference_syslog_property13

入力出来たら実行を押すと、コマンドを正常に受け付けた画面となります。

altitude_reference_syslog_property15

復旧しているか確認しましょう。

サービス一覧表示にて、ステータス情報が先ほど入力した「ログ検知テストのためOK」というステータスとなり正常（OK）で復旧しています。

altitude_reference_syslog_check12

以上が基本的な設定例とテストとなります。

15.4.6. 式ベースフィルターの入力項目詳細

式ベースフィルターでの検索項目は以下の４種となります。

ファシリティ

プライオリティ

メッセージ

タグ

altitude_reference_syslog_check14

それぞれの検索項目について次項より解説します。

15.4.6.1. ファシリティ

検索項目でファシリティを選択すると条件欄が下記のようになります。

altitude_reference_syslog_setitem

検索内容が選択BOXとなります。選択肢は以下表の通りです。

kern

user

mail

daemon

auth

syslog

lpr

news

uucp

cron

authpriv

ftp

ntp

audit

clock

alert

local0～7

レベルが高いものが上に表示されます。

条件指示は以下４種です。

一致する

以外

より大きい

より小さい

・一致する

選択したファシリティと一致する場合に検知します。

・以外

選択したファシリティと一致しない場合に検知します。

・より大きい/より小さい

選択したファシリティより大きいレベルまたは小さいレベルの場合に検知します。（選択したファシリティは含みません）

■ 設定例

ファシリティをdaemonより大きい、と設定する場合は下記のようになります。

altitude_reference_syslog_setitem2

この場合はdaemonより上位レベルのkern、user、mailのファシリティが検知対象となります。

15.4.6.2. プライオリティ

検索項目でプライオリティを選択すると条件欄が下記のようになります。

altitude_reference_syslog_priority

検索内容が選択BOXとなります。選択肢は以下表の通りです。

emerg

alert

crit

err

warn

notice

info

debug

レベルが高いものが上に表示されます。

条件指示は以下４種となります。

一致する

以外

より大きい

より小さい

・一致する

選択したプライオリティと一致する場合に検知します。

・以外

選択したプライオリティと一致しない場合に検知します。

・より大きい/より小さい

選択したプライオリティより大きいレベルか小さいレベルかの場合検知します。（選択したものは含みません）

■ 設定例

プライオリティがCRITに一致する、と設定する場合は下記のようになります。

altitude_reference_syslog_priority2

15.4.6.3. メッセージ

検索項目でメッセージを選択すると条件欄が下記のようになります。

altitude_reference_syslog_mess

検索内容は記入欄となります。

条件指示は以下４種となります。

一致する

一致しない

含める

含まない

・一致する

入力した文字列とメッセージ全体が一致した場合に検知します。

例えば、指定文字列を"X-MON-TEST"とした場合、メッセージが"X-MON-TEST"と完全に一致した場合のみ検知します。そのため、"X-MON-TEST WARNING"というメッセージの場合は検知しません。

サービスによる複雑なメッセージであっても一致するかどうかを判別できます。

・一致しない

入力した文字列とメッセージ全体が一致しない場合に検知します。

・含める

入力した文字列がメッセージ内に含まれる場合に検知します。

例えば、指定文字列を"X-MON-TEST"とした場合、メッセージが"X-MON-TEST”でも"X-MON-TEST WARNING"の場合でも検知します。

・含まない

入力した文字列がメッセージに含まれない場合に検知します。

■ 設定例

メッセージに「X-MON-TEST」を含むと検知する場合は下記のように設定します。

altitude_reference_syslog_mess2

15.4.6.4. タグ

検索項目でタグを選択すると条件欄が下記のようになります。

altitude_reference_syslog_tag

検索内容は記入欄となります。

条件指示は以下４種となります。

一致する

一致しない

含める

含まない

・一致する

入力した文字列とタグが完全に一致した場合に検知します。

例えば、指定文字列を"ssh"とした場合、タグ"ssh"と一致した場合のみ検知します。そのため、"sshd"というタグは検知しません。

・一致しない

入力した文字列とタグが一致しない場合に検知します。

・含める

入力した文字列がタグに含まれる場合に検知します。

例えば、指定文字列を"ssh"とした場合、タグが"ssh"でも"sshd"でも検知します。

・含まない

入力した文字列がタグに含まれない場合に検知します。

■ 設定例

タグに「ssh」を含むと検知する場合は下記のように設定します。

altitude_reference_syslog_tag2

15.4.7. パネルを追加して複数の条件を設定する

条件を追加する（パネルを追加する）と、and条件とor条件を設定できます。

15.4.7.1. and検索

例えば、メッセージに「X-MON-TEST」を含み、かつファシリティが「user」の場合に検知する条件を設定してみます。

まずは新規作成から、条件パネルを追加しメッセージの条件を入力します。

altitude_reference_syslog_and

そしてパネルの操作盤から「新しい条件パネルを横に追加(and条件)」を選択し実行します。

altitude_reference_syslog_and2

and条件用の条件パネルが追加されました。

altitude_reference_syslog_and3

２つの条件パネルがあり真ん中にandと表示されます。これでこの２つがand条件となることを意味しています。

入力パネルに条件を入力します。

■ 設定例

altitude_reference_syslog_and6

入力が完了すれば登録ログ条件名や通知ステータスを設定しましょう。

以上でand検索での設定は完了です。

15.4.7.2. or検索

例えば、メッセージに「X-MON-ERROR」を含むか、またはファシリティが「daemon」の場合に検知する条件を設定してみます。

まずは新規作成から、条件パネルを追加しメッセージの条件を入力します。

altitude_reference_syslog_or

そしてパネルの操作盤から「このパネルに条件を追加（or条件)」を選択し実行します。

altitude_reference_syslog_or2

or条件用の条件入力パネルが追加されました。

altitude_reference_syslog_or3

２つの条件入力パネルが並んでおり、これでこの２つがor条件となることを意味しています。入力パネルに条件を入力します。

■ 設定例

altitude_reference_syslog_or4

入力が完了すれば登録ログ条件名や通知ステータスを設定しましょう。

以上でor検索での設定は完了です。

15.4.8. 複雑な条件設定

パネルを追加することで、より複雑な条件での検索も可能となります。

次のような検索条件を例として扱います。

・プライオリティが「ALERT」と一致するか、またはタグ「X-MON」と一致、かつファシリティが「user」と一致し、更にメッセージに「ERROR」を含む場合に検知する。

この条件を、||（or）と&&（and）を使って式で表してみます。

((プライオリティ=ALERT || タグ=X-MON)&&ファシリティ=user)&&メッセージ=ERROR

複雑な条件の場合は、式の内側括弧から設定していくイメージが分かりやすいでしょう。

それでは、上記の例を実現するよう設定していきます。

まずは、プライオリティが「alert」、もしくはタグが「X-MON」の場合を作成します。

新規作成から条件パネルを追加します。１行目にプライオリティに関する条件を入力した後、「このパネルに条件を追加（or条件)」を実行して、タグに関する条件を追加します。

altitude_reference_syslog_complex

これで式の内側括弧部分が作成出来ました。

( (プライオリティ=ALERT || タグ=X-MON) &&ファシリティ=user)&&メッセージ=ERROR

次に、この条件に対するand条件として、ファシリティが「user」と一致する条件のパネルを追加します。

「新しい条件パネルを下に追加（and条件）」で条件パネルを追加し、設定例の通りに条件を入力します。

altitude_reference_syslog_complex2

これで式の外側括弧部分が作成出来ました。

((プライオリティ=ALERT || タグ=X-MON)&&ファシリティ=user) &&メッセージ=ERROR

残りは、設定済の全ての条件に対して、メッセージが「ERROR」を含むand条件となります。ただし、このまま条件パネルを追加すると、ここまでで追加した「プライオリティが「ALERT」と一致するか、またはタグ「X-MON」と一致する」及び「ファシリティが「user」と一致する」に対するand条件となってしまいます。

(プライオリティ=ALERT || タグ=X-MON)&&ファシリティ=user&&メッセージ=ERROR

■ 間違ったand条件の追加

altitude_reference_syslog_complex3

そのため、式の外側括弧部分を「グループ化」することで条件をまとめます。

操作盤にて「この条件と同じ階層のパネルをgroup化する」を実行します。

altitude_reference_syslog_complex4

これで「プライオリティが「ALERT」と一致するか、またはタグ「X-MON」と一致する」及び「ファシリティが「user」と一致する」条件がグループ化された状態となります。

altitude_reference_syslog_complex5

このグループにand条件のパネルを追加すると、グループ化した部分とand条件が設定できます。

altitude_reference_syslog_complex6

追加したパネルに、メッセージが「ERROR」を含む条件を入力することで、設定例が完成しました。

■ 設定例

altitude_reference_syslog_complex7

altitude_reference_syslog_complex72

このようにして、複雑な条件でも内側括弧部分から作成していくことで実現できます。

また、括弧の外側部分から式を作成していく場合は、「この条件の下にパネルを追加」を実行します。

altitude_reference_syslog_complex8

altitude_reference_syslog_complex9

最終的には同じ設定が登録できますので、使いやすい方をご利用ください。

15.4.8.1. 注意点

式ベースフィルター形式を使用する上での注意点をまとめています。

15.4.8.2. 不要なパネルを追加した場合

誤ってパネルを追加してしまった場合は、パネルを削除できます。

条件パネルの場合は選択BOXから「この条件パネルの削除」を選んで実行します。

■ 削除前

altitude_reference_syslog_mis

■ 削除後

altitude_reference_syslog_mis2

しかし、複雑な条件の設定中に誤った操作をしてしまった場合は、パネルの境界が分かりにくいため特に注意して実行してください。

現在のX-MONでは「１つ前に戻る」機能は搭載されておりません。

実行する操作盤を囲っている範囲が対象パネルとなります。下記画像では各色で囲っている範囲となります。

■ 複雑な条件

altitude_reference_syslog_mis3

実際の運用時に、ログ検索条件を複数設定したり正規表現を利用する場合は、事前に監視環境にて検証を行い、正常に検知されるか確認いただくことを推奨いたします。

15.4.9. syslog管理の共通操作

プロパティベースフィルター、式ベースフィルターで共通の設定動作を解説します。

例や画像はプロパティベースフィルターが主になっていますが、式ベースフィルターでも共通です（一部用語もプロパティベースフィルターに合わせていますが、ベースは同じです）。

15.4.9.1. 通知条件を編集する

一度登録した設定を編集できます。後述の「複数ホストへ同一の通知条件を設定」している場合、一括で設定が変更されます。

[管理者メニュー]の[syslog管理]から対象の条件の「詳細表示」を開きます。

altitude_reference_syslog_property5

設定の詳細が表示されますので、下のメニューの編集ボタンを開きます。

altitude_reference_com_edit2

編集が可能となりますので、編集を実施します。

■ 編集（プロパティベースフィルター）

altitude_reference_com_edit3

■ 編集（式ベースフィルター）

altitude_reference_com_edit4

この際、フィルター部分のみの編集であればX-MONの再起動は不要です。

その他の項目を編集すると反映のためX-MONの再起動が必要となりますので、X-MONの再起動を実施してください。

15.4.9.2. 通知条件を削除する

条件の削除は編集と同じく詳細表示から実施できます。こちらも、「複数ホストへ同一の通知条件を設定」している場合は一括で設定が削除されます。

[管理者メニュー]の[syslog管理]から対象の条件の「詳細表示」を開きます。

altitude_reference_syslog_property5

設定の詳細が表示されますので、下のメニューの削除ボタンを開きます。

altitude_reference_com_del2

削除の確認が出ますので、問題なければOKボタンを押してください。

altitude_reference_com_del3

OKを押すと「設定を削除し反映しました。」と表示されます。

反映にはX-MONの再起動が必要ですので、X-MONを再起動してください。

altitude_reference_com_del4

15.4.9.3. サービス設定から削除する

[syslog管理]メニューではなく、[ホスト管理] の[サービス設定]からも通知条件を削除できます。この場合は操作したホストのサービスのみ削除されます。

また、通知先に登録されていたサービスが全て削除されると、通知条件も削除されます。

該当のホストでサービス設定を開いて一覧を表示します。

削除するサービスのチェックボックスにチェックを入れて[削除と承認]を押します。

altitude_reference_com_del5

確認ウィンドウが出ますので、問題なければOKを押してください。

altitude_reference_com_del6

「設定を削除し反映しました。」と表示されますのでX-MONを再起動してください。

altitude_reference_com_del4

以上が通知条件の削除方法となります。

15.4.9.4. 複数の通知条件を同じサービスに設定する

複数の通知条件を単一サービスに設定できます。

例えばLOG_ERRという監視サービスを作成し、メッセージが「ERROR」に一致した場合と、プライオリティが「err」に合致した場合の両方で障害を検知できます。

■ 例

altitude_reference_com_noti

複数の通知条件を作成し、「対象ホスト」と「通知先サービス名」を一致させておくことで、ホストに対して単一のサービスが追加され、どちらの条件も有効となります。

上記の例では、登録ログ条件名をLOG_E01とLOG_E02とし、それぞれ「対象ホスト」をログサーバ01、「通知先サービス名」をLOG_ERRとして作成します。

■ 設定例

altitude_reference_com_noti2

altitude_reference_com_noti3

ログサーバ01に登録された「LOG_ERR」サービスは一つだけですが、通知条件はLOG_E01とLOG_E02のどちらも有効、となります。

15.4.9.5. 複数のホストに同じ通知条件を設定する

複数のホストに同じ通知条件を使用することも可能です。

例えば３台の監視ホストに対して、各ホストのメッセージが「ERROR」と一致する場合に障害を検知する条件を設定したい場合に使用できます。

■ 例

altitude_reference_com_multinoti

「対象ホスト」に複数のホストを選択することで実現します。

例として、LOG_ERRORという通知条件の「対象ホスト」を、sv01、sv02、sv03の３台となるよう選択します。

■ 複数ホストの選択

altitude_reference_com_multinoti2

altitude_reference_com_multinoti3

指定した３ホストに、同じサービスIDで監視が登録されます。

ログ監視や障害検知、エスカレーションの動作は各ホストで独立して行われますが、設定した通知条件を編集・削除すると、対象に指定されている全てのホストへ影響が出ますのでご注意ください。

15.4.9.6. 自動復旧の条件

通知条件を組み合わせることで、監視の自動復旧が可能なケースもあります。

altitude_reference_com_autorec

例えば、メッセージが「BATCH_ERROR」と一致した場合はCRITICALとする条件と、メッセージが「BATCH_SUCCESS」と一致した場合はOKとする条件をそれぞれ作成し、通知先サービス名を同じものにします。

ここでは通知条件名をLOG_BATCH01、LOG_BATCH02とし、通知先サービス名をどちらもLOG_BATCHとしています。

■ 設定例

altitude_reference_com_autorec2

altitude_reference_com_autorec3

これで自動復旧の設定は完了です。監視対象ホストで下記例のようなコマンドを実行することで、検知テストを実行できます。

■CRITICAL検知テスト

# logger -i -t TEST -p user.warning "BATCH_ERROR"

■OK検知テスト

# logger -i -t TEST -p user.warning "BATCH_SUCCESS"

■ 自動復旧確認

altitude_reference_com_autorec4

15.4.10. syslog管理のサービス設定変更について

syslog管理からサービスを登録した場合は、「ログ監視」及び「NRPE経由でのログ監視」プラグインとは異なり、デフォルトで再試行回数が１回に変更されています。

また、監視の性質上「アクティブチェック無効、パッシブチェック有効」となっています。

しかし、「volatileサービス」については他のログ監視と同様に、必要に応じて変更してください。

15.4.10.1. ログを検知するたびに通知を行う（volatileサービスの設定）

X-MONの仕様により、一度サービスのステータスが変化すると、次にステータスが変化するかエスカレーション再実行間隔が経過するまで、エスカレーションは実行されません。

このため、同一サービスに複数の検知条件を設定している場合、同じステータスで異なる内容のログを検知してもエスカレーションが実施されません。

例）同じ通知先サービス名・ステータスを設定しているが、検知対象文字列が異なる

altitude_reference_service_volatile

同じ通知先サービス名なので、作成される通知条件は１つです。

altitude_reference_service_volatile2

volatileサービスを有効に設定すると、同じステータスであっても、条件に合致するログを検知すると都度エスカレーションを実行します。

デフォルトではこの機能は無効となっています。

サービス設定の[高度な設定] タブ内に「volatileサービス」がありますので有効にすれば設定は完了です。

altitude_reference_service_volatile3

15.4.10.2. アクティブチェックと試行回数の設定について

syslog通知条件ではパッシブチェックを利用し、条件に合致するsyslogを受信するとエスカレーションを実行します。

そのため、syslog管理はアクティブチェック無効、パッシブチェック有効、試行回数は１と設定されています。

設定項目	設定値	目的
アクティブチェック	無効にする	syslog管理は待ち受ける監視のため。
パッシブチェック	有効にする	syslog管理は待ち受ける監視のため。
試行回数	１	条件に一致するログを１件受信すると即座にハードステータスとなり、エスカレーションが実行されます。

■ 詳細

altitude_reference_acre

syslog管理を使用する際は、上記内容を変更しないようお願いします。