アクティブ/パッシブ計測とネットワークテレメトリ

計測は「能動」と「受動」の二系統に分かれる

ネットワークの観測手法は、計測者が トラフィックを自分で作り出すかどうか で大きく二分されます。

• アクティブ計測（能動計測）: 既知の特性を持つ プローブパケット を意図的に注入し、その応答や挙動から経路・遅延・損失を推定する。pingやtracerouteが代表例。
• パッシブ計測（受動計測）: 既に流れている 実トラフィック を観測し、サンプリングや集約で統計を取る。sFlowやIPFIXが代表例。

この区別は本質的です。アクティブ計測は「測りたいときに、測りたい経路を、測りたい粒度で」測れますが、注入したプローブは本物の利用者トラフィックではないため、実際のユーザー体験とずれる ことがあります。一方パッシブ計測は実トラフィックそのものを見るので体験に忠実ですが、トラフィックが流れていない経路は観測できず、サンプリング由来の誤差も持ちます。両者は代替ではなく相補です。

アクティブ計測の原理：プローブの応答を読む

アクティブ計測の核は「既知の刺激を与え、応答の差分から内部状態を逆算する」ことです。pingは Echo Request を送り Echo Reply の往復時間を RTT とし、tracerouteは TTL を1ずつ増やして各ホップの Time Exceeded を誘発し経路を描きます。これらが ICMP に依存する仕組みは ICMP の役割 に詳しく、ここで重要なのは 応答のばらつき の読み方です。

• 平均 RTT より 損失率とジッタ（RTT分散） のほうが診断価値が高い。平均が良好でも数%の損失があれば上位TCPは再送で大きく速度を落とす。
• 中間ホップの RTT は経路品質の直接指標にならない。ルータが ICMP 応答を低優先で処理するため、転送そのものより遅く見えるからである。

より体系化したのが TWAMP（Two-Way Active Measurement Protocol） などの標準計測で、送信・受信側で時刻印を付与し、片方向遅延・損失・遅延変動を継続的に測ります。SLA 監視やバックボーンの常時計測に使われ、「いつ・どこで・どれだけ劣化したか」を数値で残せるのが利点です。アクティブ計測の限界は、プローブ自体が帯域とCPUを消費する点と、ECMP環境では フローハッシュ によって本物のトラフィックとプローブが別経路に振り分けられ、測った経路が実際に使われている経路と一致しない ことがある点です。

パッシブ計測：sFlow と IPFIX/NetFlow

パッシブ計測は実トラフィックを観測しますが、すべてのパケットを記録するのは非現実的です。そこで2つの異なる縮約戦略が生まれました。

sFlow は パケットサンプリング を採る方式です。スイッチが「N個に1個」の割合でパケットをランダムに抜き取り、その先頭部分（ヘッダ）とインタフェースのカウンタを sFlowデータグラム としてコレクターに送ります。サンプリングなので個々のフローを正確に追うことはできませんが、統計的に全体像を高速に把握 でき、ハードウェア実装が軽いのが強みです。サンプリング率 N を 1/1000 などに設定し、観測値を N 倍してトラフィック総量を推定します。

IPFIX（IP Flow Information Export、RFC 7011） とその前身 NetFlow は フロー集約 を採ります。{送信元IP, 宛先IP, プロトコル, 送信元ポート, 宛先ポート} のような キー（5-tuple） が同じパケット群を1つの「フロー」とみなし、パケット数・バイト数・開始/終了時刻・TCPフラグなどをルータ内の フローキャッシュ に積み上げます。フローが終了（FIN/RSTやタイムアウト）すると、その集約レコードをコレクターへエクスポートします。個別パケットは捨て、会計・監査に使える正確なフロー単位の台帳 が残るのが特徴です。

