24. 高度リファレンス

本書はX-MON3系列を用いてLinuxサーバを監視するリファレンスとなっております。

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

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

本書における解説環境

X-MON ver 3.0.6

X-MON ver 3.0.5以前をご利用の方はver 3.0.5用リファレンスをご利用ください。

SNMP TRAP監視につきましてX-MON ver3.6.0以上をご利用のお客様は別途「SNMP TRAP監視設定マニュアル」をご利用ください。

24.1. ログ監視

ここではX-MONを用いたログ監視について解説していきます。

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

ログ監視は3つ用意されています。

・ログ監視

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

どのログファイルを監視するか任意に指定が出来ます。

・NRPE経由でのログ監視

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

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

・syslog管理

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

syslogの設定によりログが大きくなる可能性もありますので運用負荷は高くなります。

24.1.1. ログ監視

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

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

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

この監視を設定する際には、サービス設定画面の「高度な設定」タブ内の「volatileサービス」で「有効にする」を選択して、指定した文字列が出現する度に通知するよう設定する必要があります。また、「監視の詳細設定」タブ内の「試行回数」で「1」を入力して、指定した文字列が1度出現したら通知するよう設定する必要があります。

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

altitude_reference_log altitude_reference_log2 altitude_reference_log3

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

指定したログがX-MONを実行するx-monユーザで読み取れる権限が必要となります。

読み取り権限がない場合は読み取り権限を付与してください。

例として、/var/log/messagesを監視する場合、デフォルトではrootのみ権限があります。

# ls -la /var/log/messages

-rw------- 1 root root 548037 12月 12 16:03 /var/log/messages

所有者ごと変更するとサーバ運用に問題が発生しやすいので、グループ設定をx-monグループに変更します。

# chgrp x-mon /var/log/messages
# ls -la /var/log/messages
-rw------- 1 root x-mon 548227 12月 12 16:06 /var/log/messages

グループがx-monになった事を確認して、グループ権限に読み取りを付与します。

# chmod g+r /var/log/messages
# ls -la /var/log/messages
-rw-r----- 1 root x-mon 548227 12月 12 16:06 /var/log/messages

これでx-monグループに所属しているx-monユーザでも読み取りが可能となります。

24.1.1.2. 監視設定例

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

エラー文字列で検出する文字列を指定します。

入力は半角英数字で、大文字と小文字を区別しますので注意してください。

例では「sshd」を指定します。

■ 監視設定例

altitude_reference_log4

ログ監視で1度でもエラー文字列を検知したら通知するように設定を行います。「試行回数の設定」か「volatileサービスの設定」のどちらかを設定してください。

24.1.1.3. 試行回数の設定

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

altitude_reference_log_retry

24.1.1.4. volatileサービスの設定

下にある「高度な設定」を開きます。ログ監視ではデフォルトで「無効」になっていますので「有効」へ変更します。

altitude_reference_log_volatile

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

ログ監視では比較する一時ファイルを作成するため、作成後一回目のチェックのみ

「Log check data initialized」となります。

■ 一回目の監視

altitude_reference_log_status

二回目のチェック以降は比較が実施されます。正常に監視がOKの場合は下記のように「Log check ok - 0 pattern matches found」が表示されます。

■ 正常な場合

altitude_reference_log_status2

異常を検知しCRITICALとなった場合は下記のように検知した文字列を表示します。

（セキュリティのため一部文字列を伏せております）

■ 異常な場合

altitude_reference_log_status3

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

■ 権限がない場合

altitude_reference_log_status4

「ログの閲覧権限について」を参考に読み取り権限を付与してください。

24.1.1.5. 設定項目一覧

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

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

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

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

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

この監視を設定する際には、サービス設定画面の「高度な設定」タブ内の「volatileサービス」で「有効にする」を選択して、指定した文字列が出現する度に通知するよう設定する必要があります。また、「監視の詳細設定」タブ内の「試行回数」で「1」を入力して、指定した文字列が1度出現したら通知するよう設定する必要があります。

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

指定したログがNRPEを実行するユーザで読み取れる権限が必要となります。

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

24.1.2.2. 監視設定例

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

エラー文字列で検出する文字列を指定します。

入力は半角英数字で、大文字と小文字を区別しますので注意してください。

例では「error」を指定します。

■ 監視設定例

altitude_reference_nrpelog_sample

ログ監視で1度でもエラー文字列を検知したら通知するように設定を行います。「試行回数の設定」か「volatileサービスの設定」のどちらかを設定してください。

24.1.2.3. 試行回数の設定

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

altitude_reference_nrpelog_sample2

24.1.2.4. volatieサービスの設定

下にある「高度な設定を開きます。ログ監視ではデフォルトで「無効」になっていますので「有効」へ変更します。

altitude_reference_nrpelog_sample3

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

ログ監視では比較する一時ファイルを作成するため、作成後一回目のチェックのみ

「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

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

altitude_reference_nrpelog_status4

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

24.1.2.5. 設定項目一覧

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

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

ログ監視のステータス情報は複数の行が検知した場合、行の数を表示しますが、表示されるステータス情報の部分は1行しか表示されません。

そのため、ログ検知をした場合は行数を確認し、実際に監視ホストにてログを確認するような運用をお願いします。

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

altitude_reference_nrpelog_status5

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

altitude_reference_nrpelog_status6

また、下記のようなUnknownが表示される事があります。

altitude_reference_nrpelog_status7

この場合は、検知文字列の入力にて使用出来ない文字列が入っており、監視ホストのNRPEプラグインでエラーが発生しています。

現状、X-MONの仕様により記号や漢字を入力しても入力エラーにならずに監視設定が出来てしまいます。そのため、入力の際は半角英数字での入力をお願いします。

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

ログ監視で検知する文字列を入力出来ますが、監視プラグインの仕様で正規表現が使用できます。

使用出来る正規表現は下記となります。

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

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

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

「user3*」とすると「user300」など3桁の数字があった場合も検知されてしまいます。

24.1.4.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の文字列以降を検索しますので、上記例ログでは検知しない形となります。

24.2. syslog管理

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

ログ監視との違いは正規表現が使用でき、複数条件を指定出来る事です。

また検知した際のステータスの種類も選択出来ます。

そのため、検知すればCRITICALという条件と検知すればOK(復旧)を組み合わせる事で自動で監視復旧をさせる事も可能です。

■ ログ転送

altitude_reference_syslog

フィルターはrsyslogが実施するので、X-MONの監視設定的にはパッシブチェックとなります。

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

本書では監視ホストのsyslog管理も多くのディストリビューションで使用されているrsyslogを例に取り上げます。ネットワーク機器のログ転送方法についてはぞれぞれのマニュアルをご参照ください。

24.2.1. ログ転送の設定

24.2.1.1. X-MONサーバ（転送先）

X-MONではrsyslogを制御しています。

rsyslogは以前のsyslogではUDPのみだったポートがTCPにも対応しております。

そのためX-MONサーバでiptablesやファイアウォールでポート制限を実施している場合は下記ポートを許可するようにしてください。

TCP/UDP 514番

24.2.1.2. 監視ホスト（転送元）

rsyslogの設定でX-MONサーバへログを転送するようにします。

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

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

#to X-MON

*.* @192.168.100.1

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

#to X-MON

*.* @@192.168.100.1:514

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

#to X-MON

authpriv.info @192.168.100.1

24.2.1.3. 注意点

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

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

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

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

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

#to X-MON

*.* @@192.168.100.1:514;RSYSLOG_TraditionalFileFormat

24.2.1.4. ログ転送の確認

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

監視ホストで

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

を発行し、監視ホストとX-MONサーバの/var/log/messagesを確認します。

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

というログが両サーバにて記載されていれば正常にログが転送されています。

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

ログ検出の範囲は、X-MONに転送されたログ全てが対象となります。

rsyslogでログに書き出される前にX-MONにて処理を実施しています。

X-MONサーバのrysylogの設定ファイルは /etc/rsyslog.d/syslog.confですが、特別に別ファイルへ出力させたりする必要がある場合以外に設定ファイルは編集しないようにお願いします。（X-MONの動作関係の設定も記載されています）

24.2.2. syslog管理画面

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

altitude_reference_syslog_menu

また、ログを検知する方法はプロパティベースフィルター、式ベースフィルターの2種類があります。

24.2.2.1. 新規作成

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

altitude_reference_syslog_menu2

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

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

altitude_reference_syslog_menu3

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

登録ログ条件名はsyslog管理画面で表示する時の名前です。

X-MONのサービス一覧表示などで表示させた際には「通知先サービス名」が使用されます。別々の名前にするとわかりにくくなりますので、同じ名前にしておくと運用しやすくなります。

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

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

ログは1行ずつのテキストとなっています。ログ管理にて検知するログは1行単位での範囲となります。

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

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

altitude_reference_syslog_menu4

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

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

式ベースフィルターでは、複数の検索条件を設定することが可能です。いずれかの条件に一致した際に通知を行いたい場合は、同じパネル内に条件を追加していきます。全ての条件に一致した際に通知を行いたい場合は、別のパネル内に条件を追加します。

ログは1行ずつのテキストとなっています。ログ管理にて検知するログは1行単位での範囲となります。

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

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

altitude_reference_syslog_menu5

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

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

プロパティベースフィルター形式を例に交えながら解説を行います。

下記のサンプルネットワークをご確認頂きながらご参照ください。

■ サンプルネットワーク

altitude_reference_syslog_property

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

24.2.3.1. 基本的な設定例

24.2.3.1.1. 新規作成

[MENU]の[syslog管理]内の[新規作成]を開き、条件を入力します。

altitude_reference_syslog_menu

altitude_reference_syslog_formula3

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

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

■ 入力例

altitude_reference_syslog_property4

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

24.2.3.1.2. 確認

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

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

