SNMPは使い方に注意

ひと昔前に、サーバー監視のソフトウェアの流行りとして、SNMPを使ったエージェントレス監視が流行った時期があります。

「エージェントレスなので、ソフトを個別のサーバーに入れない分安くなりますよ」

みたいな流れでの導入が多かった記憶があります。
まあ、この時SNMPの仕様の落とし穴にハマったので、回顧と備忘を記事にしておこうと思います。

0.結論(というか持論)

いきなりですが、

「精度を求めるならSNMPを使うな」

という点です。
以下詳しく書いていきます。

1.SNMPの仕様

これは是非RFCを一度サラッと見ていただきたいです。
今回の記事で見ていただきたいのは、GetRequest、GetNextRequestの項目です。

   4.1.2 The GetRequest-PDU .................................   20
4.1.3 The GetNextRequest-PDU ............................. 21
(引用 https://datatracker.ietf.org/doc/html/rfc1157)

端的に言うと、GetRequestは指定のoidを取得する時に、GetNextRequestはその直前に取得(GetResponse)したoidの次のoidを取得するときに使われます。

snmpwalkコマンドを実行したことある人であれば、特にイメージしやすいと思いますが、コマンドで指定したoid下にある一連の情報を取得する時、コマンドで指定した最初のoid情報だけGetRequestを、それ以下のoid情報を再帰的に取得するときにGetNextRequestが使われています。

こういった動きから、サーバーの情報を一括して取得するという点では、非常に有用です。

2.実は厄介なGetNextRequest

しかしながら、UDP通信である(=欠落が生じても、タイムアウトしてもそのまま)ということを除いても、SNMPでの情報取得には注意が必要となります。

具体的には、取得対象となるoidの母数が変化する情報を取得した場合、その先頭と末尾とでは情報に食い違いが発生することがあります。

特に顕著なのはプロセスのoidです。

GetNextRequestは、「コールされた時の情報」を取得します。snmpwalkコマンドでいうと、「コマンド実行した瞬間の値ではなく、処理している間のその瞬間、その瞬間の値」を取得します。

これによって何が起こるのかというと、SNMPのoid情報取得中にプロセスの起動・停止が行われると、一覧取得していたはずのプロセスリストに欠落や、情報の食い違いが発生します。
一連の取得処理に時間がかかればかかるほど、この欠落や食い違いが当然のごとく多くなります。

そしてGetNextRequestが「コールされた時の情報」を取得するということは、oidの母数が変わらないものでも、取得した瞬間の違いによる数値のずれが起こることがあります。

具体的には、Linux OSのCPUであれば、「User+System+idle+wait+stealを足しても100%にならない」などの事が起きえます。

また、意外とSNMPの情報取得は、取得対象となるサーバーへ負荷をかけることがあります。
負荷がかかると、処理時間が延び、その結果情報の欠落や食い違いの発生頻度が増える、という負のスパイラルを描くこともあります。

3.理解したうえでSNMPを使う

ということで、SNMPを使うときには、その使い方に注意が必要です。
特に監視(後述の愚痴参照)で使うときには注意が必要です。

SNMPの仕様上、GetNextRequestが使われているプロセス監視の誤検知は、絶対なくせません。できても発生頻度の低減までです。

また、リソース情報の収集として使う場合にも、合計値が実際の値と異なることがあるというのも、このGetNextRequestの仕様上、絶対なくせません

ある程度精度が犠牲になることを理解してSNMPは使うものです。
精度が必要なのであれば、ローカルで情報を取得する製品や、自身でコーディングすることをお勧めします。

4.当時の愚痴とか

私がこの事象にハマっていたのが東日本大震災のすぐ後だったので、ちょうど2011~2012年ごろの事です。

当時エージェントレスのプロセス監視に限って誤検知が頻発、オペレーターからの苦情も多く、顧客から原因説明を求められるが、製品ベンダーからは正常動作であるとの回答しか得られない、板挟みになり暫定的に「連続検知○回したら通知」といった設定をすることで、誤検知の発生頻度を落とすといったことしかできませんでした。(まぁ、これが最終的に恒久対処となるのですが…)

この時RFCを読み込み、大量の製品ログとパケットキャプチャの結果を追いかけ、原因と思わしき事象をベンターに突き付けたのは、糧にはなりましたがもう二度とやりたくない…

そして意外とこういったSNMPを使うときの落とし穴について、書かれた記事がないのが個人的には意外だなぁと感じています。

Googleで”SNMP 監視”とか検索すると、「○○できます」はあるけど、「○○できません」が思いのほか見つからない。
いや、もっと書こうよ、特に製品ベンダーさん…