サーバでは、ログの情報を見て、特定の文字列が含まれていたときに、警告を出したいこともある。
例えば、/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秒)調べるようになる。
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種類のデータとして得られる。
正規表現にマッチした累計だ。この値は、クリアされることがない。
該当ファイルでマッチした回数だ。ファイルに対するマッチであるから、この値は、ログがローテートされるなど、新しいファイルとして作成し直されれば、クリアされることになる。
今回に限ってマッチした回数だ。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」の使い方を説明する予定だ。
Copyright © ITmedia, Inc. All Rights Reserved.