altitude_reference_syslog_property5

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

altitude_reference_syslog_property6

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

altitude_reference_syslog_property7

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

syslog管理ではフィルターして検知するのをrsyslogが行い、結果をX-MONへ通知します。そのため監視はパッシブチェックとなります。そのため画像のように「このサービスはチェックするようにスケジュールされていません。」となります。

24.2.3.1.3. 検知テスト

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

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

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

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

altitude_reference_syslog_property8

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

24.2.3.1.4. 監視を復旧させる

手動で監視を復旧させるにはパッシブの結果を送るという動作になります。

サービス一覧表示の監視名を開き、「 altitude_reference_send_passive_check_icon このサービスのパッシブチェックの結果を送信」アイコンをクリックします。

altitude_reference_syslog_property10

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

altitude_reference_syslog_property12

チェック結果をOKにします。（デフォルトで選択されています）チェック出力は必須入力となります。

例えば「ログ検知のテストのためOK」や実際の運用では「ログ確認、対応完了」などを記載するといいでしょう。

altitude_reference_syslog_property13

入力出来たら発行を押します。

altitude_reference_syslog_property14

コマンドを正常に受け付けた画面となります

altitude_reference_syslog_property15

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

サービス一覧表示にてステータス情報がパッシブの結果を送信の際に入力した「ログ検知のテストのためOK」というステータスとなり正常（OK）で復旧しています。

altitude_reference_syslog_property16

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

24.2.3.2. 「対象」の設定例

「対象」について個別に設定例を記載します。

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(error)
warn(warning)	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サーバ上でどのようにログが転送されているかも確認するようにしてください。

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

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

altitude_reference_syslog_property19

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

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

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

例：ファシリティがdaemon以外を検知するようにする。

■ 設定例

altitude_reference_syslog_property20

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

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

altitude_reference_syslog_property21

比較内容は下記４つを選択出来ます。

部分一致

完全一致

前方一致

正規表現

24.2.3.4.1. 部分一致

指定した文字列を部分で検索し、検知します。

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

altitude_reference_syslog_property22

24.2.3.4.2. 完全一致

完全一致を検索し、検知します。

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

altitude_reference_syslog_property23

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

24.2.3.4.3. 前方一致

指定した文字列の前方が合うか検索し検知します。

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

altitude_reference_syslog_property24

24.2.3.4.4. 正規表現

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

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

また、先頭を表す「^」や文末の「$」も使用出来ます。

例：ファシリティが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

運用としては、ログを複数設定する場合や正規表現させる場合は一度監視環境にて検証を行い、正常に検知されるかを確認してから通常運用に入るようにお願いします。

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

式ベースフィルター形式を例に交えながら解説を行います。

下記のサンプルネットワークをご確認頂きながらご参照ください。

■ サンプルネットワーク

altitude_reference_syslog_formula

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

24.2.4.1. 基本的な設定例

24.2.4.1.1. 新規作成

