# Scaling Telemetry Workloads ## 定義 テレメトリワークロードのスケーリング(Scaling Telemetry Workloads)は、クラウドアプリケーションの規模拡大に伴い増大するテレメトリ処理の負荷を、**計装(instrumentation)・保持(storage)・分析(mining)の 3 層**に分解し、各層で「スケーラビリティと運用複雑性の低減」を両立させる研究枠組みである。[[@2025__Kyoto University__Scaling Telemetry Workloads in Cloud Applications - Techniques for Instrumentation, Storage, and Mining]] が提唱し、テレメトリデータを **time-oriented**(メトリクス・ログ)と **path-oriented**(トレース・コールグラフ)に大別したうえで、path-oriented の計装([[分散トレーシング]]・in-kernel flow bundling)、time-oriented の保持([[時系列データベース]]・[[HeteroTSDB]])、time-oriented の分析([[特徴量削減]]・[[MetricSifter]])の 3 課題を統一的に扱う。中核の設計指針は「**データ削減は文脈知識が最も豊富な両端——計装層(プロセス/ソケット/トランザクションの文脈)と分析層(アラート/障害の文脈)——で行い、保持層は文脈非依存の堅牢な保持に徹する**」(§6.2)である。 ## 横断的知見 - **3 層分解は wiki 内の概念・エンティティ配置と 1 対 1 で対応し、孤立していた研究課題を接続する**: 計装層は[[分散トレーシング]]・[[go-conntracer-bpf]]・[[eBPF]]、保持層は[[時系列データベース]]・[[HeteroTSDB]]・[[Mackerel]]、分析層は[[特徴量削減]]・[[MetricSifter]]・[[変化点検知]]・[[Fault Localization]] に対応する。これらは個別に見ると「ネットワーク可観測性」「TSDB 設計」「障害箇所特定の前処理」として独立した話題だが、3 層枠組みはテレメトリの生産→保持→消費というパイプライン上に位置づけ直し、層間の設計トレードオフ(例: 計装で削減すれば保持コストが下がるが、削減しすぎると分析精度が落ちる)を可視化する。(Source: [[@2025__Kyoto University__Scaling Telemetry Workloads in Cloud Applications - Techniques for Instrumentation, Storage, and Mining]]) - **「文脈豊富な両端で削減」の指針は、AIOps エージェントのテレメトリ過剰消費問題にも延伸する**: 分析層の上流側(障害箇所特定の特徴量削減)は博士論文で実証済みだが、分析層の下流に LLM エージェントが座ると同じ削減圧力がさらに強まる。[[OpenRCA]] は KPI 1263 種を oracle で 53 種(95% 減)に絞らねば LLM が扱えないと示し、[[Cloud-OpsBench]] は事前計算 snapshot + ツール群で供給を最適化する。いずれも「分析層のコンシューマ(LLM)の文脈に合わせて絞る」操作であり、博士論文の指針を LLM 時代に再解釈したものと見なせる。(Source: [[@2025__Kyoto University__Scaling Telemetry Workloads in Cloud Applications - Techniques for Instrumentation, Storage, and Mining]], [[@2025__ICLR__OpenRCA - Can Large Language Models Locate the Root Cause of Software Failures]], [[@2026__arXiv__Cloud-OpsBench - A Reproducible Benchmark for Agentic Root Cause Analysis in Cloud Systems]]) - **計装層のスケーリング手法が GPU/LLM インフラのテレメトリ層へ拡張される**: 博士論文が socket-based トレーシングの 4 系統(snapshot / streaming / aggregating / bundling)を整理した計装層の設計空間は、LLM インフラのテレメトリに拡張されている。[[@2025__eBPF__eInfer - Unlocking Fine-Grained Tracing for Distributed LLM Inference with eBPF]] は推論リクエスト単位の実行タイムラインを eBPF で構築し、[[@2025__SOSP__Mycroft - Tracing Dependencies in Collective Communication Towards Reliable LLM Training]] は集合通信の依存追跡をフロー/チャンク単位で行い、[[@2025__SIGCOMM__Astral - A Datacenter Infrastructure for Large Language Model Training at Scale]] は 4 層(アプリ/トランスポート/ネットワーク/物理)のフルスタック計装で MTTLF を最大 25 倍短縮する。いずれも「細粒度トレースは取りすぎると害」という制約下での計装設計であり、bundling が「同一宛先を束ねて転送量を最小化」したのと同じ削減圧力が GPU 通信トレースでも反復する。(Source: [[@2025__Kyoto University__Scaling Telemetry Workloads in Cloud Applications - Techniques for Instrumentation, Storage, and Mining]], [[@2025__eBPF__eInfer - Unlocking Fine-Grained Tracing for Distributed LLM Inference with eBPF]], [[@2025__SOSP__Mycroft - Tracing Dependencies in Collective Communication Towards Reliable LLM Training]], [[@2025__SIGCOMM__Astral - A Datacenter Infrastructure for Large Language Model Training at Scale]]) - **保持層の「取り込み最適化 vs クエリ最適化」の直交性が後続研究で裏づけられる**: [[HeteroTSDB]] は hash table インデックス + TTL tiering で取り込みスケーラビリティを攻めたが、クエリ側の冗長性には触れなかった。[[PromSketch]]([[@2025__VLDB__Approximation-First Timeseries Monitoring Query At Scale]])は VictoriaMetrics が CPU 時間の 80.2% を Data Scanning に費やすと測定し、中間結果キャッシュでクエリ側を攻める。この直交性は博士論文が保持層を「文脈非依存に徹する」と位置づけたことの帰結でもある——保持層は取り込みもクエリも文脈なしに効率化するしかなく、結果として取り込み vs クエリという 2 軸に分岐する。(Source: [[@2025__Kyoto University__Scaling Telemetry Workloads in Cloud Applications - Techniques for Instrumentation, Storage, and Mining]], [[@2025__VLDB__Approximation-First Timeseries Monitoring Query At Scale]]) - **3 層枠組みの外に「能動計装」という直交する系統がある**: 博士論文は計装層を受動的な収集(ソケットイベントの捕捉)として整理したが、[[R-Pingmesh]]([[@2024__SIGCOMM__R-Pingmesh - A Service-Aware RoCE Network Monitoring and Diagnostic System]])は能動的プロービング(UD QP + CQE タイムスタンプ)で RTT・ドロップを測る。受動収集(イベントが発生してから捕捉)と能動プローブ(計測を仕掛けて応答を得る)はスケーリング特性が異なり——受動はイベント量に比例してコストが増えるが能動はプローブ頻度でコストを制御できる——3 層枠組みの計装層を拡張する軸になりうる。(Source: [[@2025__Kyoto University__Scaling Telemetry Workloads in Cloud Applications - Techniques for Instrumentation, Storage, and Mining]], [[@2024__SIGCOMM__R-Pingmesh - A Service-Aware RoCE Network Monitoring and Diagnostic System]]) - **計装と分析の間に「中間処理層」を挟む設計パターンが SQL ベースで出現**: [[@2024__IEEE CLOUD__Enabling Programmable Metric Flows]] の [[PMF]] は、計装層（Prometheus コレクタ）と保持/分析層（Cortex/アグリゲータ）の間にインメモリ SQLite ベースのミドルボックスを挿入し、DAG として合成された変換操作（周波数・フィルタ・適応・集約）をメトリクスごとに適用する。博士論文が整理した「計装→保持→分析」の 3 層モデルに対し、PMF は**計装と保持の間に「プログラマブルな中間処理」層**を差し込む構成。この層が異常検知のメトリクス重要度をトップダウンで取り込む点は、博士論文が提唱した「文脈豊富な両端で削減」の計装側実装と見なせるが、博士論文の計装層がカーネル/プロセス文脈で削減する（flow bundling）のに対し、PMF はメトリクスラベルとグローバル帯域制約という**アプリケーション層の文脈**で削減する。同じ「計装側の削減」でも文脈の取得元が異なる。(Source: [[@2024__IEEE CLOUD__Enabling Programmable Metric Flows]], [[@2025__Kyoto University__Scaling Telemetry Workloads in Cloud Applications - Techniques for Instrumentation, Storage, and Mining]]) ## 未解決の問い - **collect-first → use-first の閉ループは実現可能か**: 博士論文の future direction(§6.3)は、分析層から計装/保持層へ利用パターンをフィードバックし収集・保持を動的に最適化する閉ループを提唱する。[[PMF]]([[@2024__IEEE CLOUD__Enabling Programmable Metric Flows]])は異常検知のメトリクス重要度を帯域制約下でトップダウン最適化し部分的に実現するが、重みは静的付与であり分析層の変化（異常検知モデルの再学習・新規下流タスクの追加）に自動追従しない。AIOps エージェント([[AIOpsLab]]・[[Bits AI SRE]])を分析層に据えれば、エージェントのテレメトリ消費パターンを計装ポリシーに**動的に**還流する閉ループが技術的に成立するか。 - **LLM 向け failure snapshot の最適生成**: 大量のテレメトリを LLM プロンプトに直接入れられない制約に対し、博士論文は「ノイズを除いた failure snapshot の生成」を将来課題に挙げた。[[MetricSifter]] の変化点密集による特徴量削減と、[[OpenRCA]] の oracle 削減(95% 減)・[[Cloud-OpsBench]] の事前計算 snapshot は同じ方向を異なる粒度で攻めている。統計前処理と LLM の入力整形を一体設計する手法はどうあるべきか。 - **GPU/LLM インフラへの 3 層枠組みの適用**: 博士論文はクラウドのマイクロサービスを対象にしたが、future direction(§6.3)で GPU/TPU クラスタの分散学習テレメトリに言及した。計装層は [[eBPF]] ベースの GPU 可観測性や集合通信トレースで急速に進展するが、保持層(GPU メトリクスの TSDB 設計)と分析層(GPU 障害の特徴量削減)はまだ体系化されていない。3 層枠組みは LLM インフラにそのまま移植できるか、それとも新たな層（例: 通信ミドルウェア層）の追加が要るか。 - **受動 vs 能動計装のスケーリング特性の統合**: 受動収集（イベント量比例）と能動プローブ（頻度制御可）はスケーリングの支配因子が異なる。両者を同じ 3 層枠組みの計装層に包摂するには、スケーリング特性をどう統一的に表現すべきか。 ## 関連 - ソース: [[@2025__Kyoto University__Scaling Telemetry Workloads in Cloud Applications - Techniques for Instrumentation, Storage, and Mining]] / [[@2024__IEEE Access__MetricSifter - Feature Reduction of Multivariate Time Series Data for Efficient Fault Localization in Cloud Applications]] / [[@2025__ICLR__OpenRCA - Can Large Language Models Locate the Root Cause of Software Failures]] / [[@2026__arXiv__Cloud-OpsBench - A Reproducible Benchmark for Agentic Root Cause Analysis in Cloud Systems]] / [[@2025__VLDB__Approximation-First Timeseries Monitoring Query At Scale]] / [[@2025__eBPF__eInfer - Unlocking Fine-Grained Tracing for Distributed LLM Inference with eBPF]] / [[@2025__SOSP__Mycroft - Tracing Dependencies in Collective Communication Towards Reliable LLM Training]] / [[@2025__SIGCOMM__Astral - A Datacenter Infrastructure for Large Language Model Training at Scale]] / [[@2024__SIGCOMM__R-Pingmesh - A Service-Aware RoCE Network Monitoring and Diagnostic System]] / [[@2024__IEEE CLOUD__Enabling Programmable Metric Flows]] - 概念(3 層の各層): [[分散トレーシング]](計装) / [[時系列データベース]](保持) / [[特徴量削減]](分析) / [[変化点検知]](分析) / [[Fault Localization]](分析) - 概念(隣接): [[テレメトリ]] / [[AIOps]] / [[根本原因分析]] / [[eBPF]] / [[GPU観測性]] / [[近似クエリ処理]] / [[RDMAネットワーク監視]] / [[動的インストルメンテーション]] - エンティティ: [[HeteroTSDB]] / [[go-conntracer-bpf]] / [[MetricSifter]] / [[Mackerel]] / [[Meltria]] / [[Yuuki Tsubouchi]] / [[Kyoto University]] / [[SAKURA Internet]] / [[PMF]] - 関連 MOC: [[SRE - MOC]] / [[異常検知 - MOC]] / [[AI Infra Telemetry - MOC]] ## 出典 - [[@2025__Kyoto University__Scaling Telemetry Workloads in Cloud Applications - Techniques for Instrumentation, Storage, and Mining]](§1.1–1.4 テレメトリ 3 層とワークロードの定義、§3 in-kernel flow bundling、§4 HeteroTSDB、§5 MetricSifter、§6.2 設計指針「両端で削減」、§6.3 future directions: collect-first→use-first・LLM for failure management・telemetry for LLM training infrastructure) - [[@2024__IEEE CLOUD__Enabling Programmable Metric Flows]](§III PMF アーキテクチャ=計装と保持の間の SQL ベース中間処理層、§IV 動的周波数最適化=メトリクス重要度×帯域制約の LP、§V-D WRE 約 600 倍削減)