第6回 サーバ異常をSNMPで通知させるにはSNMPによるネットワークモニタリング「第2版」(6/6 ページ)

» 2007年05月25日 07時59分 公開
[大澤文孝,ITmedia]
前のページへ 1|2|3|4|5|6       

ログ内文字列の監視

 サーバでは、ログの情報を見て、特定の文字列が含まれていたときに、警告を出したいこともある。

 例えば、/var/log/secureファイルに「authentication failure」という文字列(認証に失敗した)が書き込まれたときに警告を出すといった具合だ。このような目的にも使えるよう、Net-SNMPには、ファイルが特定の正規表現にマッチするかどうかを調べる機能が備わっている。

 その機能は、snmpd.conf内に次のようなlogmatchディレクティブを指定することで有効にできる。


logmatch [名称ファイルのフルパス名] [検査間隔] [正規表現]

 logmatchディレクティブは、最大50個まで指定できるものだ。

 「名称」は監視するときの名前であり、任意のものでよい。次の検査間隔は、問い合わせがない場合でも、そのファイルに対して正規表現の条件マッチを実行する間隔であり、単位は秒だ。

 検査間隔は、後述するlogMatchTableに対して問い合わせがないときでも監視するタイミングを指定する。logMatchTableを参照したときには、その時点でリアルタイムに検査される。よってSNMPマネージャ側から定期的にlogMatchTableを参照する場合には、検査間隔は重要ではない。検査間隔が必要となるのは、マッチしたときにSNMPトラップを仕掛けたいような場合だ

 例えばリスト5のように指定すると、/var/log/secureファイルに「authentication failure」という文字列が入っているかどうかを、最低でも5分に1回(300秒)調べるようになる。

リスト5■ファイルサイズを監視するsnmpd.conf内記述の例

logmatch serucelog /var/log/secure 300 "authentication failure"

 このときlogMatchTableを参照すると、次のようになる。


$ snmpwalk -c hogeprivate -v 1 localhost logMatchTable
UCD-SNMP-MIB::logMatchIndex.1 = INTEGER: 1
UCD-SNMP-MIB::logMatchName.1 = STRING: serucelog
UCD-SNMP-MIB::logMatchFilename.1 = STRING: /var/log/secure
UCD-SNMP-MIB::logMatchRegEx.1 = STRING: "authentication failure"
UCD-SNMP-MIB::logMatchGlobalCounter.1 = Counter32: 1
UCD-SNMP-MIB::logMatchGlobalCount.1 = INTEGER: 1
UCD-SNMP-MIB::logMatchCurrentCounter.1 = Counter32: 1
UCD-SNMP-MIB::logMatchCurrentCount.1 = INTEGER: 1
UCD-SNMP-MIB::logMatchCounter.1 = Counter32: 0
UCD-SNMP-MIB::logMatchCount.1 = INTEGER: 0
UCD-SNMP-MIB::logMatchCycle.1 = INTEGER: 300
UCD-SNMP-MIB::logMatchErrorFlag.1 = INTEGER: 0
UCD-SNMP-MIB::logMatchRegExCompilation.1 = STRING: Success

 正規表現にマッチした箇所は、次の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」の使い方を説明する予定だ。

この記事に関連するキーワード

オープンソース | SNMP | Linux


前のページへ 1|2|3|4|5|6       

Copyright © ITmedia, Inc. All Rights Reserved.

注目のテーマ