[MENU]の[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を再起動します。

24.2.4.1.2. 確認

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

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

altitude_reference_syslog_check

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

altitude_reference_syslog_check2

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

altitude_reference_syslog_check3

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

syslog管理ではフィルターして検知するのをrsyslogが行い、結果をX-MONへ通知します。そのため監視はパッシブチェックとなります。そのため画像のように「このサービスはチェックするようにスケジュールされていません。」となります。

24.2.4.1.3. 検知テスト

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

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

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

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

altitude_reference_syslog_check4

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

24.2.4.1.4. 監視を復旧させる

手動で監視を復旧させるにはパッシブの結果を送るという動作になります。

サービス一覧表示の監視名を開き、「 altitude_reference_send_passive_check_icon このサービスのパッシブチェックの結果を送信」アイコンをクリックします。

altitude_reference_syslog_check6

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

altitude_reference_syslog_check8

チェック結果をOKにします。（デフォルトで選択されています）チェック出力は必須入力となります。

例えば「ログ検知のテストのためOK」や実際の運用では「ログ確認、対応完了」などを記載するといいでしょう。

■ 項目入力

altitude_reference_syslog_property13

入力出来たら発行を押します。

altitude_reference_syslog_property14

コマンドを正常に受け付けた画面となります

altitude_reference_syslog_property15

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

サービス一覧表示にてステータス情報がパッシブの結果を送信の際に入力した「ログ検知のテストのためOK」というステータスとなり正常（OK）で復旧しています。

altitude_reference_syslog_check12

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

24.2.4.2. 設定項目について

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

ファシリティ

プライオリティ

メッセージ

タグ

altitude_reference_syslog_check14

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

24.2.4.3. ファシリティ

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

altitude_reference_syslog_setitem

検索内容が選択BOXとなります。検索内容は以下となります。

kern

user

mail

daemon

auth

syslog

lpr

news

uucp

cron

authpriv

ftp

ntp

audit

clock

alert

local0～7

上から順にレベルが高い順となっております。

条件指示は以下4つとなります。

一致する

以外

より大きい

より小さい

・一致する

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

・以外

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

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

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

24.2.4.3.1. 設定例

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

altitude_reference_syslog_setitem2

この場合はdaemonは含みませんので、上位のkern、user、mailのファシリティが検知対象となります。

24.2.4.4. プライオリティ

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

altitude_reference_syslog_priority

検索内容が選択BOXとなります。検索内容は以下となります。

emerg

alert

crit

err

warn

notice

info

debug

上から順にレベルが高い順となっております。

条件指示は以下4つとなります。

一致する

以外

より大きい

より小さい

・一致する

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

・以外

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

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

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

24.2.4.4.1. 設定例

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

■ 設定例

altitude_reference_syslog_priority2

24.2.4.5. メッセージ

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

altitude_reference_syslog_mess

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

条件指示は以下4つとなります。

一致する

一致しない

含める

含まない

・一致する

入力した文字列（単語ではなく、文字列）が一致するかどうかになります。

例えば、メッセージで"X-MON-TEST"とした場合、メッセージで"X-MON-TEST"と一致した場合のみ検知します。そのため、"X-MON-TEST WARNING"というメッセージの場合は検知しません。行そのものが一致するかどうか、と認識頂ければと思います。

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

・一致しない

入力した文字列（単語ではなく、文字列）が一致しない場合検知します。

・含める

入力した文字列が含まれるかとなります。

例えば、メッセージで

"X-MON-TEST"とした場合、メッセージが"X-MON-TEST”でも"X-MON-TEST WARNING"の場合でも検知します。

・含まない

入力した文字列が含まれない場合に検知する、となります。

24.2.4.5.1. 設定例

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

■ 設定例

altitude_reference_syslog_mess2

24.2.4.6. タグ

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

altitude_reference_syslog_tag

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

条件指示は以下4つとなります。

一致する

一致しない

含める

含まない

・一致する

入力した文字列（単語ではなく、文字列）が一致するかどうかになります。

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

・一致しない

入力した文字列（単語ではなく、文字列）が一致しない場合検知します。

・含める

入力した文字列が含まれるかとなります。

例えば、タグで"ssh"とした場合、タグが"ssh”でも"sshd"の場合でも検知します。

・含まない

入力した文字列が含まれない場合に検知する、となります。

24.2.4.6.1. 設定例

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

■ 設定例

altitude_reference_syslog_tag2

24.2.4.7. パネルを追加して複数の条件で検索する

条件を追加する（パネルを追加する）とand条件とor条件を設定出来ます

24.2.4.7.1. and検索

例えば、メッセージでX-MON-TEST、ファシリティでuserの場合は検知する場合を設定してみます。

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

altitude_reference_syslog_and

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

altitude_reference_syslog_and2

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

altitude_reference_syslog_and3

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

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

■ 設定例

altitude_reference_syslog_and6

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

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

24.2.4.7.2. or検索

例えば、メッセージでX-MON-ERRORもしくはファシリティでdaemonの場合は検知する場合を設定してみます。

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

altitude_reference_syslog_or

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

altitude_reference_syslog_or2

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

altitude_reference_syslog_or3

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

■ 設定例

altitude_reference_syslog_or4

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

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

24.2.4.7.3. 複雑な条件での検索

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

例として

「プライオリティがALERT、もしくはタグがX-MONがある場合にファシリティがuserと一致、その場合にメッセージにERRORの場合は検知する。」

少しわかりにくいですが、||と&&を使って式で表してみます。

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

複雑な条件の場合は上記の式の内部の小さいものから設定していくのをイメージすればわかりやすくなります。

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

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

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

altitude_reference_syslog_complex

これで式の囲っている部分が出来ました。

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

次はこの条件に対するand条件ファシリティがuserのパネルを追加します。

「新しい条件パネルを横に追加（and条件）」で条件パネルを追加し、「このパネルに条件を追加（or条件）」で入力パネルを追加します。追加出来たら、設定例を入力します。

altitude_reference_syslog_complex2

これで式の囲っている部分が出来ました。

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

残りは、この大きい条件に対して、メッセージがERRORの場合というand条件となります。このままさらに条件パネルを追加すると、小さい条件に対するand条件となってしまいます。

■ 間違ったand条件の追加

altitude_reference_syslog_complex3

そのため、式でいう、かっこで纏めるようにイメージしてください。

この小さい条件をグループとしてまとめます。

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

altitude_reference_syslog_complex4

これでgroup化となります。

altitude_reference_syslog_complex5

それではこのグループにand条件のパネルを追加します。

グループ化した部分とand条件になる事がわかります。

altitude_reference_syslog_complex6

これに入力しましょう。

これでグループとand条件が完成し、設定例が完成しました。

■ 設定例

altitude_reference_syslog_complex7

altitude_reference_syslog_complex72

このようにして、複雑な条件でも小さい部分から作成していく事によって実現する事が出来ます。

その他の作成方法として、大きい部分から作成する事も可能です。その場合は「この条件の下にパネルを追加」を実行します。

altitude_reference_syslog_complex8

altitude_reference_syslog_complex9

設定方法は大きくはかわりませんので、使いやすい方を使用してください。

24.2.4.8. 注意点

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

24.2.4.8.1. パネルを間違って追加した場合

間違ってパネルを追加してしまった場合、パネルを削除出来ます。

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

■ 削除前

altitude_reference_syslog_mis

■ 削除後

altitude_reference_syslog_mis2

しかし、複雑な条件の場合に間違って追加してしまった場合、そのパネルの境界がわかりにくいため注意して実行してください。現在のX-MONのバージョンでは1つ前の動作に戻る機能は搭載されておりません。

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

■ 複雑な条件

altitude_reference_syslog_mis3

運用としては、ログを複数設定する場合や正規表現させる場合は一度監視環境にて検証を行い、正常に検知されるかを確認してから通常運用に入るようにお願いします。

24.2.5. 共通の設定動作

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

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

一度設置した設定を編集する事が出来ます。

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

altitude_reference_syslog_property5

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

altitude_reference_com_edit2

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

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

altitude_reference_com_edit3

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

altitude_reference_com_edit4

この際、フィルターの部分のみの編集ですとX-MONの再起動は必要ありませんので再起動を促す再起動ボタンは点滅しません。

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

24.2.5.1.1. 編集できる項目について（サービス設定からの編集）

syslog管理からは通知条件について編集を行いますが、再通知間隔やステータスによる通知の有無、また通知先グループについては[ホスト管理] の[サービス設定] から編集を行います。

altitude_reference_com_edit5

該当のサービスの[ 詳細表示] を開きます。一番下に[編集]がありますので開きます。

altitude_reference_com_edit6

編集画面が開きますので、編集する項目を編集してください。

この際、「サービス監視用コマンド」の部分についてはsyslog管理部分にて動作をさせるための項目ですので編集しないようにお願いします。

編集が完了したら、[編集]もしくは[編集と承認]にて完了させ、X-MONを再起動させてください。

altitude_reference_com_edit7

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

条件の削除は編集と同じく詳細表示から実施出来ます。

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

altitude_reference_syslog_property5

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

altitude_reference_com_del2

削除の確認が出ますので、OKでしたらOKボタンを押してください。

altitude_reference_com_del3

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

X-MONの再起動が必要となりますので、X-MONを再起動させて完了です。

altitude_reference_com_del4

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

syslog管理以外にも、[ホスト管理] の[サービス設定]からも通知条件は削除出来ます。どちらで削除を行っても動作への影響はありません。

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

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

altitude_reference_com_del5

確認ウィンドウが出ますので、OKでしたらOKを押してください。

altitude_reference_com_del6

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

altitude_reference_com_del7

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

24.2.5.3. 複数の条件を一つの通知先に設定する

複数の条件を１つの通知先（監視名）に設定する事が可能です。

例えば、LOG_ERRという監視名でメッセージがERRORを検知した時とプライオリティでerrを検知した際に通知する事が出来ます。

■ 例

altitude_reference_com_noti

設定としては、通知条件を二つ作成します。

この例ですと、メッセージがERRORを検知した時と、プライオリティでerrを検知する条件です。登録ログ条件名をLOG_E01とLOG_E02とし、それぞれの「通知先サービス名」をLOG_ERRとして作成します。

■ 設定例

altitude_reference_com_noti2

altitude_reference_com_noti3

ログサーバ01に「LOG_ERR」は一つだけですが、検知する条件はLOG_E01とLOG_E02両方とも有効、という形になります。

複数の監視を追加することなく、スマートな監視が可能となります

24.2.5.4. 複数のホストで一つの通知先を設定する

複数のホストで1つの通知先を使用する形となります。

例えば、監視ホストが3つあり、それぞれメッセージでERRORが出れば通知するような条件を設定したい場合に使用出来ます。

■ 例

altitude_reference_com_multinoti

設定としては、対象ホストでホストを3つ選択するだけです。

例として、LOG_ERRORという通知条件を、sv01、sv02、sv03の3つのホストに通知するように設定します。

■ 作成時のホストの選択

altitude_reference_com_multinoti2

altitude_reference_com_multinoti3

それぞれのホストで同じ監視名で登録されます。

検索はそれぞれのホストで行われますが、通知条件を編集すると全てのホストへ影響が出ますので注意してください。

24.2.5.5. 自動復旧の条件

条件を組み合わせる事により、監視の自動復旧も可能です。

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

24.2.6. サービス設定からの設定について（共通）

syslog管理で設定できる項目でも解説していますが、ホストのサービス設定から設定する項目で重要な点について記載します。

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

X-MONの仕様により、一度ステータスが変化すると、次にステータスが変化するか再通知間隔の時間が過ぎるまで通知は実施されません。

そのため、同じ通知サービス名で複数の通知条件を設定している場合に同じステータスのまま違う内容のログを受け取っても、ステータスが変化しないために通知が実施されません。

例）同じ通知先サービス名・ステータスを設定しているが、対象TRAPが違う

altitude_reference_service_volatile

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

altitude_reference_service_volatile2

volatileサービスを設定する事により、同じステータスであっても別の内容のログを受信（厳密にはログ検知するたびに）すると通知を行います。デフォルトではこの機能は無効となっています。

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

altitude_reference_service_volatile3

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

syslog通知条件では、パッシブチェックを利用し、syslogを受信したら通知を実施する設定となっています。

そのため、サービス設定のアクティブチェックは無効、試行回数は1の設定が通知条件を作成した際に設定されます。

設定項目	設定値	目的
アクティブチェック	無効にする	SYSLOG監視は待ち受ける監視のため。
試行回数	1	条件に一致するログを1件受信したら即座にハードステータスとなり、メール等の通知が実施されます。

■ 詳細

altitude_reference_acre

並びに、パッシブチェックも有効となっています。

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

24.3. SNMP TRAP監視

X-MONでは、サーバやネットワーク機器からイベントが発生した際に状況を通知するSNMP TRAPに対応しています。

SNMP TRAPはサーバの管理ソフトやバックアップソフトで正常にジョブが終了した通知や、ネットワーク機器にてポートの状況が変化した際などで使用されます。

SNMP TRAPはOIDという数字列で構成され、その数字列が対応するMIBという各ベンダーが公開している管理項目と照らしあわせ、そのTRAPが何を意味しているかを表示します。

X-MONでは、各ベンダーのMIBをデフォルトで各種搭載しています。

また、各ベンダーが公開しているMIBファイルをX-MONに登録する事も可能です。

24.3.1. 監視概要

SNMP TRAPの監視を設定するには以下のような手順を踏みます。

本リファレンスではサンプルネットワークを基に、手順について解説していきます。

■ サンプルネットワーク

altitude_trap_overview

altitude_trap_overview2

24.3.1.1. 監視について

SNMP TRAPの監視はSNMP TRAPのデーモン（SNMPTT）で動作しています。

SNMPTTがTRAPを受信しX-MONへ通知する、という形です。

そのため、X-MONではSNMP TRAPの監視設定については「通知条件の設定」という名称で実施しております。そのため監視についてはパッシブチェックとなります。

設定については、どのようなSNMP TRAPを通知条件に設定するか、MIBを登録する、編集するについてはSNMP TRAP管理にて行います。

基本的にはSNMP TRAP管理のみで運用（新規作成、編集、削除）は可能ですがステータスによる通知の有無や再通知間隔など監視詳細（Nagiosコアを使用する部分）については、SNMP TRAP管理で新規作成後に[ホスト管理]の[サービス設定]から設定を行います。

altitude_trap_overview3

24.3.1.2. MIBの依存関係について

MIBファイルには依存関係が存在します。大きいカテゴリから小さいカテゴリがあり、小さいカテゴリのMIBファイルを使用するには、大きいカテゴリのMIBファイルが登録されていないといけません。ベンダーのサイトでも依存関係については表記があり、またX-MONではMIB登録時に依存関係のチェックを実施します。

その際に、どの依存関係のMIBファイルが必要かも表示されます。（依存関係の不足を参照）

24.3.1.3. 監視ホストの設定について

機器やソフトウェアのSNMP TRAPの設定は各マニュアルを確認してください。

Ciscoスイッチではグローバルコンフィギュレーションモードにて

(config)# snmp-server enable traps

(config)# snmp-server host [IPアドレス] version 2c [コミュニティ名]

で設定が可能です。X-MONではデフォルトのコミュニティ名はpublicです。

ソフトウェアですと、TrendMicro社のServerProtectやSymantec社のBackupExecなどGUIの管理画面があるものは管理画面から設定出来るものもあります。また、WindowsサーバもGUIより設定可能です。Windowsに関しては

設定例（Windowsサーバからの任意TRAP通知）を参照ください。

次章より、サンプルネットワークに沿って設定方法を解説いたします。

24.3.2. TRAPする機器の確認

本リファレンスのサンプルではCiscoスイッチで解説いたします。

スイッチはCiscoのcatalyst2950を例にします。

Cisco機器の場合、以下のwebサイトにてどのようなtrapがあるか解説されています。

■ URL1

http://www.cisco.com/cisco/web/support/JP/100/1004/1004133_SNMPTrapsInImages.html

各ベンダーにてスイッチのMIBはwebサイトで公開されています。

Cisco機器の場合は

■ URL2

http://tools.cisco.com/Support/SNMP/do/BrowseOID.do?local=ja

のSNMP オブジェクトナビゲータというところから検索が可能です。

また、URL1のSNMP TRAPの解説のページからURL2へのオブジェクトナビゲータへのリンクもあります。

24.3.2.1. MIBファイルの探し方

どのようにMIBファイルを探すか、例をします。

例えば、コンフィグファイルを新しく保存された際にTRAPの通知をしたい、とします。

URL1のページで確認すると、configという項目があります。設定通知を送信するTRAPで、MIBファイル名は「CISCO-CONFIG-MAN-MIB」でそれを示すOIDは「1.3.6.1.4.1.9.9.43.2.0.1」、TRAP名は「ciscoConfigManEvent」であることがわかります。このMIBのリンクか、URL2で「CISCO-CONFIG-MAN-MIB」を検索します。

■ URL3

http://tools.cisco.com/Support/SNMP/do/BrowseMIB.do?local=ja&step=2&mibName=CISCO-CONFIG-MAN-MIB

ここで必要なMIBの一覧が表示されます。

X-MONではSNMPバージョン2を推奨しますので、ダウンロードします

それ以外依存のあるものも必要となりますが、X-MONでは基本的なMIBはすでに搭載しています。そのため、登録されていない物だけダウンロードしてください。

この例では、「CISCO-CONFIG-MAN-MIB」以外はすでにX-MONに登録されていますので、ダウンロードするのは「CISCO-CONFIG-MAN-MIB」のみとなります。

これで必要なMIBファイルは準備出来ました。

24.3.2.1.1. その他のMIBファイルの探し方

・YAMAHAルータの場合

http://www.rtpro.yamaha.co.jp/RT/docs/mib/

にて公開されています。全てのMIBがX-MONに初期登録済です

・サーバソフトウェアの場合

サーバソフトウェアの場合でもスイッチと同じように各ベンダーのwebサイトにて公開されております。

TrendMicro社 ServerProtectでは

http://esupport.trendmicro.co.jp/Pages/JP-2080116.aspx

http://esupport.trendmicro.co.jp/Pages/JP-23681.aspx

サポートページから検索できます。

http://esupport.trendmicro.co.jp/corporate/sresult.aspx?q=MIB

商品のディスクに付属している場合もあります。

Symantec社のBackupExecでは

http://www.symantec.com/business/support/index?page=content&id=HOWTO73524

このように商品の中にしかないものもありますので注意してください。

また、Windowsサーバでは独自のMIBファイルがありませんので手動で登録する形となります。（設定例（Windowsサーバからの任意TRAP通知）参照）

必要なMIBファイルが用意出来たら、X-MONへMIBファイルを登録しますので次章をご参照ください。

24.3.3. MIBファイルのX-MONへの登録

MIBファイルが準備出来たらX-MONへ登録します。

サンプルではCisco catalyst2950のCISCO-CONFIG-MAN-MIBを使用します。

24.3.3.1. MIBファイルを登録する

X-MONの画面からSNMP TRAP管理を選択します。

altitude_trap_mib_reg

このような画面が表示されます。

altitude_trap_mib_reg2

ここがSNMP TRAPの管理画面となります。管理画面の詳細は SNMP TRAP管理画面メニューについてに記載しております。

それではMIBをX-MONに登録していきます。

MIB一覧を選択して開いてください。

altitude_trap_mib_reg3

altitude_trap_mib_reg4

現在X-MONに登録されているMIBファイルの一覧が表示されます。表示はアルファベット順で50件ごとです。

左上に「登録」のボタンがありますので開きます。

altitude_trap_mib_reg5

MIBファイルの登録画面になります。

altitude_trap_mib_reg6

「参照」ボタンを押し、ファイルを選んでください。

文字コード欄は下記3つが選択出来ます。

・UTF-8 ・SJIS ・EUC

ファイルの文字コードではなく、TRAPの文字コードとなります。

通常でしたらUTF-8を選択してください。（デフォルト）

しかし、TRAPの送信元がWindowsの場合はSJISの場合がございます。

例：TrendMicro社ServerProtect Windows版の場合

http://esupport.trendmicro.co.jp/Pages/JP-2078841.aspx?print=true

送信元がsift-jisでエンコードされているとありますので、その場合はsjisを選択してください。

不明な場合は各ベンダーサポートへお問い合わせお願いします。

（文字コードは登録後でも変更可能です）

選択が出来たら「登録と承認」を押します。

altitude_trap_mib_reg7

正常に登録できれば　MIB一覧の画面に戻ります。

「CISCO-CONFIG-MAN-MIBを登録しました。」と表示が出ます。

altitude_trap_mib_reg8

MIB一覧でも確認出来ます。

altitude_trap_mib_reg9

左から、MIBファイル名、継承元MIBファイル、文字コード、操作となっています。

SNMP TRAP一覧を見てみましょう。SNMP TRAP一覧画面を開いてください。

ここにも「CISCO-CONFIG-MAN-MIB」が追加されています。

altitude_trap_mib_reg10

左側からMIB定義、定義TRAP数、登録TRAP通知条件数、操作となっています。

詳細表示を開いてください。

altitude_trap_mib_reg11

このMIBから3つのTRAPが定義されました。

通知条件はここから設定します。

受信するOIDによってステータスの変化や通知先を変更できます。

24.3.3.2. MIBファイル登録時のエラーについて

24.3.3.2.1. 二重登録の禁止

すでに登録されているMIBファイルをもう一度登録しようとすると、すでに登録されていると表示され登録出来ません。

altitude_trap_mib_error

24.3.3.2.2. MIBファイル以外の形式の禁止

MIBファイルでないファイルを登録しようとした場合はエラーが表示され登録出来ません。

altitude_trap_mib_error2

24.3.3.2.3. 依存関係の不足

登録しようとしているMIBファイルに継承元の必要なMIBがX-MONに登録されていない場合はエラーとなり登録出来ません。

altitude_trap_mib_error3

この場合は表示されている「SNMPv2-TC-v1」というMIBを先にX-MONに登録する必要があります。

24.3.3.3. SNMP TRAP管理画面メニューについて

TRAP管理画面メニューの項目一覧は下記となります。

項目	内容
SNMP trap一覧	登録されているtrapの一覧が表示されます。定義されているtrap数や通知条件数、または詳細が表示されます。監視設定もここから行います。
MIB一覧	X-MONにMIBファイルを登録します。MIBファイルは一覧で表示され、 MIBファイルの内容をプレビューできます。TRAP通知条件の設定を行うためには、設定するTRAPのOIDが含まれているMIBファイルを登録する必要があります
任意SNMP TRAP通知条件一覧	X-MONにMIBファイルを登録せず、独自のTRAP OIDを登録し通知条件の設定を行えます。
非監視SNMP TRAP通知設定	X-MONに登録していない条件のTRAPが送られてきた場合に通知するサービス、通知先を登録します。

24.3.3.4. MIBの文字コード変更する

登録したMIBの文字コードを変更する際はMIB一覧から対象のMIBファイル名の[文字コード変更]を開いてください。

altitude_trap_mib_error4

変更する文字コードを選択し、変更ボタンを押してください。

altitude_trap_mib_error5

例では「CISCO-CONFIG-MAN-MIB」SJISへ変更してみます。

変更が完了すれば「CISCO-CONFIG-MAN-MIBの文字コードをSJISに変更しました」と画面に表示されます。

altitude_trap_mib_error6

MIB一覧でも文字コードの部分が変更されているか確認してください。

altitude_trap_mib_error7

24.3.3.5. MIBファイルの内容をプレビューする

MIBファイルの内容をプレビューで確認出来ます。

MIB一覧からプレビューする該当のMIBの名前のリンクを開いてください。

altitude_trap_mib_preview

リンクを開くと下記図のような画面となりMIBファイルの内容を確認出来ます。

altitude_trap_mib_preview2

MIBファイル一覧に戻るには[戻る] を押してください。

24.3.3.6. MIBを削除する

登録しているMIBを削除するには、MIB一覧から対象のMIBファイル名の[削除と承認]を開いてください。

altitude_trap_mib_del

確認ウィンドウが出ますので、OKでしたらOKを押してください。

altitude_trap_mib_del2

「CISCO-CONFIG-MAN-MIBを削除しました」の表示が出ます。

これで削除は完了です。

altitude_trap_mib_del3

24.3.3.6.1. 通知設定（監視）がされている場合

削除対象のMIBからTRAPの通知設定（監視）がされている場合は削除できません。

altitude_trap_mib_del4

この場合は先に通知設定を削除してください。

（削除の方法については通知条件を削除するをご参照ください。）

24.3.4. TRAP通知条件の設定

必要なMIBをX-MONへ登録できたので、通知条件の設定（監視設定）をしていきましょう。ここでは「CISCO-CONFIG-MAN-MIB」を例にします。

24.3.4.1. TRAP通知条件の設定例

メニューからSNMP TRAP管理を開きSNMP TRAP一覧を表示します。

altitude_trap_noti_set

altitude_trap_noti_set2

「CISCO-CONFIG-MAN-MIB」の詳細表示を開いてください。

OID一覧が表示され、3つのTRAPが定義されています。

altitude_trap_noti_set3

altitude_trap_noti_set4

「ciscoConfigManEvent」のTRAPを設定してみましょう。

詳細表示を開いてください。

altitude_trap_noti_set5

通知条件の一覧が表示されます。まだこのTRAPに対して通知条件は設定されておりませんので、「このOIDのTRAPを受信した際の挙動を登録して下さい。」と画面に表示されます。

[新規作成]のボタンがありますので、開きましょう。

条件設定の画面となります。

altitude_trap_noti_set6

それぞれの項目は下記となります。

ステータス	内容
条件名	登録する通知条件の名前を入力します。
DataBinding(上級者向け)	TRAP OIDの中に含まれている変数バインドの情報を表示し条件を指定することが出来ます。 TRAPの中には変数バインドを持たないものも含まれます。変数バインドを持っていない場合、「このTRAPはData Bindingを持っていないため設定できません」と表示されます。変数バインドをもっている場合、バインド名、条件入力フィールド、使用条件が表示されます。
バインド名	変数の名前を表示します。
条件入力フィールド	バインド名に対して自由に記述することが出来るテキストフィールドで、使用条件と組み合わせます。
使用条件	「完全一致」「前方一致」「正規表現」が選択でき、その情報と条件入力フィールドの値を組み合わせて比較します。データバインディングの条件は、そのバインド名の項目が未入力だった場合はその項目は比較されません。このため特にそのバインドに対して条件を指定したくない場合は未記入で構いません。正規表現を選択している時は先頭と末尾にデリミタの「/」を必ず指定してください。例:)/^X-MON$/ また、全て未記入の場合エラーではなく対象TRAP OIDが送られてきた場合に通知します。(旧X-MON2系仕様)
対象ホスト	通知対象となるホストを選択します。選択したい「ホスト名称」の頭文字や「ホストグループ名称」を選択し、表示された選択肢からホストを選択し、「↑(選択)」をクリックします。また、ホストを除外する場合は、任意のホストを選択後、「↓(外す)」ボタンをクリックします。
通知先グループ	任意SNMP TRAP通知条件に反応した場合に通知する通知先グループを選択します。選択したい「ユーザグループ名称」の頭文字を選択し、表示された選択肢から通知先を選択し、「↑(選択)」をクリックします。また、通知先を除外する場合は、任意の通知先を選択後、「↓(外す)」ボタンをクリックします。通知先の登録は、ユーザグループ管理 - ユーザグループの作成、編集を参照してください。通知先グループはサービス登録・編集時でも指定が可能な為、どちらの設定条件を優先すべきか選択できます。「チェックで上書き登録/チェックなしで通知先を更新しない」にチェックを付けた場合、通知先情報を上書きし登録します。
通知先サービス名	対象ホストに入力した通知先サービス名が登録されます。新規作成時のみ設定が可能であり、変更はできません。入力制限：入力必須、半角英数字、アンダーバー、ドット、ハイフンのみ。また、以下の通知先サービス名は設定できません。・「-VMPERF」で終わる・間に「-VMPERF-」を含む・間に「-VMWARE-」を含む
通知ステータス	対象TRAPが通知条件と一致した場合にX-MONに投げるステータス情報を「OK」「WARNING」「CRITICAL」「UNKNOWN」から選択します。

