【OSS技術コラム】

第3回 SNMP監視に関する留意点とは？

3回目となります今回は②SNMP監視に関しての留意点を書きたいと思います。

1.SNNPポーリング監視に関して
2.SNMP Trap に関する問題
3.まとめ

1.SNNPポーリング監視に関して

ZabbixはSNMP監視マネージャとして、監視対象となるネットワーク機器やストレージ機器のSNMPエージェントと通信することにより、様々なSNMP監視を実現します。SNMPはOID（オブジェクトID）というツリー構造の数値（.1.3.6.1.2.1.1.X.Xのような感じ）で管理され１つ１つがユニークなものとしてそれぞれの数値には管理対象としての値と意味を持ちます。

例えば以下のような具合です。

それぞれの機器は製造された開発ベンダーによって管理されます。上記の例を始め機器に特化した電源状態やインターフェイスの使用量などが拡張MIBとして管理され、Zabbixからのポーリング監視に対して、値を返します。

ZabbixからOIDに関する情報を取得する設定については、具体的には以下の項目が挙げられます。

概ね上記を設定すれば監視は開始できます。（型は間違えないように）

インターネット上でも、よく監視対象になる機器のOIDの情報は確認できますし、監視対象となる項目も分かると思います。しかし、おそらく問題になるのはその先です。

例えばネットワークインターフェイス(NIC)など、1ノードに対して複数存在するものにかかわる情報は、それがどの項目にあたるか調べないと正しく監視する事が出来ません。

1台の監視対象でもSNMPオブジェクトは非常に多い為、その中から目的のOIDを探すのはなかなか大変です。

snmpwalkを使用した調査

以下はsnmpwalkコマンドを使った調査の一例です。

今回は、GigabitEthernet1 のインバウンドのトラフィック量を取得してみましょう。

　※小規模なcisco のルータを使用しています。

まずは、ifInOctets を調べてみると4つのNICが存在している事が分かりますが、今回監視したい GigabitEthenet 1がどれか分かりません。

次に ifDescr　で対象項目の説明書きを確認します。

ifDescr.1 が目的のNICで、対象のインデックスは 1番目 と分かりました。

最後に、最終的に取得したい値とそのOIDを確認してみます。

また監視対象オブジェクトのMIBファイル(今回はIF-MIB)を開き、説明を読んでみます。

(MIBファイルはベンダーや機器のWebサイトや担当者から入手してください)

ふむふむ。total number of octets receivedという事はバイトで取得するのか。SyntaxにCounter32(Counterは積算値)とあるので、更新間隔ごとの通信量が欲しい場合は常に差分をとらなければならないのか…といった事が分かります。

このように、ZabbixにおけるSNMP監視の設定を行っていきますが、問題が起きた時の切り分けや参考情報のない時の新規監視項目追加には上記のような手順(場合によりこれ以上)の事前調査が必要になる為、snmpwalkコマンドで調査する事やMIBファイルを読み解くといった前提知識は持ち合わせておくべきと考えます。

2.SNMP Trap に関する問題

Zabbix 単体ではSNMP Trap メッセージを受信する機能を有していないため、

Zabbixサーバが動作するLinuxOS上のNet-SNMPに含まれるsnmptrapd を使ってメッセージを受信し、snmptt をはじめとするその他の仕組みを使ってZabbixで取り扱える形に整形したうえでZabbixに取り込みます。

この設定自体は、関連情報も多くのWebサイト等でも紹介されています。

動作する流れは以下のようになります。

機器ベンダーのMIBの作りによりますが1つの機器に設定されるSNMP Trapの数は数種類から数百種類とマチマチです。 1受信なんだから構築時に全部設定すれば良いだろうと思ってしまいがちですが、基本的に１つのシステムでSNMP監視されるサーバ/ネットワーク機器は何種類か存在します。

例えば、200 種類の項目が用意されている機器が5種類あった場合、それだけで1000項目の精査が必要です。

こうなると設定をする人・運用する人が膨大な数のsnmptt.conf ファイルのエントリ、アイテム/トリガーの山に囲まれる事になります。変更、棚卸しなどの機会の度に、それら監視項目の山の中から目的の項目を探す・変更することは現実的ではありません。

サイレント障害は怖いため通知はすべて受け取りたいところですが、発生頻度が低いもの・イベント内容として特に対応の必要ないものは、運用する者としては明示的に「障害通知」とは受け取りたくないものです。

さらに、SNMP Trap項目を１つ１つ設定する事の労力と使用頻度の少ないOIDを設定し管理しておく事の手間が生じると思います。

プログラムを書いて一括で設定する事もできますが、使用頻度の少ないOIDを管理する手間は同様ですので、労力はあまりかけるべきではないと思います。

Zabbixには特定のもの以外を1つの項目として集約する機能があるため、優先度の低いものはそこに溜めておいて、時間をおいて確認するなどの工夫ができます。

経験値に左右される内容と言えますが、発生頻度の高いSNMP Trap OIDの選出や優先度の低いSNMP Trapを1つの項目に集約するなど、効率的に運用する事を見据えた設定が大事だと考えます。

３．まとめ

今回は前半でSNMPポーリングの話、後半でSNMP Trapの話をしました。

SNMPポーリング監視はZabbixから能動的に監視対象へ監視しにいく動きをします。

SNMP Trap監視はZabbixからすると受動的な監視となり、SNMPエージェントにあたる監視対象機器からのイベント通知を待ち受けます。

共にSNMP の仕様は理解しなくても監視設定することは可能です。しかしながら、運用時に実際に障害通知を受けて、復旧やエスカレーション対応を行う事を考えて、人が見て分かりやすい形、人が行動を起こす現実的な運用を考えた上で監視設定をしなければならないと考えます。

SNMP は、それだけで主機能から独立して知っておくべき分野ですので、こういった事が浮き彫りになりやすいと考え、このような話をしました。

次回でこの監視に関するお話はいよいよ最終回となります。

監視システムとしては管理者との重要な接点にあたる通知に関して私が経験した中での気付きを共有しますので続けてお読みいただければ幸いです。