ネットワーク監視

ホストの CPU が正常でも通信は落ちている - ネットワーク監視が埋める死角

障害調査でよくある行き詰まりは、アプリのエラー率が上がっているのに、どのホストの CPU もメモリもディスクも平常値というものです。原因が「ホストの中」ではなく「ホスト同士の間」にあるとき、インフラ監視の標準メトリクスは何も異常を示しません。Datadog のネットワーク監視はこの死角を埋める機能群で、大きく 2 本の柱に分かれます。1 本目は Cloud Network Monitoring (CNM) で、Agent を入れたホスト上の接続情報を IP / ポート / プロセスの単位で集め、サービスやコンテナ、アベイラビリティゾーンといった任意のタグ単位の依存関係に集約して見せます。2 本目は Network Device Monitoring (NDM) で、Agent が動かないルーター / スイッチ / ファイアウォールを SNMP などの機器向けプロトコルで監視します (2026 年 9 月時点・出典: Cloud Network Monitoring、Network Device Monitoring)。公式ドキュメントが CNM の用途として挙げるのは、想定外の (または遅い) サービス依存の発見、リージョン間やマルチクラウド間の高コストな通信の最適化、クラウド事業者のリージョン障害や外部サービス障害の特定、クライアント側とサーバー側の DNS 問題の切り分けの 4 点です。どれも「アプリのログには出ず、ホストのグラフにも出ない」種類の故障で、これが無いと調査は当て推量の再起動に流れがちです。

CNM が見るのはサービス間のフロー、DNS、経路の 3 つ

CNM の守備範囲は 3 層で捉えると整理しやすくなります。第 1 層はフロー (接続) で、どのクライアントがどのサーバーへどれだけ送受信し、TCP のリトランスミットや遅延、ジッターがどう推移しているかをタグで絞って追えます。収集は Linux では eBPF、Windows ではネットワークカーネルドライバーが担い、Agent v6.14 以上で system-probe.yaml の network_config を有効にすると始まります (2026 年 9 月時点・出典: CNM Setup)。第 2 層は DNS で、Agent 7.33 以上と CNM の有効化を前提に、どの Pod やサービスがどの DNS サーバーへ問い合わせているか、応答時間の急上昇やエラー種別ごとの発生率を見られます (出典: DNS Monitoring)。

第 3 層は経路で、Network Path がホスト上で traceroute を実行して送信元から宛先までのホップごとの遅延を描きます。監視対象は Agent 設定に書く固定の送信元と宛先の組 (スケジュールテスト) と、CNM が観測した実トラフィックから自動生成する組 (ダイナミックテスト) の両方が選べ、問題が自社内か ISP 側かを見分ける材料になります (出典: Network Path)。

NDM は SNMP でルーターやスイッチの中身を見る

Agent をインストールできない機器の監視を担うのが NDM です。対象はオンプレミスと仮想環境のルーター / スイッチ / ファイアウォールで、ネットワーク上の機器を自動検出し、帯域使用率や送信バイト量、機器やインターフェースの生死を SNMP で集めます。機器ごとの取り方はプロファイルという定義ファイルで決まり、ベンダー別のプロファイルが用意されている機器はダッシュボードまで揃った状態で始められ、一覧に無い機器でも汎用プロファイルが TCP / UDP / IP とインターフェースの基本メトリクスを拾います (2026 年 9 月時点・出典: NDM Supported Devices)。集め方は SNMP のポーリングだけではありません。機器側から Agent へ送る SNMP トラップ (出典: SNMP Traps)、そして NetFlow / jFlow / sFlow / IPFIX のフロー情報を受け取る NetFlow Monitoring があり、後者は Agent 7.45 以上で flow_type に netflow5 / netflow9 / ipfix / sflow5 を指定して受信ポートを開けます (出典: NetFlow Monitoring)。フローが取れると「どの機器のどのインターフェースが帯域を食っているか」「通信の上位はどこか」が機器単位で見え、CNM が見るホスト間の流れと、機器が見る経路上の流れを同じ Datadog の画面で突き合わせられます。オンプレのコアスイッチとクラウド上のサービスが同じタグ体系で並ぶことが、混在環境で NDM を選ぶ実利です。

ネットワークマップはホストマップと何が違うか