今回はdata bindingは入力せず、下記のような条件で設定します。

（Data Bindingについては Data Bindingについてをご参照ください）|

ステータス	内容
対象TRAP	CISCO-CONFIG-MAN-MIB - ciscoConfigManEvent
条件名	snmp-trap-test
対象ホスト	SW-TRAP
通知先グループ	webチーム
通知先サービス名	snmp-trap-test
通知ステータス	CRITICAL

条件名と通知先サービス名は別の名前を指定出来ますが、同じにしておくほうが管理しやすくなります。

altitude_trap_noti_set7

入力出来たら作成と承認を押してください。

altitude_trap_noti_set8

「snmp-trap-testを設定しました。」と表示さますので、X-MONの再起動を実施してください。

altitude_trap_noti_set9

以上で通知条件の作成は完了です。

24.3.4.2. 通知条件の確認する

登録出来ているか確認してみましょう。

SNMP TRAP一覧の「CISCO-CONFIG-MAN-MIB」の部分に「登録TRAP通知条件数」が1となっています。

altitude_trap_noti_check

詳細表示を開いてください。

「ciscoConfigManEvent」の部分の「登録TRAP通知条件数」が1となっています。

altitude_trap_noti_check2

さらに詳細表示を開くと設定した通知条件一覧が表示されますので、作成したsnmp-trap-testが表示されます。