パッシブ計測は実トラフィックに密着できる一方、ヘッダしか見えないため暗号化された本文は観測できず、パケットキャプチャ のように全バイトを保存する手法とは精度と保存コストのトレードオフが異なります。フルキャプチャは詳細だが保存が重く、フロー/サンプルは軽量だが粒度が粗い、という住み分けです。

インバンドネットワークテレメトリ（INT）：パケット自身が記録を運ぶ

アクティブ計測は「別物のプローブ」を、パッシブ計測は「事後の集約」を見ます。どちらも 個々の実パケットが各ホップで何を経験したか までは分かりません。ここを埋めるのが インバンドネットワークテレメトリ（INT） です。

INTの発想は単純かつ強力です。転送中のパケット自身に、通過した各スイッチがメタデータを追記していく。受信側（またはINTシンクのスイッチ）でそれを抜き出せば、そのパケットが辿った経路と各ホップでの状態が、実トラフィックそのものから 得られます。書き込まれる代表的なメタデータは次の通りです。

• スイッチID / 入出力ポート: 実際に通った経路（どのデバイスのどのポートか）
• 入口・出口タイムスタンプ: そのスイッチ内での 滞留時間（hop latency）
• キュー占有量（queue occupancy）: 通過時のキュー長。輻輳の発生源をホップ単位で特定できる
• 出力リンク利用率: そのリンクの混雑度

これにより「この経路のこのパケットは、3番目のスイッチのキューで遅延が積み上がった」というレベルの解像度が得られます。事後のフロー集計やプローブ推定では到達できない、パケット粒度・ホップ粒度の可視化です。実装はP4などの プログラマブルデータプレーン を前提とし、スイッチASICがラインレートでメタデータを挿入します。

INTには方式の幅があります。INT-MD（eMbed Data） はパケット本体に命令とメタデータの両方を積むため経路情報が最も豊富ですが、ホップごとにパケットが膨らみ MTU を圧迫する懸念があります。INT-MX（eMbed instructions） は命令ヘッダだけをパケットに積み、各スイッチはその指示に従ってメタデータを直接コレクターへ送るため、パケットはホップを越えても肥大しません。INT-XD（eXport Data、いわゆる postcard 型） は命令すらパケットに積まず、各スイッチが事前設定に基づきメタデータを直接コレクターへエクスポートします。IETF の IOAM（In-situ OAM） も同様の考え方を標準化しており（本体に積む方式と、DEX のようにレポートを直送する方式の双方を持つ）、用途やデータプレーン能力に応じて方式を選びます。

三者をどう使い分けるか

実務では単一の手法に頼らず、目的に応じて重ねます。

データセンタファブリックのような Clos/fat-tree 型の多経路環境では、ECMP のどの経路で輻輳が起きているかが集約統計だけでは分かりにくく、INTのホップ単位可視化が威力を発揮します。逆に、課金や法的監査にはフロー単位で正確な IPFIX が、SLA の常時監視には継続的なアクティブ計測が向きます。

つまずきポイント

• アクティブの結果を過信しない: プローブはECMPで実トラフィックと別経路に振られることがある。測った経路＝使われている経路とは限らない。
• sFlowとNetFlowを混同しない: sFlowはパケットサンプリング、NetFlow/IPFIXはフロー集約。精度と用途が根本的に違う。
• サンプリング率の意味を取り違えない: sFlowの値は率Nで拡大した推定値。小さなフローは取りこぼしうると理解して使う。
• INTヘッダの剥がし忘れに注意: シンクで除去しないとMTU超過・情報漏洩・外部機器での破棄を招く。
• テレメトリ自体が負荷になる: パケット粒度のレポートを無制限に送ると、観測機構がボトルネックになる。集約・サンプリングと併用する。

計測は「壊れてから慌てて測る」ものではなく、平時から数値を蓄積しておく 常時の制御チャネル です。アクティブ・パッシブ・INTの三者を、それぞれの盲点を埋め合うように組み合わせれば、障害の「どこで・なぜ」を推測でなく事実で押さえられます。