CNM の画面で最初に開くことになるのがネットワークマップです。ホストマップが「1 台 1 台の状態」を六角形の色で並べる画面であるのに対し、ネットワークマップは「誰と誰がどれだけ話しているか」を矢印つきの図で描く、方向のある地図です。ノードに使うタグ (service や availability-zone など) を先頭のセレクターで選び、辺 (エッジ) に載せるメトリクスを送信スループット / 受信スループット / TCP リトランスミット / TCP 遅延 / TCP ジッター / 確立済み接続数 / 切断接続数の 7 種から選びます。ノードが多すぎるときは 2 つ目のタグで自動的にまとめられ、環境や namespace で絞り込み、指定したパーセンタイル範囲の外側のトラフィックを隠す操作もできます。Agent で CNM を有効にしていれば追加の設定は不要で、集まったデータから自動で描かれます (2026 年 9 月時点・出典: Network Map)。読み方のコツは、平常時の形を一度覚えておくことです。障害時に「本来無いはずの太い矢印」や「リトランスミットで赤くなった辺」を探す作業は、平常時との差分探しに他なりません。タグの設計が揃っていないと、ノードが「unknown」や IP アドレスの羅列になって地図の意味が薄れるため、CNM を入れる前に service タグと env タグを全ホストで揃えておく順序が効きます。

課金はホスト単位 (CNM) と機器単位 (NDM) に分かれる

ネットワーク監視の費用は、対象が「Agent を入れたホスト」か「SNMP で見る機器」かで数え方が変わります。CNM は 1 ホストあたり月額のホスト単位の SKU で、年契約とオンデマンドで単価が異なります (2026 年 8 月時点の SKU 区分・出典: Datadog Pricing)。インフラ監視のホスト課金に上乗せされる形なので、CNM を足したホストは「インフラ監視のホスト単価 + CNM のホスト単価」が月の基本料金になる、と見積もります。一方 NDM は機器単位 (per device) の別 SKU で、ルーターやスイッチ 1 台ごとに数え、ホスト課金には含まれません。Network Path についても、Synthetic Monitoring 側から実行するテストはテスト回数単位の別 SKU が用意されています。具体的な単価はいずれも Datadog 公式の料金ページで確認してください。

見積もりの実務では「CNM は全ホストに入れない」が第一の守りです。ホストの中で起きる故障はインフラ監視で足りるので、CNM は通信の要所、たとえば API ゲートウェイ、DB の前段、リージョン間通信を担うホストに絞って始め、効果が見えた範囲だけ広げます。料金体系全体の読み方は料金の読み解きで扱っています。

切り分けはアプリ、ホスト、ネットワークの順に疑う

ネットワーク監視を入れると、何でもネットワークのせいにしたくなる時期が来ます。しかし実務の切り分けの順序は、アプリ (APM のトレースでどのサービスのどの処理が遅いか)、ホスト (インフラ監視で CPU や I/O が飽和していないか)、ネットワーク (CNM でその区間のリトランスミットや DNS が乱れていないか) の順が効率的です。理由は単純で、発生頻度と修正の速さが違います。アプリのバグやホストのリソース不足は自分たちで直せる一方、ネットワーク側の問題は経路や機器、ときには ISP の手に渡るため、確証が無いまま「ネットワークが怪しい」と言うと調査が止まります。CNM の価値はこの順序の最後で「ネットワークではない」と数字で否定できることにもあり、否定できれば残る容疑者はアプリかホストに絞られます。オンプレのデータセンターとクラウドが専用線や VPN でつながる混在環境を例に取ります。ここでは「クラウド側は CNM でホスト間を、オンプレ側は NDM でスイッチや境界ファイアウォールを、その間の経路は Network Path で」と担当を分けると、どの区間で遅延が乗ったかを 1 つの画面で追えます。

有効化の前に確かめる 5 項目

CNM も NDM も、有効にしてから困る点はおおむね決まっています。対応環境、権限、タグ、機器側設定、課金範囲の 5 項目を先に埋めておくと、後戻りがほぼ無くなります。

これらが埋まっていれば、有効化そのものは system-probe.yaml の 1 行で済みます。

network_config:
  enabled: true

設定後は Agent の status 出力で system-probe が動いているかを見てから、ネットワークマップに自分のホストが現れるまで数分待つ、という順序で確認します。異常を通知に変える段階では、リトランスミット率や DNS エラー率を モニターで見張るのが定番で、公式ドキュメントにも CNM 専用のモニター種別の解説があります (2026 年 9 月時点・出典: Cloud Networking Monitor)。