altitude_trap_noti_check3

設定した通知条件を確認するには[詳細表示]を開けば表示されます。

altitude_trap_noti_check4

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

設定したホストにsnmp-trap-testがあります。

altitude_trap_noti_check5

パッシブチェックとなるため、ステータス情報は「このサービスはチェックするようにはスケジュールされていません。」と表示されます。

SNMPTTがTRAPを検知し、X-MONへ通知すると検知します。

以上で通知条件の設定と確認は完了です。

実際に検知するかテストは動作確認テストにて行います。

24.3.4.3. 通知条件の編集する

通知条件を編集するには、通知条件の詳細から行います。

該当の通知条件の詳細を表示させ、下の[編集]を開きます。

altitude_trap_noti_edit

編集画面が開きますので、編集したい項目を編集してください。

編集が完了したら、[作成と承認] を押して完了後、X-MONを再起動させます。

altitude_trap_noti_edit2

24.3.4.3.1. 編集できる項目について（サービス設定からの編集）

SNMP TRAP管理からは通知条件について編集を行いますが、再通知間隔やステータスによる通知の有無、また通知先グループについては[ホスト管理] の[サービス設定] から編集を行います。

altitude_trap_noti_edit3

該当のサービスの[詳細表示] を開きます。一番下に[編集]がありますので開きます。

altitude_trap_noti_edit4

編集画面が開きますので、編集する項目を編集してください。

この際、「サービス監視用コマンド」の部分についてはSNMP TRAP管理部分にて動作をさせるための項目ですので編集しないようにお願いします。

編集が完了したら、[編集] もしくは[編集と承認]にて完了させ、X-MONを再起動させてください。

altitude_trap_noti_edit5

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

通知条件を削除するには、通知条件の詳細から行います。

該当の通知条件の詳細を表示させ、下の[削除と承認] を開きます。

altitude_trap_noti_del

確認ウィンドウが出ますので、OKでしたらOKを押してください。

altitude_trap_noti_del2

「設定を削除し反映しました」の表示が出ます。

X-MONを再起動させて完了です。

altitude_trap_noti_del3

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

SNMP TRAP管理以外にも、[ホスト管理] の[サービス設定]からも通知条件は削除出来ます。どちらで削除を行っても動作への影響はありません。

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

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

altitude_trap_noti_del4

確認ウィンドウが出ますので、OKでしたらOKを押してください。

altitude_trap_noti_del5

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

altitude_trap_noti_del6

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

24.3.4.5. Data Bindingについて

通知条件にある「Data Binding」について解説します。

Data Bindingとは変数バインド、不可データとも呼ばれ、SNMP TRAPに付与されるデータの事を指します。同じOIDであってもData Bindingの中の値によってさらに値を振り分ける（通知条件を絞り込む）事が可能となります。

例えば、監視対象ホストのインタフェースのリンクのアップ/ダウンを示すTRAPがあります。

このTRAPは「IF-MIB」という名前で定義されており一般的にも広く使われているTRAPとなっております。

altitude_trap_noti_databind

リンクダウンを示すTRAPは「linkDown」というTRAP名で定義されており、それを示すOIDは「.1.3.6.1.6.3.1.1.5.3」です。

altitude_trap_noti_databind2

このlinkDownについてData Bindingがどのようになっているか通知条件の新規作成画面で確認してみます。

altitude_trap_noti_databind3

図の通り、「ifindex」「ifAdminStatus」「ifOperStatus」の3つのData Bindingがある事がわかります。

つまり、OIDである.1.3.6.1.6.3.1.1.5.3と共にこの3つのデータがTRAPに含まれるということになります。

「ifindex」はインタフェース番号、「ifAdminStatus」は管理上のステータス（機器としてインタフェースは正常に動作しているか）、「ifOperStatus」は運用上（インタフェースが開いているか閉じているか）のステータスを意味します。

しかし、このData Bindingのデータについては、使用する機器やソフトウェアによってどのようなデータが含まれるか確認する必要があります。

それは機器によって仕様が違う、また拡張MIBを使用している場合はベンダー固有のMIBとなるためどのようなデータが含まれるかは受信してみないとわからないためです。

このDataBindingはX-MON上では、その通知条件を検知するための条件の一部として考えて頂ければと思います。

例としてこのlinkDownを検知する場合を想定してみます。

Data Bindingを設定せずに通知条件を作成してみます。

詳細画面では画像のように表示されます。

altitude_trap_noti_databind4

この状態で、監視対象ホスト（設定しているのはswitch機器）の7番のインタフェースをダウンさせてみます。「.1.3.6.1.6.3.1.1.5.3」のTRAPを検知しますので設定したステータスに変化します。また、ステータス情報を確認してみます。

altitude_trap_noti_databind5

画像のようにステータス情報を受信しています。

この時、文章の一番最後に

This other state is indicated by the included value of ifOperStatus. 7 FastEthernet0/7 ethernetCsmacd administratively down

というのがあります。FastEthernet0/7がダウンしたという意味となります。

このように、DataBindingを指定していない場合はDataBindingによる振り分け（検知する条件の絞り込み）はされませんので監視対象ホストのどのインタフェースにも対応できる通知条件となる、という事になります。

次に、DataBindingを使用する事を考えてみます。

このステータス情報に「ifOperStatus. 7」という記載があります。この値をX-MONからsnmpwalkコマンドで確認します。

# snmpwalk -v 2c -c public 192.168.19.101 ifOperStatus.7

IF-MIB::ifOperStatus.7 = INTEGER: down(2)

このような結果となります。down(2)に注目します。

DataBindingの設定項目にもifOperStatusというのがありました。downを意味する数字は「2」である事を示しています。

それでは、このifOperStatus.7が実際にどのインタフェースに関連づけされているか確認してみます。確認するにはifDescrの値を見ます。

# snmpwalk -v 2c -c public 192.168.19.101 ifDescr.7

IF-MIB::ifDescr.7 = STRING: FastEthernet0/7

Switch機器のFastEthernet0/7である事が確認されました。

これに関連付けされているifIndexの値も確認してみましょう。

# snmpwalk -v 2c -c public 192.168.19.101 ifIndex.7

IF-MIB::ifIndex.7 = INTEGER: 7

ifIndexの値は7であることがわかりました。

それでは、もう一つの値である

# snmpwalk -v 2c -c public 192.168.19.101 ifAdminStatus.7

