# ネットワーク監視 ## 定義 ネットワーク監視(Network Monitoring)は、データセンターネットワークと wide-area network(WAN)の状態を継続的に観測し、障害の検知・診断・緩和を支援するための一連のツール・データソース・分析処理の総称。代表的なデータソースとして Ping、Traceroute、Out-of-band monitor、Traffic statistics(sFlow/Netflow)、Internet telemetry、Syslog、SNMP/GRPC、In-band network telemetry(INT)、PTP、Route monitoring、Modification events、Patrol inspection 等が用いられる([[@2025__SIGCOMM__SkyNet - Analyzing Alert Flooding from Severe Network Failures in Large Cloud Infrastructures|SkyNet]] Table 2)。 単一データソースの failure detection coverage は限定的(SkyNet Figure 3 で 3%-84%)であり、包括的カバレッジを得るには複数ソースの統合が必須。 ## 横断的知見 - **ネットワーク監視の観測点は、経路・NodeからPodインターフェイスへ近づけることでテナント帰属を回復できる**: 上流ルーターはNAT後のインターネットアクセス量を測れるが、通信元Podを識別できない。[[@2024__Preferred Networks__eBPFを用いてPod ごとのインターネットトラフィック量を計測するツールの開発]]は、Chained CNI PluginからPodのTCへeBPFをアタッチし、Pod・Service・クラスタ外の方向別バイト数を集計する。これはPingmesh/Harpのようなネットワークパス監視やSkyNetの多ソース統合を補完する、ホスト・コンテナ境界の帰属計測である。(Source: [[@2024__Preferred Networks__eBPFを用いてPod ごとのインターネットトラフィック量を計測するツールの開発]], [[@2015__SIGCOMM__Pingmesh - A Large-Scale System for Data Center Network Latency Measurement and Analysis]], [[@2026__NSDI__Harp - Improving VPC Network Availability via Efficient Failure Detection and Rerouting in Tencent Cloud]]) - **インバンド監視はアウトオブバンドプローブよりパスカバレッジが高い**: 従来の Pingmesh 系はスタンドアロンパケットで均等に全ネットワークをプローブするが、パスカバレッジは VM トラフィックパスに依存しない。Harp([[@2026__NSDI__Harp - Improving VPC Network Availability via Efficient Failure Detection and Rerouting in Tencent Cloud]])は VM パケットに 28 バイトのプローブを埋め込むことで「実際にトラフィックが流れているパスのみ」を高密度に監視し、スタンドアロンパケットによる帯域消費を排除する。大規模環境(80K+ サーバ)でも CPU < 1.2%・メモリ < 13.5 MB。ただしトラフィックのないパスは未監視になる設計上の制約がある。(Source: [[@2026__NSDI__Harp - Improving VPC Network Availability via Efficient Failure Detection and Rerouting in Tencent Cloud]] §4.3, §7) - **「単一データソース」の coverage 限界は研究 / 本番双方で再現**: [[@2025__SIGCOMM__SkyNet - Analyzing Alert Flooding from Severe Network Failures in Large Cloud Infrastructures|SkyNet(Yang+ 2025)]] は Pingmesh[15]、NetNORAD[3]、RD-Probe[10]、deTector[34]、007[7]、NetBouncer[42] 等の既存研究を Table 1 で整理し、いずれも「単一データソース依存で coverage 限定」と評価。実際 Figure 3 では 12 個の監視ツールが個別に 3-84% の coverage に留まる。Alibaba Cloud の Internet entry cable 障害事例(§2.2)では Syslog/Ping/SNMP/Out-of-band の各単独では root cause を逃し、複数組み合わせが必須となった。「multi-source integration is necessary」が研究と本番の共通結論。(Source: [[@2025__SIGCOMM__SkyNet - Analyzing Alert Flooding from Severe Network Failures in Large Cloud Infrastructures]] Table 1, Figure 3, §2.1) - **データソース統合の代償が "alert flooding"、その緩和が次の問題に**: 複数ソース統合は coverage を上げる一方、severe failure 時に "10,000 alerts/分" 規模の alert flooding を生む([[@2025__SIGCOMM__SkyNet - Analyzing Alert Flooding from Severe Network Failures in Large Cloud Infrastructures|SkyNet §2.2]])。これは ([[アラートストーム]] と直接接続される問題)、ネットワーク監視研究と AIOps アラート管理研究の交差点。SkyNet は (1) preprocessor で 100K alerts/hour → <10K-50K に削減、(2) hierarchical alert tree で incident に集約、(3) severity score で priority 付け、という 3 段で対応する。(Source: [[@2025__SIGCOMM__SkyNet - Analyzing Alert Flooding from Severe Network Failures in Large Cloud Infrastructures]] §4, §6) - **監視データソース統合の下流に、ワークフロー自動化による一次対応がある**: SkyNet・Harp・INTFusion は「検知・可視化」を扱うが、検知後の**対応(response)**は各論文の射程外である。[[@2026__JANOG58__ネットワーク監視の自動化はどこまでできるのか - Apache Airflowによるアラート対応基盤|LY Corporation の oyakata(JANOG58, 2026)]] は、Alertmanager や syslog 監視ツールからの Webhook 受信を起点に [[Apache Airflow]] のワークフローを自動起動する設計で、「監視 → 検知 → 対応」のパイプラインのうち対応部分を産業実装として補完する。SkyNet が §8 で「LLM への posterior integration」を未来課題とするのに対し、oyakata は既にワークフロー内に LLM Agent を Task として組み込み、関連アラート判定・アラート分類・専門家調査という役割分担で稼働させている点が、監視研究とワークフロー自動化研究の接続点として観察できる。(Source: [[@2026__JANOG58__ネットワーク監視の自動化はどこまでできるのか - Apache Airflowによるアラート対応基盤]] p.31-32, 40) - **監視対象は L3(VPC/経路)からさらに物理層(光デバイス)まで降りる**: 本頁の既存事例(SkyNet・Harp・INTFusion)はL3以上のネットワーク層・パス監視を扱うのに対し、[[光バックボーンネットワークテレメトリ]]([[@2022__NSDI__Detecting Ephemeral Optical Events with OpTel]])は光トランスポンダ・アンプ・光監視チャネルという物理層コンポーネントを対象とする。SNMPのpull型・ベンダー固有コントローラ依存という制約は、既存事例の「単一データソースのcoverage限定」問題と構造的に類似するが、原因は「ソースの数」ではなく「収集プロトコルの逐次実行設計」にある点が異なる。物理層の劣化(Tx/Rx電力の変化)がL3以上の障害の根本原因になりうるため、両層のテレメトリを統合する余地は[[インバンドネットワークテレメトリ]]・[[INTFusion]]が扱うホスト-ネットワーク統合と同型の未解決課題である。(Source: [[@2022__NSDI__Detecting Ephemeral Optical Events with OpTel]]) - **「機械性能レベル」と「抽象ポリシーレベル」という2つの監視水準の区別は、2004年の時点ですでに現在のSLI/SLO的な発想の原型を示していた**: 本ページの各ソースはSNMP・INT・トレースといったデータソースの統合や、アラート洪水の緩和という「検知の精度・速度」を主題とするが、[[@2004__Wiley__Principles of Network and System Administration - Chapter 8 Diagnostics, fault and change management]] §8.10は監視を「機械性能レベル」と「抽象ポリシーレベル」という異なる問いを立てる2つの水準に分け、両者は無関係ではないが同一ではないと述べる。さらに異常検知(anomaly detection)を「障害診断」と「セキュリティ侵入検知」の両方に使える汎用的な発想として位置づけ、cfengineの環境デーモンが長期的な時間スケールで「非決定論的な異常検知」を行い自動化されたポリシー対抗策の起動に使えると紹介する(図8.15)。SNMPベースのMRTG・RRDtool・Cricketが本ページの各データソース(SNMP/GRPC等)の直接の前身にあたる一方、cfengineの環境デーモンが担う「長期の統計的正常性からの逸脱」という監視スタイルは、本ページのSkyNet・Harp等が扱う短期的なfailure detectionとは異なる時間スケールの監視であり、両者の接続は本wikiではまだ扱われていない。(Source: [[@2004__Wiley__Principles of Network and System Administration - Chapter 8 Diagnostics, fault and change management]] §8.10) - **「全サーバ常時参加」という 2015 年の設計選択が、10 年後の "multi-source integration" 論の中で単一データソースとして相対化される**: [[@2025__SIGCOMM__SkyNet - Analyzing Alert Flooding from Severe Network Failures in Large Cloud Infrastructures|SkyNet]] Table 1 は [[@2015__SIGCOMM__Pingmesh - A Large-Scale System for Data Center Network Latency Measurement and Analysis|Pingmesh]] を「単一データソース依存で coverage 限定」なツール群の一つとして整理するが、Pingmesh 自身の論文はこの限界を明確に自覚しており(§6.4「Spine層のどのスイッチかまでは特定できない」)、その限界を TCP traceroute の併用で補うと述べる(§5.2)。これは SkyNet が「複数ソース統合が必須」と結論づける 10 年前の時点で、単一システム内での限定的なソース併用によって同型の課題に対処していたことを示す——multi-source integration という発想自体は SkyNet が発明したのではなく、Pingmesh の時点ですでに部分的に実践されていた設計原則である。(Source: [[@2015__SIGCOMM__Pingmesh - A Large-Scale System for Data Center Network Latency Measurement and Analysis]] §5.2, §6.4、[[@2025__SIGCOMM__SkyNet - Analyzing Alert Flooding from Severe Network Failures in Large Cloud Infrastructures]] Table 1) - **「常時稼働 vs オンデマンド計測」という設計論争は、本頁のインバンド/アウトオブバンド論争の前段にすでに存在した**: Pingmesh 論文 §6.1 は、常時稼働かオンデマンドか、全サーバ参加か一部サーバ選択かという当時の内部論争を明示的に記録し、「いつインシデントが起きるか予測できない」「どのサーバを選ぶべきか自明でない」という2つの理由で常時・全数を選んだと述べる。この論争は、本頁の Harp(インバンド、実トラフィックパスのみ監視)と SkyNet(アウトオブバンド、12 ソース統合)の対比に構造的に先行する——「カバレッジを絞ってオーバーヘッドを削るか、カバレッジを最大化してオーバーヘッドを許容するか」という同じトレードオフが、データソースの選択(Harp/SkyNet)だけでなく計測対象サーバの選択(Pingmesh)という異なる軸でも繰り返し現れている。(Source: [[@2015__SIGCOMM__Pingmesh - A Large-Scale System for Data Center Network Latency Measurement and Analysis]] §6.1) - **本ページが記録してきたSNMPのpull型・カバレッジ限定という問題の技術的な根本原因は、SNMPが「監視専用」に設計されたプロトコルであるという第9章の教科書的な説明で裏付けられる**: [[@2022__NSDI__Detecting Ephemeral Optical Events with OpTel]] はSNMPの「pull型・ベンダー固有コントローラ依存」という制約を光バックボーンテレメトリの文脈で指摘していたが(既存の横断的知見)、なぜSNMPがそのような制約を持つに至ったかの設計的な理由には立ち入っていなかった。[[@2020__SystemsApproach__Computer Networks - A Systems Approach - Chapter 9 Applications]] §9.3.2は、SNMPが`GET`/`SET`/`GET-NEXT`という3操作しか持たず、実際には`GET`(読み取り)が圧倒的に主に使われ、構成の書き込み(`SET`)は歴史的にほぼ手作業のCLIに委ねられてきたと明記する。ASN.1で定義されるMIB変数は、本ページが挙げるSNMPベースの初期ツール(MRTG・RRDtool・Cricket)が前提とする「読み取り専用の統計収集」というスコープをそのまま反映しており、YANG/OpenConfigが監視と構成を対等に扱うモデルベース設計へ転換した(教科書§9.3.2)ことと対比すると、本ページが各所で観測してきたSNMPの限界は「protocolの実装上の制約」ではなく「監視専用という設計時点でのスコープの狭さ」に起因することが分かる。(Source: [[@2020__SystemsApproach__Computer Networks - A Systems Approach - Chapter 9 Applications]] §9.3.2, [[@2022__NSDI__Detecting Ephemeral Optical Events with OpTel]]) - **セキュリティ工学は「監視」の目的を障害検知から侵入検知へ横展開し、本ページが繰り返し扱う"低い誤警報率でも実際には使い物にならない"という問題を、定量的な比率で再確認する**: 本ページのSkyNetは「単一データソースのcoverage限界」という量の問題を扱うが、[[@2020__Wiley__Security Engineering 3e - Chapter 21 Network Attack and Defence]] §21.4.2.3 は侵入検知(IDS)という別目的の監視について、「攻撃が稀」であることそのものが誤警報問題を悪化させると指摘する——100万セッションあたり実際の攻撃が10件(過大推定として)しかない状況では、誤警報率がわずか0.1%でも偽陽性対真陽性比は100倍に達し、この比率は疾病スクリーニング(HIV検査で検査誤り率が有病率を上回る問題)と数学的に同型である。本ページが記録してきた「多要素・ノイズの問題」は障害検知の文脈だったが、侵入検知という別の監視目的でも同じ統計的制約(信号が雑音より小さいと見張りが疲弊し本物の警報を見逃す)が現れることを示す。(Source: [[@2020__Wiley__Security Engineering 3e - Chapter 21 Network Attack and Defence]] ch.21 §21.4.2.3) - **本ページのSIEM/SOAR的な統合ツールへの言及の起源となる、より具体的な描写を第21章が与える**: 第21章 §21.4.2.3 は、大規模組織のネットワーク監視が「複数の監視機構・製品の協調」を要求するようになった結果、SIEM(セキュリティ情報イベント管理)・SOAR(セキュリティオーケストレーションと対応)・メトリクスという統合ツール領域が成長していると述べる。本ページが記録するアラート洪水の緩和(SkyNetの3段パイプライン)やワークフロー自動化(oyakata)は、この「統合・自動化」という同じ潮流の別の実装であり、セキュリティ監視(第21章)とネットワーク信頼性監視(SkyNet・Harp)という異なる目的の監視系が、同じ「統合ツール不足」という課題に収斂していることを示す。(Source: [[@2020__Wiley__Security Engineering 3e - Chapter 21 Network Attack and Defence]] ch.21 §21.4) - **暗号化トラフィックの普及は、本ページのSNMP限界論とは異なる経路で、監視の「見える範囲」を狭める**: 本ページは既にSNMPの「pull型・監視専用スコープ」という設計上の制約を記録しているが、第21章 §21.4.2.3 はこれとは独立に、暗号化(特にDNS-over-httpsのようなアプリケーション層暗号化)の普及がコンテンツ解析・DNSトラフィック分析を不可能にすることで監視の実効性を下げると指摘する。前者はプロトコル設計時のスコープの狭さ、後者は後年のプライバシー強化技術の副作用という異なる原因でありながら、いずれも「監視ツールが見られるデータの範囲が狭まる」という同じ帰結に至る。(Source: [[@2020__Wiley__Security Engineering 3e - Chapter 21 Network Attack and Defence]] ch.21 §21.2.2, §21.4.2.3) - [定義] ntopng はフローコレクタ方式の構造的遅延(フローキャッシュ→エクスポートキャッシュ→コレクタ)を避け、生パケットまたは nProbe が JSON 化したフロー/非フローイベントを ØMQ 経由で直接消費してカウンタを即時更新する設計により実時間性を確保する。単一データソースの検知カバレッジが限定的という [[@2025__SIGCOMM__SkyNet - Analyzing Alert Flooding from Severe Network Failures in Large Cloud Infrastructures|SkyNet]] の知見とは異なり、ntopng は DPI・フロー・システムコール(sProbe/sysdig)の複数データソースを 1 ツールに統合する設計を取る(Source: [[@2014__LISA__Realtime High-Speed Network Traffic Monitoring Using ntopng]], [[@2025__SIGCOMM__SkyNet - Analyzing Alert Flooding from Severe Network Failures in Large Cloud Infrastructures]])。 - [未解決の問い] sFlow/NetFlow のようなサンプリングベースの標準は、10/40 Gbit 級のライン速度に追従できないルータでは不正確な計測に陥る。ntopng は PF_RING DNA によるゼロコピーキャプチャとコモディティサーバでこの問題を回避するが、これは特定ツール側の対策であり、フロー標準自体のサンプリング精度問題は未解決のまま残る(Source: [[@2014__LISA__Realtime High-Speed Network Traffic Monitoring Using ntopng]])。 ## 未解決の問い - Pod単位のeBPFバイト計測を、Pingmesh/Harpの経路・遅延計測やINTFusionのネットワーク層テレメトリと統合したとき、帯域占有の原因Podから障害経路まで一貫して追跡できるか。 - **cfengineの環境デーモン(長期の統計的異常検知)と、SkyNet等の短期的なfailure detection(アラート洪水を伴う)は、監視パイプラインの中でどう役割分担すべきか**: 前者は日次・週次の周期からの逸脱を検知する予防的な監視、後者は障害発生時の即時検知であり、時間スケールが根本的に異なる。本wikiにはこの2つの監視スタイルを統合的に扱う文献がまだない。 - **インバンド vs アウトオブバンドの最適組み合わせ**: Harp のインバンド監視はトラフィックが流れているパスのみカバーし、休眠パスは未監視。SkyNet の 12 ソース統合はカバレッジを上げるが alert flooding を引き起こす。両者を組み合わせてカバレッジとオーバーヘッドを両立する指針はあるか。 - **データソース統合のスケーラビリティ**: SkyNet の preprocessor は 12 ソースを統合するが、user-side telemetry や SRTE label-based testing など 新ソース追加時にどう拡張するか。SkyNet §5.2 は extensibility を強調するが定量評価はない。 - **multi-cloud / hybrid network への適用**: 単一 cloud(Alibaba Cloud)の SkyNet 設計が、AWS Direct Connect + Azure ExpressRoute + on-premises 等の hybrid 環境にどう拡張されるか。 - **LLM × ネットワーク監視の統合点**: SkyNet が §2.3 で LLM 不採用を選んだ後、§8 では「SkyNet 出力を LLM に渡す posterior integration」を未来課題と位置づける。具体設計(LLM プロンプトテンプレート、SkyNet 出力フォーマット、結果の検証フロー)は未公開。 - **障害検知(本ページの主軸)と侵入検知(第21章)は同じ「稀な信号を雑音から拾う」問題を抱えるが、両者の監視パイプラインを統一的に扱う研究はまだない**: SkyNet はネットワーク障害の検知、第21章の IDS はセキュリティ侵害の検知という異なる目的を持つが、いずれも「低い誤警報率でも実用に耐えない」という同型の統計的制約に直面する。障害検知とセキュリティ検知のデータソース・アラート集約基盤を統合できれば、両者の coverage・誤警報問題を同時に緩和できる可能性があるが、本wikiにはまだこの統合を扱う文献がない。 - **eBPF ベース監視と従来 SNMP/Syslog の競合**: モダンな network observability では eBPF/XDP が低オーバーヘッドで深い計装を可能にする。SkyNet の 12 ソースに eBPF 由来のデータが含まれず、過去 8 年で incremental に追加された統合だけが報告されている。eBPF 統合の余地は大きい。 - **INT + eBPF のクロスレイヤー融合後の Centralizer スケーラビリティ**: INTFusion([[@2026__IFIP Networking__INTFusion - Unifying Network and Host Telemetry in Data Center Networks]])はネットワーク層(INT)とホスト層(eBPF)を per-flow で融合する Centralizer を Elasticsearch で実装した。しかし評価は 2 ホスト環境にとどまり、数千ホスト規模での融合処理の性能は未検証。SkyNet が 12 ソース統合時に直面した alert flooding と同様に、スケールアップ時の処理能力が実用化の分水嶺になりうる。 - ネットワーク監視ツールにおける DPI・フロー統計・システムコールベースの相関付けを 1 ツールへ統合する設計(ntopng の sProbe/sysdig 統合等)は、専用の分散トレーシング/eBPF 系ツールと比較してどこまで拡張可能か。 ## 関連 - 概念: [[VPCネットワーク可用性]]、[[グレイ障害]]、[[インバンドネットワークテレメトリ]]、[[光バックボーンネットワークテレメトリ]]、[[Pod単位ネットワークトラフィック計測]]、[[サービス妨害攻撃とネットワークプロトコルの悪用]](侵入検知の対象となる攻撃) - 親概念: [[オブザーバビリティ]]、[[ネットワーク障害診断]] - 兄弟概念: [[RDMAネットワーク監視]](AI training 特化)、[[テレメトリ]]、[[トレースサンプリング]] - 関連手法: SkyNet(SIGCOMM 2025、12 ソース統合)、[[Pingmesh]](SIGCOMM 2015、全サーバ常時参加型)、NetNORAD(Facebook)、NetBouncer(NSDI 2019)、007(NSDI 2018)、Gandalf(NSDI 2020)、Aegis(NSDI 2025)、INTFusion(IFIP Networking 2026)、[[oyakata]](Apache Airflow ベースのアラート対応自動化基盤) - 関連エンティティ: [[Apache Airflow]] / [[oyakata]] / [[NetBox]] / [[Pingmesh]] - 子概念: [[サイレントパケットドロップ検知]](Pingmesh・R-Pingmesh が扱うスイッチ/RNICのサイレント障害検知手法) - ソース: [[@2025__SIGCOMM__SkyNet - Analyzing Alert Flooding from Severe Network Failures in Large Cloud Infrastructures]]、[[@2026__IFIP Networking__INTFusion - Unifying Network and Host Telemetry in Data Center Networks]]、[[@2026__JANOG58__ネットワーク監視の自動化はどこまでできるのか - Apache Airflowによるアラート対応基盤]]、[[@2004__Wiley__Principles of Network and System Administration - Chapter 8 Diagnostics, fault and change management]]、[[@2015__SIGCOMM__Pingmesh - A Large-Scale System for Data Center Network Latency Measurement and Analysis]]、[[@2024__Preferred Networks__eBPFを用いてPod ごとのインターネットトラフィック量を計測するツールの開発]]、[[@2020__SystemsApproach__Computer Networks - A Systems Approach - Chapter 9 Applications]](SNMPの設計スコープに関する教科書的な説明)、[[@2020__Wiley__Security Engineering 3e - Chapter 21 Network Attack and Defence]](侵入検知の誤警報問題・SIEM/SOAR) / [[@2014__LISA__Realtime High-Speed Network Traffic Monitoring Using ntopng]] ## 出典 - [[@2025__SIGCOMM__SkyNet - Analyzing Alert Flooding from Severe Network Failures in Large Cloud Infrastructures]] §2.1(既存ツールの limitation)、§4.1(12 ソース統合 preprocessor)、§6.1(coverage 評価) - [[@2026__NSDI__Harp - Improving VPC Network Availability via Efficient Failure Detection and Rerouting in Tencent Cloud]] §4.3(インバンド検知設計)、§7(本番オーバーヘッド評価) - [[@2026__IFIP Networking__INTFusion - Unifying Network and Host Telemetry in Data Center Networks]](§III 二層エクスポートモデルと Centralizer 融合設計) - [[@2026__JANOG58__ネットワーク監視の自動化はどこまでできるのか - Apache Airflowによるアラート対応基盤]] p.31-32, 40(oyakata のアラート対応自動化) - [[@2015__SIGCOMM__Pingmesh - A Large-Scale System for Data Center Network Latency Measurement and Analysis]] §5.2, §6.1, §6.4(常時稼働・全サーバ参加の設計論争、サイレント障害検知の限界) - Mark Burgess, *Principles of Network and System Administration*, 2nd ed., Wiley, 2004, Chapter 8 §8.10. - Larry Peterson and Bruce Davie, *Computer Networks: A Systems Approach*, 6th edition, Chapter 9: Applications, §9.3.2 Network Management (SNMP, OpenConfig). https://book.systemsapproach.org/applications.html - Ross Anderson, *Security Engineering: A Guide to Building Dependable Distributed Systems*, 3rd Edition, John Wiley & Sons, 2020, Chapter 21, §21.2.2, §21.4, §21.4.2.3.