同様の方法で、モニタリングする対象を変更すれば、任意のオブジェクトの異常をSNMPトラップへと変換できる。
「第6回 サーバ異常をSNMPで通知させるには」で説明したが、Net-SNMPには、メモリ不足、ロードアベレージ異常、ディスク容量不足、ファイルサイズ超過といったタイミングで、値が「0」から「1」へと変化するエラー通知のためのオブジェクトがあったことを思い出してほしい。
これらのオブジェクトをSNMPトラップへと変換すれば、サーバが異常になったことを管理者へと伝えることができるのは言うまでもない。実際にファイルサイズ超過の監視を試みたのが、リスト2である。
# /tmp/dummy.txtが100Kを超えないかを監視
file /tmp/dummy.txt 100
# ここではイベントに対して適当なOIDを付けた
notificationEvent fileOverSize .1.3.6.1.4.1.8072.99999.1 fileSize
monitor -r 60 -e fileOverSize -u _internaluser "File Too Big" fileErrorFlag == 1
なお、「第6回 サーバ異常をSNMPで通知させるには」で説明したように、ファイルサイズはfileディレクティブで監視することができ、サイズを超過したときにはfileErrorFlagが1となるので、その値をmonitorで監視している。そして、次のように、「.1.3.6.1.4.1.8072.99999.1」という適当なOIDをもつSNMPトラップを発生させるようにした。
notificationEvent fileOverSize .1.3.6.1.4.1.8072.99999.1 fileSize
最後に指定している「fileSize」は、fileTableサブツリー以下のファイルサイズを示すオブジェクトである。すなわち、このSNMPトラップには、data bindingとして、現在のファイルサイズが含まれることになる。
実際にやってみよう。まずは、ダミーの/tmp/dummy.txtを作成する。
$ touch /tmp/dummy.txt
このときは、まだ何も起きない。次に、ファイルサイズを大きくしてみる(関連記事)。
$ dd if=/dev/zero of=/tmp/dummy.txt bs=110K count=1
そして1分が経過すると、次のようなメッセージが渡っていることが、snmptrapdが書き出すsyslogで確認できるはずだ。1分経過しないとSNMPトラップが発生しないのは、リスト2にて「-r 60」と指定し、60秒ごとに値を調べているためである。
May 31 12:07:14 xencentos5 snmptrapd[6748]: 2007-05-31 12:07:14 [UDP: [127.0.0.1]:32785]: DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (12006) 0:02:00.06 SNMPv2-MIB::snmpTrapOID.0 = OID: NET-SNMP-MIB::netSnmp.99999.1 UCD-SNMP-MIB::fileSize.1 = INTEGER: 250880 kB
結果を見ると、fileSizeとして、現在のファイルサイズが渡されていることも確認できる。
このオンライン・ムックPlus「SNMPによるネットワークモニタリング“第2版”」では、全8回に渡って、SNMPを使ったサーバ監視について説明してきた。
結局のところ、全体を通して読んでみればSNMPを活用する上でポイントとなるのは、OIDだということが分かったと思う。OIDさえ理解すれば、その統計をとったりトラップを受け取ったりすることは、さほど難しくない。
実際のところ、本気でSNMPでのサーバ管理をするとなれば、監視対象が多岐に渡るため、最初の設定が少し面倒なのは否めない。しかし、いちど設定しておけば、日々、監視しなくて良いので、のちのサーバ管理業務が劇的に軽減するのも間違いないわけだ。
Copyright© 2012 ITmedia, Inc. All Rights Reserved.