IF-MIB::ifAdminStatus.7 = INTEGER: up(1)

upしている状態であり、示す数字は「1」である事がわかりました。

情報をここで纏めてみましょう。

FastEthernet0/7でData Bindingを指定する場合、

ifindexでインタフェース番号を指定すれば、指定したインタフェース番号のlinkdownのTRAPを検知します。

idAdminStatusでdownの条件を指定する場合は2を、upの条件の場合は1を入力すれば検知します。

iDoperStatusでdownの条件を指定する場合は2を、upの条件の場合は1を入力すれば検知します。

複数の組み合わせや、完全一致・正規表現も利用出来ます。

このように、DataBindingの値を指定すれば細かく通知条件を指定する事が出来ます。

しかし、拡張MIBを利用する場合、DataBindingの内容はベンダーによりさまざまです。さらに、例で示したのは数字を指定する形ですが、テキスト（データ型ではString）のDataBindingもあります。さらにシチュエーションにより内容もかわってきます。

そのため、該当のTRAPがどのようなDataBindingを付与するかの詳細については各ベンダーサポートにご確認をお願いします。

24.3.5. 動作確認テスト

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

今回登録したCiscoの「CISCO-CONFIG-MAN-MIB」の「ciscoConfigManEvent」は機器の設定ファイルを上書きしたらTRAPを通知します。

（その他の動作でもTRAPを通知しますが、例ではこちらの動作を記載します）

altitude_trap_check テスト前には設定のバックアップを取得するようにしてください

24.3.5.1. テストコマンドの発行

今回の例ではCisco Catalyst2950を使用しています。

まずは通知前のサービスの状態を確認しておきましょう。

altitude_trap_check_testcmd

スイッチでテストコマンドを発行します。

SW-TEST# copy run start

これでトラップが送信されます。サービス一覧を確認します。

altitude_trap_check_testcmd2

該当のサービスがcriticalになっています。

さらにステータス情報には登録したMIBファイルにひも付られる情報（MIBファイル内に記載されているメッセージ）が表示されます。

また、例ではメール通知をしておりますのでメールも届きます。

altitude_trap_check_testcmd3

24.3.5.2. TRAP履歴

トラップについては、[メニュー] の[TRAP履歴]からも確認出来ます。

altitude_trap_history

TRAPログは、X-MONに通知条件の設定（監視の設定）がされているサービスのログの履歴が記録されています。不明TRAPログは、反対に通知条件の設定がされていないTRAPが記録されています。

セキュリティ上必要ないTRAPやTRAPのテストでOIDを確認する場合はここを調べてください。また、特定の機器から不明なTRAPを受けると通知を行う事が「非監視SNMP TRAP通知設定」にて可能です。

こちらの設定方法は不明なTRAPを通知するをご参照ください。

■ TRAPログ

altitude_trap_history2

■ 不明TRAPログ

altitude_trap_history3

24.3.5.3. 監視の復旧方法

通知された監視を知らせるにはパッシブの結果を送るという動作になります。

[サービス一覧表示]から該当のホストのサービス情報画面の[サービス詳細]タブを開きます。今回の例では「SW-TRAP」ホストの「snmp-trap-test」になります。

altitude_trap_rec

[サービス詳細]タブのメニューの中から「このサービスのパッシブチェックの結果を送信」を開きます。

altitude_trap_rec2

項目の入力画面になります。

チェック結果をOKにします。（デフォルトで選択されています）チェック出力は必須入力となります。例えば「トラップ検知のテストのためOK」や実際の運用では「トラップ確認、対応完了」などを記載するといいでしょう。

altitude_trap_rec3

入力出来たら[発行]を押します。

コマンドを正常に受け付けた画面となります

altitude_trap_rec4

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

サービス一覧表示にてステータス情報がパッシブの結果を送信の際に入力した「ログ検知のテストのためOK」というステータスとなり正常（OK）で復旧しています。

altitude_trap_rec5

また、通知先にも下記のような復旧のメールが届きます。

altitude_trap_rec6

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

24.3.5.4. その他の機器でのテスト

サーバソフトウェアの中にはGUIの画面からテストを実施する事が可能なものもあります（TrendMicro社ServerProtectなど）。また、Windowsサーバからもテストは可能です。

稼働中の機器のためテストが出来ない場合、linuxからコマンドでテストする事も可能です。その場合は、テスト用のlinuxサーバをホスト登録し、通知条件でテストホストを追加してテストホストにも通知条件を設定してください。既にホスト登録しているサーバでテストを実施して頂いても結構です。

■ テストを行うLinuxサーバを追加

altitude_trap_etc

altitude_trap_etc2

今回の例では、OIDは「.1.3.6.1.4.1.9.9.43.2.0.1」でX-MONサーバのIPアドレスが「192.168.19.201」ですので、Linuxサーバにて発行するコマンドは

# snmptrap -v 2c -c public 192.168.19.201 '' .1.3.6.1.4.1.9.9.43.2.0.1

となります。

監視ホストにはコミュニティ名の設定はしておりませんが、TRAPはX-MONサーバで受け取りますので、デフォルトのpublicを指定します。

コマンドが発行出来たらサービス一覧を確認します。

■ テスト後

altitude_trap_etc3

Linux-TRAPから発行しましたので、Linux-TRAPのみ、CRITICALを検知しました。

このOIDは正常にX-MONで監視が出来る事が確認出来ました。

24.3.6. 任意のSNMP TRAPを設定する

基本的な使い方以外に、MIBファイルがないOIDなど任意のSNMP TRAPを設定する事が出来ます。

例えば、サーバでバッチスクリプトを定期動作させており、バッチスクリプト完了時にTRAPを送信する設定すればX-MONにてバッチ処理の監視が可能です。

また、Windowsサーバにてイベントトラップトランスレーターを使用する場合はエンタープライズOIDを使用しますので、こちらで登録します。

本セクションではLinuxとWindowsの設定例を取り上げます。

24.3.6.1. 設定画面

[メニュー]の[SNMP TRAP管理]から[任意SNMP TRAP通知条件一覧]を開いてください。

altitude_trap_any_set

何も登録されていない場合は「任意OIDのTRAPを受信した際の挙動を登録して下さい。」と表示されます。

[新規作成]を開いてください。条件を入力する画面が開きます。

altitude_trap_any_set2

それぞれの項目は以下となります。

ステータス	内容
TRAP名	登録するTRAP名を定義します。既に登録されているMIBファイル名、TRAPオブジェクト名禁止。
OID	登録する任意TRAPのOIDを指定します
メッセージフォーマット(省略可)	登録したTRAPが送られてきた場合に、サービス一覧表示「ステータス情報」の欄に表示される情報を記述します
文字コード	送られてくるメッセージの文字コードを指定します。
対象ホスト	通知対象となるホストを選択します。選択したい「ホスト名称」の頭文字や「ホストグループ名称」を選択し、表示された選択肢からホストを選択し、「↑(選択)」をクリックします。また、ホストを除外する場合は、任意のホストを選択後、「↓(外す)」ボタンをクリックします。
通知先グループ	任意SNMP TRAP通知条件に反応した場合に通知する通知先グループを選択します。選択したい「ユーザグループ名称」の頭文字を選択し、表示された選択肢から通知先を選択し、「↑(選択)」をクリックします。また、通知先を除外する場合は、任意の通知先を選択後、「↓(外す)」ボタンをクリックします。通知先の登録は、ユーザグループ管理 - ユーザグループの作成、編集を参照してください。通知先グループはサービス登録・編集時でも指定が可能な為、どちらの設定条件を優先すべきか選択できます。「チェックで上書き登録/チェックなしで通知先を更新しない」にチェックを付けた場合、通知先情報を上書きし登録します。
通知先サービス名	対象ホストに入力した通知先サービス名が登録されます。新規作成時のみ設定が可能であり、変更はできません。入力制限：入力必須、半角英数字、アンダーバー、ドット、ハイフンのみ。また、以下の通知先サービス名は設定できません。・「-VMPERF」で終わる・間に「-VMPERF-」を含む・間に「-VMWARE-」を含む
通知ステータス	対象TRAPが通知条件と一致した場合にX-MONに投げるステータス情報を「OK」「WARNING」「CRITICAL」「UNKNOWN」から選択します。

24.3.6.2. OIDについて

OIDには標準MIBと拡張MIB（別名：エンタープライズMIB）があります。

