# ネットワーク監視 ## 定義 ネットワーク監視(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) - **監視データソース統合の下流に、ワークフロー自動化による一次対応がある**: 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) ## 未解決の問い - **インバンド 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 統合の余地は大きい。 - **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 と同様に、スケールアップ時の処理能力が実用化の分水嶺になりうる。 ## 関連 - 概念: [[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)、INTFusion(IFIP Networking 2026)、[[oyakata]](Apache Airflow ベースのアラート対応自動化基盤) - 関連エンティティ: [[Apache Airflow]] / [[oyakata]] / [[NetBox]] - ソース: [[@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によるアラート対応基盤]] ## 出典 - [[@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 のアラート対応自動化)