ピーク時間帯のあと、ユーザから「あの 20 秒だけつながりにくかった」という申告が届く。手元の監視画面を開くと、interface counter のグラフは 1分間隔の点をまっすぐ結んだまま、問題の時刻をまたいで横ばいに見える。申告は確かに来ているのに、グラフからは何も読み取れない。

直前の点も、直後の点も、画面の上ではいつも通りだった。リンク状態の履歴を見ても、監視画面の線だけを追う限り、そこには短い揺らぎの跡がない。現場でつらいのは、ユーザの体感を疑いたいわけではないのに、自分の画面には説明に使える点が残っていないことだ。

SNMP のグラフは「その間ずっと安定していた証拠」ではなく、聞き取りの瞬間に取れた値を結んだ画面だ。

グラフの点は、聞き取りの瞬間だけを残している

SNMP の監視では、監視サーバが装置側の MIB に並んだ値を polling で取りに行く。SNMP の規格（RFC 1157）でも、ネットワーク状態の監視は監視センター側からの polling を基本に置いている。装置は、聞かれた時点の interface counter や状態値を返し、その返ってきた値が監視サーバのデータベースに点として残る。

Cisco のドキュメントでは、SNMP poll の間隔は 5〜30 分が一般的とされている。現場でそれより短くしている画面でも、構造は変わらない。画面に並ぶのは、監視サーバが聞き取りに成功した時刻の値であり、点と点の間に起きた細かい変化そのものではない。

だから、横ばいの線を見たときに言えるのは、「その聞き取り時点では前後の値が大きく変わっていなかった」というところまでだ。その間ずっと何も起きなかった、と画面が保証しているわけではない。保証していない空白が、グラフの点と点の間に残っている。

ポイント: SNMP のグラフは、連続した現実そのものではなく、聞き取りで残った点を画面上で結んだ時系列だと判断する。

平らな線は、合間の 20 秒を保証しない

申告された 20 秒が、ちょうど 2 つの聞き取りの間に入っていたとする。前の聞き取りでは link は up、ユーザの体感では短く途切れ、そのあと戻り、次の聞き取りでも link は up に見える。画面に残った点だけを見ると、前後の状態は同じなので、線は平らに見える。

同じことは、短い interface error の増加や、ピーク時間だけの通信の落ち込みでも起きる。値が次の聞き取りまでに戻ってしまえば、監視画面には「戻った後の値」だけが残る。あとから画面を開いた人は、申告の時刻とグラフの横ばいを並べて、どちらを信じればよいか迷う。

SNMP には trap のような装置側からの単発通知もある。ただ、それは polling の時刻を補助する通知であって、interface counter の細かな動きを時系列として埋め直すものではない。申告された短い区間をあとからたどりたいなら、単発の通知だけでは画面上の筋が足りない。

ポイント: 横ばいの SNMP グラフから断言できるのは聞き取り時点の値であり、聞き取りの合間の 20 秒は別の時系列で確認する余地が残る。

ここで一度立ち止まりたい。polling 間隔をもっと短くすれば、ピーク時の短いゆらぎは全部見えるようになるか。点を細かく増やせば画面は詰まって見えるが、そのたびに装置と監視サーバは値を取りに行き、受け取り、保存する。見たいのは点の密度なのか、それとも変化が起きた瞬間の跡なのかを、同じ interface counter の画面で考えておきたい。

同じ 20 秒が、装置側の時系列には残る

同じ装置を streaming telemetry でも観測していたら、見える画面は変わる。装置側からコレクタへ外向きの接続が流れ、状態の変化や短い周期の連続値が時系列として残る。監視サーバが聞きに行った時刻だけではなく、装置側から届いた値の並びとして、問題の区間を後から開ける。

その画面では、link が down した点と、ふたたび up に戻った点が、同じ 20 秒の中に並ぶ。interface counter の落ち込みも、点と点の間に消えるのではなく、短い筋として残る。装置も事象も同じなのに、片方の画面では何も起きていないように見え、もう片方の時系列では落ち込みと回復が見える。

ここで効いている違いは、値の名前ではない。観測の主体が、監視サーバ側から装置側へ移っていることだ。監視サーバが時刻を決めて値を取りに行くのか、装置側から変化と連続値が届くのか。その向きの違いが、あとで開くコレクタの時系列に残る線を変える。

ポイント: streaming telemetry は、同じ装置の同じ事象を、装置側から届く時系列として残すため、短い揺らぎを後から画面で追いやすい。

監視は観測の主体から読み直す

ピーク時間の申告を受けたとき、最初に開く SNMP のグラフは今でも重要だ。普段の傾向、長い時間の変化、装置全体の状態を広く見るには、聞き取りで積み上がった interface counter の画面が役に立つ。ただし、その画面を「その間ずっと安定していた証拠」として扱うと、短い区間の申告を画面の外へ追い出してしまう。

読み方を少し変える。SNMP のグラフに残っているのは、聞き取りの瞬間に取れた値だ。その合間の挙動を見たいときは、装置側から届く時系列を並べる。同じ時刻、同じ装置、同じ interface をそろえて、平らな線の裏に短い落ち込みが残っていないかをコレクタの画面で見る。

観測の粒度は、あとから気合いで細かくなるものではない。どちら側が観測を動かしているかで、画面に残る点と線が変わる。次にピーク時間の短い苦情を受け取ったら、まず自分のグラフを「聞き取りの瞬間の値」として読み直し、必要なら装置側から届く時系列を同じ時刻に重ねる。そこで初めて、申告と画面が同じ 20 秒を指す。

ポイント: 監視方式を選ぶ判断は、どの値を集めるかだけでなく、どちら側を観測の主体にして、どの粒度の時系列を画面に残したいかで決まる。