標準MIBは多くのベンダーで共通で使用されている定義で、拡張MIBがベンダー独自に定義しているMIBとなります。任意でのOIDを作成する場合、この拡張MIBを指定する形となります。しかし、拡張MIBはIANA(http://www.iana.org/)にて登録する必要があります。独自にする際のOIDは

.1.3.6.1.4.1.

から始まるようにしてください。この.1.3.6.1.4.1.から始まるOIDは拡張MIBであることを意味しています。また、使用する際はプライベートネットワーク内でのみ使用するようにお願いします。（すでに登録されているIANAの拡張MIBと被る可能性があるため）

24.3.6.3. 設定例(Linuxサーバからの任意TRAP通知)

設定例として、Linuxサーバから
.1.3.6.1.4.1.3.3.3.4
というOIDを受信したらメッセージ（ステータス情報で表示される）に「任意トラップテスト」と表示するようにしましょう。

設定項目は表の通りです。

ステータス	内容
TRAP名	TRAP-ORI-TEST
OID	.1.3.6.1.4.1.3.3.3.4
メッセージフォーマット	任意トラップテスト
文字コード	UTF-8
対象ホスト	Linux-TRAP
通知先グループ	webチーム
通知先サービス名	TRAP-ORI-TEST
通知ステータス	CRITICAL

条件を設定した例は下記となります。

■ テストを行うLinuxサーバを追加

altitude_trap_any_lin

条件名と通知先サービス名は別の名前を指定出来ますが、同じにしておくほうが管理しやすくなります。

記入が出来たら[作成と承認] ボタンを押して作成してください。

altitude_trap_any_lin2

作成が出来ると、一覧の画面に戻り、「TRAP-ORI-TESTを設定しました」と表示されます。反映させるため、X-MONを再起動させてください。

altitude_trap_any_lin3

サービスの一覧で確認してみましょう。

■ 正常時

altitude_trap_any_lin4

正常に追加されています。

確認する際のコマンドは

# snmptrap -v 2c -c public 192.168.19.201 '' .1.3.6.1.4.1.3.3.3.4

となります。テストの準備が出来たらコマンドを発行してください。

24.3.6.3.1. テストの確認

■ TRAP検知

altitude_trap_any_lin5

正常に任意SNMPTRAPが検知したら画像のようになります。

ステータス情報にも「任意トラップテスト」と設定した文字列が表示されます。

またメールでも通知先を設定していますので、画像のようにメールが送信されます。

■ 検知メール

altitude_trap_any_lin6

監視を復旧させる際は基本操作と同じくパッシブからOKをして復旧させてください。

これで、任意のSNMP TRAPである、OID「.1.3.6.1.4.1.3.3.3.4」は正常に登録されており、検知可能であることがわかりました。

24.3.6.4. 設定例（Windowsサーバからの任意TRAP通知）

WindowsサーバのSNMP TRAPはMIBファイルがないため任意SNMP TRAP通知で設定します。

WindowsサーバにはデフォルトでSNMP TrapサービスはインストールされていますがTRAP通知の設定をするにはSNMPサービスをインストールする必要があります。インストール手順は別途、SNMP導入手順をご参照ください。

■ SNMPサービス

altitude_trap_any_win

24.3.6.4.1. 通知先の設定

WindowsサーバのSNMPサービスからTRAPの通知先を設定します。

[サービス]から [SNMP Service] を右クリックし、[プロパティ] を開いてください。

altitude_trap_any_win2

プロパティ画面が表示されますので、「トラップ」タブを開きます。

altitude_trap_any_win3

X-MONのデフォルトのコミュニティ名である「public」と入力し、[一覧に追加] ボタンを押してください。

altitude_trap_any_win4

[一覧に追加] をすると、[トラップ送信先] に[追加]ボタンがアクティブになりますので、[追加] を押します。

altitude_trap_any_win5

IPアドレスを入力する画面が出ますのでX-MONサーバのIPアドレスを入力します。

altitude_trap_any_win6

入力できたら[追加] を押してください。

これでコミュニティ名「public」でトラップ送信先が「192.168.19.201」が登録できました。[OK]ボタンを押してプロパティを閉じてください。

altitude_trap_any_win7

24.3.6.4.2. TRAPの送信

WindowsサーバにてSNMP TRAPを送信するにはイベントトラップトランスレーターで設定します。

コマンドプロンプトにて、「evntwin.exe」を実行します。

altitude_trap_any_trapsend

イベントトラップトランスレーターが起動します。何も設定が入っていない場合は空欄となります。詳細はマイクロソフトのサポートマニュアルをご参照ください。

altitude_trap_any_trapsend2

設定例では、DHCPクライアントサービスが停止すればトラップを送信する、という設定を行います。

[構成の種類] のラジオボタンを[カスタム] を選択します。

[編集] ボタンがアクティブになりますので開きます。

altitude_trap_any_trapsend3

ウィンドウの下部分にイベントソースなどが表示されます。

altitude_trap_any_trapsend4

イベントソースの中の[System -> Microsoft-Windows-Dhcp-Client]で、50037番を選択します。

この50037番がDhcpクライアントサービスが停止したイベントの番号です。

■ イベントソースを選択

altitude_trap_any_trapsend5

この番号はイベントビューアーにて確認が出来ます。

そのため他の任意のサービスやイベントにトラップを設定する際はイベントビューアーからイベントIDを検索してください。

altitude_trap_any_trapsend6

イベントの50037番を選択し、[追加]を押してください。

altitude_trap_any_trapsend7

追加されると、「トラップに変換するイベント」に追加されます。

altitude_trap_any_trapsend8

OIDを確認するには[設定] を開きます。

altitude_trap_any_trapsend9

エンタープライズOIDとイベント固有のIDを足したものがOIDとなります。

しかし、Windowsサーバの場合、OIDがとても長くなっていまいます。

そのため、X-MON側では通知設定はまだせず、テストでトラップを送信し、SNMP TRAP履歴の不明トラップの画面でOIDを確認する方法をとります。

[OK]で画面が戻ります。

画面が戻り、[適用]を押してください。これで設定は完了です。

altitude_trap_any_trapsend10

それでは、実際にTRAPを送信します。

サービスの画面にて[DHCP Client]を停止させます。

実際にサービスを停止して確認をする際は、サービス影響に問題がないか確認してから実施するようにしてください

■ サービスの停止

altitude_trap_any_trapsend11

altitude_trap_any_trapsend12

サービスが停止したのを確認してX-MONのTRAP履歴の不明TRAPログを確認します。

■ 不明TRAPログ

altitude_trap_any_trapsend13

画像のように、送信元ホストが設定したWindowsサーバ、受け取ったメッセージの部分に「DHCPv4 クライアントサービスが停止しました。」というメッセージが含まれていれば正常にTRAPが送信され、X-MONでも受信出来ている事が確認出来ました。

受け取ったOIDの部分のOIDを任意SNMP TRAP通知で設定します。

24.3.6.4.3. X-MONへ通知条件の設定

前章にて調べた（不明TRAPログにて確認した）OIDを使用します。

設定項目は表の通りです。

項目	内容
TRAP名	TRAP-Windows-TEST
OID	1.3.6.1.4.1.311.1.13.1.29.77.105.99.114.111.115.111.102. 116.45.87.105.110.100.111.119.115.45.68.104.99.112.45.67. 108.105.101.110.116.0.50037
メッセージフォーマット	任意トラップWindowsテスト
文字コード	SJIS
対象ホスト	Windows-TRAP
通知先グループ	webチーム
通知先サービス名	TRAP-Windows-TEST
通知ステータス	CRITICAL

条件を設定した例は下記となります。

■ 任意SNMP TRAP通知条件の設定

altitude_trap_any_notiset

条件名と通知先サービス名は別の名前を指定出来ますが、同じにしておくほうが管理しやすくなります。また、Windows環境から送られてきますので文字コードを「SJIS」にしています。

記入が出来たら[作成と承認] ボタンを押して作成してください。

altitude_trap_any_notiset2

作成が出来ると、一覧の画面に戻り、「TRAP-Windows-TESTを設定しました」と表示されます。反映させるため、X-MONを再起動させてください。

altitude_trap_any_notiset3

サービスの一覧で確認してみましょう。

監視が追加されている事が確認出来ました。

altitude_trap_any_notiset4

これで通知条件の設定は完了です。

24.3.6.4.4. テストの確認

それでは、 TRAPの送信で実施したように、Windows上でTRAPを発生させてX-MONで検知するかテストしてみましょう。

実際にサービスを停止して確認をする際は、サービス影響に問題がないか確認してから実施するようにしてください

■ サービスの停止

altitude_trap_any_notiset5

altitude_trap_any_notiset6

サービス一覧で確認してみましょう。

■ 検知後

altitude_trap_any_notiset7

正常に検知しています。

ステータス情報の欄には、通知条件で設定した「任意トラップWindowsテスト」の後にTRAPに含まれるメッセージが表示されます。

メールの通知先には下記のようなメールが届きます。

こちらにもステータス情報が記載されています。

altitude_trap_any_notiset8

監視を復旧させる際は基本操作と同じくパッシブからOKをして復旧させてください。

これで、正常に登録されており、検知可能であることがわかりました。

24.3.6.5. 通知条件の編集する

通知条件を編集するには、通知条件の詳細から行います。

任意SNMP TRAP通知条件一覧から該当の通知条件の詳細を表示させ、下の[編集] を開きます。

altitude_trap_any_notiedit

編集画面が開きますので、編集したい項目を編集してください。

編集が完了したら、[作成と承認] を押して完了後、X-MONを再起動させます。

altitude_trap_any_notiedit2

24.3.6.5.1. 編集できる項目について（サービス設定からの編集）

SNMP TRAP管理からは通知条件について編集を行いますが、再通知間隔やステータスによる通知の有無、また通知先グループについては[ホスト管理] の[サービス設定] から編集を行います。

altitude_trap_any_notiedit3

該当のサービスの[ 詳細表示] を開きます。一番下に[編集]がありますので開きます。

altitude_trap_any_notiedit4

編集画面が開きますので、編集する項目を編集してください。

この際、「サービス監視用コマンド」の部分についてはSNMP TRAP管理部分にて動作をさせるための項目ですので編集しないようにお願いします。

編集が完了したら、[編集] もしくは[編集と承認]にて完了させ、X-MONを再起動させてください。

altitude_trap_any_notiedit5

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

通知条件を削除するには[任意SNMP TRAP通知条件一覧] から行います。

削除する該当のTRAPの[詳細表示] を開きます。

altitude_trap_any_del

詳細が表示されますので、[削除と承認] ボタンを開きます。

altitude_trap_any_del2

確認ウィンドウが出ますので、OKでしたら[OK]を押してください。

altitude_trap_any_del3

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

altitude_trap_any_del4

登録しているMIBファイルを削除する場合は、監視設定がされている場合、削除ができませんが、任意SNMP TRAP通知の場合、登録したOIDが監視設定されていてもOIDを監視が削除されます。

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

SNMP TRAP管理以外にも、[ホスト管理] の[サービス設定]からも通知条件は削除出来ます。どちらで削除を行っても動作への影響はありません。

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

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

altitude_trap_any_del5

確認ウィンドウが出ますので、OKでしたらOKを押してください。

altitude_trap_any_del6

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

altitude_trap_any_del7

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

24.3.7. 不明なTRAPを通知する

「非監視SNMP TRAP通知設定」を使用すると、対象ホストの通知条件を設定していないTRAPを受信したらX-MONへ通知します。MIBファイルで定義されているTRAPも、定義されていないTRAPも全てが対象となります。

検知するTRAPは[MENU] の [TRAP履歴] 内、[不明TRAPログ]の部分となります。

altitude_trap_unknown

24.3.7.1. 設定画面

[MENU] の [SNMP TRAP管理] の [非監視SNMP TRAP設定] を開きます。

altitude_trap_unknown_set

それぞれの項目は以下となります。

項目	内容
対象TRAP	デフォルトTRAPの条件が表示されます。デフォルトTRAPは、X-MONで登録されていない TRAPや、条件に一致しなかったTRAPが対象となりますこの項目は固定で変更は出来ません。
対象ホスト	通知対象となるホストを選択します。選択したい「ホスト名称」の頭文字や「ホストグループ名称」を選択し、表示された選択肢からホストを選択し、「↑(選択)」をクリックします。また、ホストを除外する場合は、任意のホストを選択後、「↓(外す)」ボタンをクリックします。
通知先グループ	デフォルトTRAPが反応した場合に通知する通知先グループを選択します。選択したい「ユーザグループ名称」の頭文字を選択し、表示された選択肢から通知先を選択し、「↑(選択)」をクリックします。また、通知先を除外する場合は、任意の通知先を選択後、「↓(外す)」ボタンをクリックします。通知先の登録は、ユーザグループ管理 - ユーザグループの作成、編集を参照してください。通知先グループはサービス登録・編集時でも指定が可能な為、どちらの設定条件を優先すべきか選択できます。「チェックで上書き登録/チェックなしで通知先を更新しない」にチェックを付けた場合、通知先情報を上書きし登録します。
通知先サービス名	対象ホストに登録する際のサービス名を表示します。「DEFAULT-TRAP」というサービス名で固定されます。
通知ステータス	対象サービスにステータス通知する際のステータスを表示します。「UNKNOWN」で固定されます。

先にも記載しましたが、本設定は対象ホストの不明TRAPとなります。

「対象ホスト」で複数の通知対象のホストを選択（選択したホストに監視が追加されます）すると同じ「DEFAULT-TRAP」で対象ホストにサービスが追加されます。

その場合、不明TRAPを受信した際は送信元のホストと一致したホストのみが通知されます。

24.3.7.2. 設定例

それでは設定してみましょう。

前章でも記載しましたが、全ての不明TRAPを検知しますので、対象ホストはX-MONのみとし、通知先にWebチームを選択します。

■ 設定例

altitude_trap_unknown_set2

入力が出来たら、[設定] ボタンを押してください。

altitude_trap_unknown_set3

「設定を変更し反映しました」と画面に表示されますので、X-MONを再起動してください。

altitude_trap_unknown_set4

確認してみましょう。

サービス一覧のX-MONに「DEFAULT TRAP」が表示されます。

altitude_trap_unknown_set5

検知するかテストしてみましょう。

前章の任意SNMP TRAP通知で使用した「.1.3.6.1.4.1.3.3.3.4」ではなく「.1.3.6.1.4.1.3.3.3.5」をLinuxサーバからTRAPを送信してみます。

# snmptrap -v 2c -c public 192.168.19.201 '' .1.3.6.1.4.1.3.3.3.5

TRAPを受け取り、UNKnown状態となります。

■ TRAPを受け取った

altitude_trap_unknown_set6

不明TRAPログも確認すると、履歴にも記載がされています。

■ 不明TRAPログ

altitude_trap_unknown_set7

これでX-MONサーバに対して、不明なTRAPが通知されても、すぐに検知する事が出来るようになります。

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

[MENU] の [SNMP TRAP管理] の [非監視SNMP TRAP設定] を開きます。

altitude_trap_unknown_edit

新規に作成するのと同じく、この画面が編集する画面となりますので編集する項目を入力し、[設定] を押して完了し、X-MONを再起動させてください。

24.3.7.3.1. 編集できる項目について（サービス設定からの編集）

SNMP TRAP管理からは通知条件について編集を行いますが、再通知間隔やステータスによる通知の有無、また通知先グループについては[ホスト管理] の[サービス設定] から編集を行います。

altitude_trap_unknown_edit2

該当のサービスの[詳細表示] を開きます。一番下に[編集]がありますので開きます。

altitude_trap_unknown_edit3

編集画面が開きますので、編集する項目を編集してください。

この際、「サービス監視用コマンド」の部分についてはSNMP TRAP管理部分にて動作をさせるための項目ですので編集しないようにお願いします。

編集が完了したら、[編集] もしくは[編集と承認]にて完了させ、X-MONを再起動させてください。

altitude_trap_unknown_edit4

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

通知条件の削除は[ホスト管理] の[サービス設定]から行います。

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

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

altitude_trap_unknown_del

確認ウィンドウが出ますので、OKでしたらOKを押してください。

altitude_trap_unknown_del2

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

altitude_trap_unknown_del3

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

24.3.7.5. 非監視TRAPの運用使用例

使用例として、下記画像のように「サービスがシャットダウンした」というTRAPが通知されてきたとします。

■ 使用例

altitude_trap_unknown_ope

ステータス情報だけでは、どのIPアドレスが送信元なのかわからないため、[TRAP履歴] の[不明トラップ]を確認します。

送信元IPアドレスと、メッセージの内容が記載されていますので、障害や負荷に問題がないか確認し、すぐに対応する事が出来ます。

■ 不明TRAP

altitude_trap_unknown_ope2

利点としてはMIB毎に通知設定していなくても通知をしてくれます。

しかし全ての不明TRAPを通知しますので環境に合わせて使用しましょう。

24.3.8. サービス設定からの設定について（共通）

SNMP TRAP管理で設定できる各TRAPの項目でも解説していますが、通知条件を作成し、ホストのサービス設定から設定する項目で重要な点について記載します。

24.3.8.1. 通知先を編集する

メールの通知先については通知条件を新規作成する際に設定出来ますが、通知先を追加、削除する等編集したい場合はサービス設定から実施する必要があります。

altitude_trap_serviceset_noti

24.3.8.1.1. 複数ホストを対象にしている場合

TRAPの対象ホストを複数設定している場合、サービス設定で通知先を編集すると編集した該当のホストの通知先のみ編集されます。

例）snmp-trap-testをLinux-TRAP、SW-TRAPにホストを対象ホストとして設定。

通知先をwebチームとする。

altitude_trap_serviceset_noti2

この通知条件で設定するLinux-TRAP、SW-TRAPに通知条件（監視設定）が作成されます。

altitude_trap_serviceset_noti3

Linux-TRAPのサービス設定でsnmp-trap-testの通知先グループをDBチームに変更します。

altitude_trap_serviceset_noti4

こうする事で、Linux-TRAPのsnmp-trap-testの通知先グループはDBチームとなりますがSW-TRAPのsnmp-trap-testの通知先はwebチームのまま変更はされません。

これにより、同じトラップ通知条件でもホストによって通知先を変更する事が可能です。

altitude_trap_serviceset_noti5

ただし、全ての通知先グループの変更が必要な場合は、設定されているサービス全てを変更する必要があります。

24.3.8.1.2. 対象ホストを変更した際の挙動について

snmp-trap-test02をLinux-TRAPを対象ホストとして設定。

通知先グループをwebチームとする。

altitude_trap_serviceset_noti6

この通知条件で設定するLinux-TRAPに通知条件（監視設定）が作成されます。

altitude_trap_serviceset_noti7

SNMP TRAP管理より、通知条件を編集します。編集する内容は対象ホストにSW-TRAPを追加します。これにより、Linux-TRAP、SW-TRAPに通知条件（監視設定）が設定されます。

altitude_trap_serviceset_noti8

altitude_trap_serviceset_noti9

しかし、追加されたホスト（SW-TRAP）は通知先が設定されません。

■ 追加したホストは通知先グループが設定されない（右側）

altitude_trap_serviceset_noti10

そのため、サービス設定より通知先を編集する必要がありますので、対象ホストを追加した際はご注意ください。

24.3.8.2. TRAPを受信するたびに通知を行う（volatileサービスの設定）

X-MONの仕様により、一度ステータスが変化すると、次にステータスが変化するか再通知間隔の時間が過ぎるまで通知は実施されません。

そのため、同じTRAP名で複数の通知条件を設定している場合に同じステータスのまま違う内容のTRAPを受け取っても、ステータスが変化しないために通知が実施されません。

例）同じ通知先サービス名・ステータスを設定しているが、対象TRAPが違う

altitude_trap_serviceset_volatile

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

altitude_trap_serviceset_volatile2

volatileサービスを設定する事により、同じステータスであっても別の内容のTRAPを受信（厳密にはTRAPを受信するたびに）すると通知を行います。デフォルトではこの機能は無効となっています。

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

altitude_trap_serviceset_volatile3

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

SNMP TRAPの通知条件では、パッシブチェックを利用し、TRAPを受信したら通知を実施する設定となっています。

そのため、サービス設定のアクティブチェックは無効、試行回数は1の設定が通知条件を作成した際に設定されます。

設定項目	設定値	目的
アクティブチェック	無効にする	SNMP TRAP監視は待ち受ける監視のため。
試行回数	1	TRAPを1件受信したら即座にハードステータスとなり、メール等の通知が実施されます。

■ 詳細

altitude_trap_serviceset_volatile4

並びに、パッシブチェックも有効となっています。

SNMP TRAPを受信する際、上記内容は変更しないようにお願いします。