第6回 サーバ異常をSNMPで通知させるには:SNMPによるネットワークモニタリング「第2版」(6/6 ページ)
SNMPでサーバリソースを監視するとさまざまな状況を把握することができる。異常となる予兆をとらえることができ、その予兆はメールなどで受け取ることが可能だ。
ログ内文字列の監視
サーバでは、ログの情報を見て、特定の文字列が含まれていたときに、警告を出したいこともある。
例えば、/var/log/secureファイルに「authentication failure」という文字列(認証に失敗した)が書き込まれたときに警告を出すといった具合だ。このような目的にも使えるよう、Net-SNMPには、ファイルが特定の正規表現にマッチするかどうかを調べる機能が備わっている。
その機能は、snmpd.conf内に次のようなlogmatchディレクティブを指定することで有効にできる。
*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***
logmatchディレクティブは、最大50個まで指定できるものだ。
「名称」は監視するときの名前であり、任意のものでよい。次の検査間隔は、問い合わせがない場合でも、そのファイルに対して正規表現の条件マッチを実行する間隔であり、単位は秒だ。
検査間隔は、後述するlogMatchTableに対して問い合わせがないときでも監視するタイミングを指定する。logMatchTableを参照したときには、その時点でリアルタイムに検査される。よってSNMPマネージャ側から定期的にlogMatchTableを参照する場合には、検査間隔は重要ではない。検査間隔が必要となるのは、マッチしたときにSNMPトラップを仕掛けたいような場合だ
例えばリスト5のように指定すると、/var/log/secureファイルに「authentication failure」という文字列が入っているかどうかを、最低でも5分に1回(300秒)調べるようになる。
*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***
このときlogMatchTableを参照すると、次のようになる。
*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***
正規表現にマッチした箇所は、次の3種類のデータとして得られる。
- logMatchGlobalCounter/logMatchGlobalCount
正規表現にマッチした累計だ。この値は、クリアされることがない。
- logMatchCurrentCounter/logMatchCurrentCount
該当ファイルでマッチした回数だ。ファイルに対するマッチであるから、この値は、ログがローテートされるなど、新しいファイルとして作成し直されれば、クリアされることになる。
- logMatchCounter/logMatchCount
今回に限ってマッチした回数だ。Net-SNMPでは、内部で前回にチェックしたファイルのバイト位置を保存しており、「前回チェックしたとき以降の場所」にマッチした回数だけが含まれる。この値は、読み取るたびにクリアされる。
もしログファイルに何かチェックしたい値が書き込まれたときにアラートを発生させるといった目的で使うのなら、logMatchCounter/logMatchCountを使うことになるだろう。そうではなく何回書き込まれたのかという統計をとりたいときにはlogMatchGlobalCounter/logMatchGlobalCountを使うことになるだろう。
表6■logMatchサブツリー
名称 | OID | 意味 |
---|---|---|
logMatchIndex | ucdavis.16.1 | インデックス番号 |
logMatchName | ucdavis.16.2 | 名称。logmatchディレクティブに設定した名称 |
logMatchFileName | ucdavis.16.3 | 調査するファイル名。logmatchディレクティブに設定したファイル名 |
logMatchRegEx | ucdavis.16.4 | 調査する正規表現。logmatchディレクティブに設定した正規表現 |
logMatchGlobalCounter | ucdavis.16.5 | 正規表現がマッチした個数の累計(COUNTER)。ファイルが作り直されたとしても値はクリアされない |
logMatchGlobalCount | ucdavis.16.6 | 同上(INTEGER32) |
logMatchCurrentCounter | ucdavis.16.7 | ファイル内で正規表現がマッチした個数。(COUNTER) |
logMatchCurrentCount | ucdavis.16.8 | 同上(INTEGER32) |
logMatchCounter | ucdavis.16.9 | 前回の読み出し位置よりも後ろにおいて、正規表現がマッチした個数(COUNTER) |
logMatchCount | ucdavis.16.10 | 同上(INTEGER32) |
logMatchCycle | ucdavis.16.11 | 検査間隔(秒)。logmatchディレクティブに設定した値 |
logMatchErrorFlag | ucdavis.16.100 | 正規表現の実行エラーが発生したときには1 |
logMatchRegExCompilation | ucdavis.16.101 | logMatchErrorFlagが1であるときのエラーメッセージ |
第5回目と今回の第6回目に渡り、MIBツリーにどのような情報があり、どのようにすればアクセスできるのかについて説明した。
多数の表を提示したが、これらの表を見れば「どんな情報を取得するときに、どのOIDをもつオブジェクトを参照すればよいのか」が分かる。
さて、次に考えなければならないのが、どのようにして値を定期的に取得するのか、そして、監視対象が異常値を示したときに、それをどうやって報告するのかという点だ。次回はオブジェクトの値を定期的に読み取って統計をとり、それをグラフ化するフロントエンドツール「RRDTool」の使い方を説明する予定だ。
関連記事
- 第5回 図解で知るSNMP――MIB情報のすべて
- 第4回 SNMPとv3セキュリティ
- 第3回 SNMPによるモニタリングセキュリティの実態
- 第2回 現在版サーバ運用の隠れた“モニタリング事情”
- 第1回 サーバ監視にSNMPを使う理由
関連リンク
Copyright © ITmedia, Inc. All Rights Reserved.