# ネットワーク監視 ## 定義 ネットワーク監視(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%)であり、包括的カバレッジを得るには複数ソースの統合が必須。 ## 横断的知見 - **インバンド監視はアウトオブバンドプローブよりパスカバレッジが高い**: 従来の 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) ## 未解決の問い - **インバンド 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 出力フォーマット、結果の検証フロー)は未公開。 - **eBPF ベース監視と従来 SNMP/Syslog の競合**: モダンな network observability では eBPF/XDP が低オーバーヘッドで深い計装を可能にする。SkyNet の 12 ソースに eBPF 由来のデータが含まれず、過去 8 年で incremental に追加された統合だけが報告されている。eBPF 統合の余地は大きい。 ## 関連 - 概念: [[VPCネットワーク可用性]]、[[グレイ障害]] - 親概念: [[オブザーバビリティ]]、[[ネットワーク障害診断]] - 兄弟概念: [[RDMAネットワーク監視]](AI training 特化)、[[テレメトリ]]、[[トレースサンプリング]] - 関連手法: SkyNet(SIGCOMM 2025、12 ソース統合)、Pingmesh(SIGCOMM 2015)、NetNORAD(Facebook)、NetBouncer(NSDI 2019)、007(NSDI 2018)、Gandalf(NSDI 2020)、Aegis(NSDI 2025) - ソース: [[@2025__SIGCOMM__SkyNet - Analyzing Alert Flooding from Severe Network Failures in Large Cloud Infrastructures]] ## 出典 - [[@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(本番オーバーヘッド評価)(既存ツールの limitation)、§4.1(12 ソース統合 preprocessor)、§6.1(coverage 評価)