# テレメトリ ## 定義 テレメトリ(telemetry)は、システム・アプリケーション・サービスから性能や利用状況のデータを自動で収集し、監視・分析のために遠隔地へ送信する取り組み。クラウドアプリケーションの信頼性維持(障害管理・性能最適化・キャパシティ計画・セキュリティ監査)を支える基盤であり、その処理は **計装(instrument を埋め込みデータ生成)→ 保持(データベースで保持)→ 分析(蓄積データから洞察を導出)** の 3 層からなる。([[@2025__Kyoto University__Scaling Telemetry Workloads in Cloud Applications - Techniques for Instrumentation, Storage, and Mining]]) テレメトリデータは大きく **time-oriented**(metrics=数値時系列、logs=イベントのテキスト記録)と **path-oriented**(traces / call graph=コンポーネント間の処理経路)に分かれる。アプリケーションがスケールすると各層のワークロード(計装のオーバーヘッド・取り込み/保持量・分析の計算量)が増大し、スケーラビリティと運用複雑性の低減の両立が課題になる。([[@2025__Kyoto University__Scaling Telemetry Workloads in Cloud Applications - Techniques for Instrumentation, Storage, and Mining]]) ## 横断的知見 - **Borgmon → Prometheus の系譜が、宣言型ルール評価によるモニタリングの保守コスト劣線形化を実証する**: [[@2016__OReilly__SRE Book - Chapter 10 Practical Alerting from Time-Series Data]] は Google の内部モニタリングシステム Borgmon を題材に、命令型チェックスクリプトから宣言型ルール評価への転換を記述する。ラベルセットによる多次元時系列モデル、代数的アグリゲーション、for 節によるフラッピング防止、Alertmanager による重複排除・抑制という設計は、そのまま Prometheus に受け継がれた。この設計思想は本ページが整理する計装→保持→分析の 3 層のうち分析層の基盤であり、時系列ルール評価の階層的トポロジ（Borgmon が Borgmon を参照する階層構造）はスケーラビリティ設計の原型にあたる。ホワイトボックスモニタリング（内部状態の計装）とブラックボックスモニタリング（外部観測）の区別は、計装設計の段階で観測対象の粒度を決める意思決定として本ページの計装層の議論と接続する。(Source: [[@2016__OReilly__SRE Book - Chapter 10 Practical Alerting from Time-Series Data]]) - **SRE Workbook は監視を「集めること」ではなく SLO に結びついた制御面として扱う**: Monitoring は、メトリクス・ログ・トレースを目的別に使い分け、アドホックなドリルダウン、監視設定のコード化、監視システム自体の容量管理、アラートロジックのテストを実務要件として並べる。Alerting on SLOs は、そのテレメトリをエラーバジェットバーン率へ変換し、ページとチケットを分ける。これによりテレメトリは「診断の素材」だけでなく、オンコール割り込みを制御する上位の運用制御面になる (Source: [[@2018__Google SRE Workbook__Monitoring]], [[@2018__Google SRE Workbook__Alerting on SLOs]])。 - **wiki の AIOps/SRE ソース群は分析層に偏在し、その足元の計装/保持層をこの博士論文が補完する**: [[AIOpsLab]]・[[Bits AI SRE]]・[[SREGym]] 等はテレメトリを「読んで」診断する分析層(検知・箇所特定・RCA・緩和)の話であり、テレメトリがどう生成・保持されるかは前提として扱う。[[@2025__Kyoto University__Scaling Telemetry Workloads in Cloud Applications - Techniques for Instrumentation, Storage, and Mining]] はその下層——path-oriented データの低オーバーヘッド収集([[分散トレーシング]])と time-oriented データの大規模保持([[時系列データベース]])——を扱い、AIOps が消費するデータの供給側を埋める。(Source: [[@2025__Kyoto University__Scaling Telemetry Workloads in Cloud Applications - Techniques for Instrumentation, Storage, and Mining]], [[@2025__MLSys2025__AIOpsLab - A Holistic Framework to Evaluate AI Agents for Enabling Autonomous Clouds]]) - **「情報を絞る」課題がテレメトリの全層を貫く**: 博士論文の設計指針(§6.2)は「データ削減は文脈知識が最も豊富な層=計装(プロセス/ソケット/トランザクションの文脈)と分析(アラート/障害の文脈)の両端で行い、保持層は文脈非依存に保持へ徹せよ」。これは分析層で観測された [[特徴量削減]] の有効性(無関係メトリクスを減らすと箇所特定が改善)や、LLM エージェントのテレメトリ過剰消費の病理([[Bits AI SRE]]/[[AIOpsLab]] §3.6、[[根本原因分析]])と同じ「障害関連シグナルに絞る」骨格を、収集の最上流(計装)にも適用する点で連続する。(Source: [[@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]]) - **観測テレメトリは一般データと統計的に異なる**: 博士論文はメトリクスの量を「メトリクス数 × 解像度」で特徴づけ大規模スケール(Slack 12M pt/s 等)を引く。[[Toto]]/[[BOOM]]([[時系列基盤モデル]])は同じ観測テレメトリが非定常・不規則・裾が重いと定量化した。テレメトリを「保持する」側(HeteroTSDB)と「予測する」側(TSFM)が、同じ観測データの規模と特異性を別問題として扱っている。(Source: [[@2025__Kyoto University__Scaling Telemetry Workloads in Cloud Applications - Techniques for Instrumentation, Storage, and Mining]], [[@2025__NeurIPS2025__This Time is Different - An Observability Perspective on Time Series Foundation Models]]) - **計装層の最前線は eBPF によるゼロ計装のカーネル/エージェント可観測性に進んでいる**: 博士論文が計装層の低オーバーヘッド収集の例に [[go-conntracer-bpf]](カーネル内フローバンドリング)を挙げたのと同じ [[eBPF]] の系譜で、[[@2026__eunomia.dev__eBPF × AI-LLMs - The Convergence of System Observability and AI]] は eBPF を AI ワークロード向けの「センサ群兼拡張ランタイム」と位置づける。とりわけ [[AgentSight]] は claude code/gemini-cli 等の**コーディングエージェント自体**を、アプリケーションコードへの計装なしに **<3% オーバーヘッド**で観測する。本 wiki の AIOps 群が消費する**アプリケーション層**テレメトリの、さらに下の**カーネル層**でゼロ計装の供給を行う層として接続する。(Source: [[@2025__Kyoto University__Scaling Telemetry Workloads in Cloud Applications - Techniques for Instrumentation, Storage, and Mining]], [[@2026__eunomia.dev__eBPF × AI-LLMs - The Convergence of System Observability and AI]]) - **大規模・異種テレメトリをエージェントにどう与えるかで、設計が「載せずに捌く」と「事前計算 snapshot + ツール」に割れる**: [[OpenRCA]]([[@2025__ICLR__OpenRCA - Can Large Language Models Locate the Root Cause of Software Failures]])は metrics(KPI 時系列)・traces(グラフ構造の呼び出し連鎖)・logs(半構造化テキスト)の 3 種を CSV で与え、**異種フォーマット横断推論**を必須化する。KPI は 1263 種に及び、oracle で 53 種(95% 減)まで絞らねば扱えない metric 主導の長コンテキスト問題を抱える。OpenRCA の RCA-agent は raw telemetry をコンテキストに**載せず**、コード実行で捌く。[[Cloud-OpsBench]]([[@2026__arXiv__Cloud-OpsBench - A Reproducible Benchmark for Agentic Root Cause Analysis in Cloud Systems]])は同じ「大規模・異種テレメトリの供給」問題を、State Snapshot でメトリクス・ログ・制御/データプレーンを凍結し、診断ツール T1〜T10(表3)で平均 487 呼び出しを事前計算(Maximum Information Coverage)する別経路で解く。両者とも対象は大規模・異種のテレメトリだが、OpenRCA は**コード実行で載せずに捌く**、Cloud-OpsBench は**事前計算した snapshot + ツール**で与える、と供給戦略が分岐する。これは博士論文の「文脈最良の両端(計装/分析)で削減せよ」を、分析層の入力整形として別々に実装したものでもある。(Source: [[@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]]) - **「情報を絞る」課題が KPI 1263→53(95% 減)という具体規模で観測される**: 既存の横断的知見「情報を絞る課題がテレメトリ全層を貫く」(分析層の [[特徴量削減]]・LLM のテレメトリ過剰消費)に、[[OpenRCA]] が metric 主導の長コンテキスト問題を **KPI 1263 種 → oracle 53 種(95% 減)** という規模で定量化したケースが加わる。[[MetricSifter]]([[@2024__IEEE Access__MetricSifter - Feature Reduction of Multivariate Time Series Data for Efficient Fault Localization in Cloud Applications]])が無関係メトリクスの削減で箇所特定を改善したのと同じ「障害関連シグナルに絞る」骨格が、LLM エージェントへ与えるテレメトリの絞り込み(oracle で 95% 減)でも要請される。絞らねば長コンテキストに溺れる、という点で連続する。(Source: [[@2025__ICLR__OpenRCA - Can Large Language Models Locate the Root Cause of Software Failures]], [[@2024__IEEE Access__MetricSifter - Feature Reduction of Multivariate Time Series Data for Efficient Fault Localization in Cloud Applications]]) - **INT + eBPF によるクロスレイヤー受動収集がデータセンターテレメトリの「第三の経路」を形成**: eBPF によるホスト層ゼロ計装(AgentSight, eInfer 等)と INT によるネットワーク内 per-hop 計測はそれぞれ独立に発展してきたが、INTFusion([[@2026__IFIP Networking__INTFusion - Unifying Network and Host Telemetry in Data Center Networks]])はこの二系統を per-flow 粒度で統合し、輻輳制御向けのクロスレイヤーテレメトリという用途を開拓した。計装→保持→分析の 3 層モデルにおいて、「計装層のどこで」「何を」取るかという選択が、下流の分析(TCP インキャスト検知・フローサイズ推定)の品質を規定する。ホスト層(eBPF による送信フロートレース)とネットワーク層(INT による受信フローの per-hop 計測)の分業が INTFusion の核心。(Source: [[@2026__IFIP Networking__INTFusion - Unifying Network and Host Telemetry in Data Center Networks]]) - **能動プロービングという計装の系統**: 既存の横断的知見が計装層を受動収集(博士論文の path/time-oriented データ収集、eBPF のゼロ計装)中心に整理してきたのに対し、[[@2024__SIGCOMM__R-Pingmesh - A Service-Aware RoCE Network Monitoring and Diagnostic System]] は受動的なフロー収集でなく、市販 RNIC の UD QP と CQE タイムスタンプを使うエンドツーエンドの能動プロービングで RoCE クラスタの RTT・エンドホスト処理遅延・ドロップを測る別系統を示す。ERSPAN/INT(レガシースイッチ非対応)を避け Traceroute 系を選ぶことで展開容易性を優先し、INT のキュー情報があれば箇所特定精度が上がると認めつつ経路追跡モジュールを能動プローブから分離する——「展開容易性 対 可観測性」のトレードオフを計装設計で表現する。これは博士論文の「文脈最良の両端で削減せよ」と同じく、計装の取り方そのものに設計判断が宿る点で連続する。(Source: [[@2024__SIGCOMM__R-Pingmesh - A Service-Aware RoCE Network Monitoring and Diagnostic System]], [[@2025__Kyoto University__Scaling Telemetry Workloads in Cloud Applications - Techniques for Instrumentation, Storage, and Mining]]) - **フルスタック計装の階層相関**: [[@2025__SIGCOMM__Astral - A Datacenter Infrastructure for Large Language Model Training at Scale]] はアプリ層(NCCL 進捗・CUDA イベント)・トランスポート層(ミリ秒級フロー/RDMA エラー)・ネットワーク層(sFlow+INT の E2E パス解析)・物理層(ハードウェアカウンタ)の 4 層を計装し、クロスホスト・階層のログ相関で根本原因に到達する(MTTLF を日→分、最大 25 倍短縮)。R-Pingmesh が単一(ネットワーク)層の能動プローブで展開容易性を取るのに対し、Astral は多層計装で可観測性を最大化する——同じ「計装」でも投入する「層の数」で設計思想が分かれる。([[@2025__ICLR__OpenRCA - Can Large Language Models Locate the Root Cause of Software Failures]] が分析層で metrics/traces/logs の異種統合を要求するのと同じ階層横断の問題が、インフラ監視の計装層でも 4 層相関として現れる。)(Source: [[@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]]) - **計装の最前線が「GPU/アクセラレータ層」と「LLM 推論演算子・集合通信オペレーション」へ降りる**: 博士論文が計装を path/time-oriented データ収集として整理し、eBPF のゼロ計装(AgentSight)をアプリ/カーネル層の供給に位置づけたのに対し、計装対象はさらに GPU・推論ランタイム・通信ミドルウェアの内部へ降りている。[[@2025__eBPF__eInfer - Unlocking Fine-Grained Tracing for Distributed LLM Inference with eBPF]]・[[@2026__arXiv__ProfInfer - An eBPF-based Fine-Grained LLM Inference Profiler]]・[[@2025__HCDS__eGPU - Extending eBPF Programmability and Observability to GPUs]] は eBPF/PTX 注入でソース改変なしに GPU カーネルや推論演算子を計装し([[GPU観測性]]・[[動的計装]])、[[@2025__SOSP__Mycroft - Tracing Dependencies in Collective Communication Towards Reliable LLM Training]] は集合通信ライブラリの内部状態を計装する。これらが生むのは time/path-oriented の 2 分類に収まりきらない「演算子/通信オペレーション単位の実行テレメトリ」で、博士論文の「文脈最良の層で削減せよ」の原則を GPU/通信ミドルウェア層まで押し広げる(ProfInfer は QoS 違反時にプローブを切る = 計装層での適応的削減)。(Source: [[@2025__eBPF__eInfer - Unlocking Fine-Grained Tracing for Distributed LLM Inference with eBPF]], [[@2025__HCDS__eGPU - Extending eBPF Programmability and Observability to GPUs]]) - **施設テレメトリは物理法則を背景に持ち、推定因果グラフを検証できる**: 施設側(冷却塔温度・ポンプ流量・チラー)の物理メトリクスは物理法則と制御ループに支配されるため、推定因果グラフを既知の物理プロセスと突き合わせて妥当性検証できる——計算/通信メトリクス中心の訓練監視とは検証可能性の性質が異なる。(Source: [[@2025__ISAV__From Exploration to Explanation - ML-Driven Causal Discovery for Datacenter Reliability at Scale]]) - **「collect-first → use-first」の閉ループを SQL ベースのエッジプロセッサで部分的に実現する試みが現れた**: 博士論文が将来課題に挙げた「分析層から計装/保持層へのフィードバック閉ループ」を、[[@2024__IEEE CLOUD__Enabling Programmable Metric Flows]] の [[PMF]] はメトリクス重要度（下流の異常検知への貢献度）と帯域制約をグローバルに考慮したトップダウン最適化として具体化する。PMF は Prometheus の固定 30 秒収集と同一帯域で重み付き再構成誤差を約 600 倍削減し、「メトリクスの不均等な重要度」を収集周波数に反映する閉ループの有効性を示す。ただし PMF の重みは静的に与えられ、分析層のアルゴリズム変更（異常検知モデルの更新等）に自動追従する仕組みは未実装——博士論文の「use-first」が要求する「利用パターンの自動還流」との間にはなお差がある。(Source: [[@2024__IEEE CLOUD__Enabling Programmable Metric Flows]], [[@2025__Kyoto University__Scaling Telemetry Workloads in Cloud Applications - Techniques for Instrumentation, Storage, and Mining]]) - **遡及的サンプリングが「生成は全数、収集は症状駆動」で計装コストと分析有用性を両立させる**: 博士論文の設計指針「データ削減は文脈最良の両端(計装/分析)で」は、[[Hindsight]] の遡及的サンプリングにおいて、計装側では全リクエストを低コスト(tracepoint 約 8 ns)で生成し、分析側(症状トリガー)の文脈で収集対象を絞るという形で具現化される。テイルサンプリングが「全数取り込み→分析側でフィルタ」という保持層に高コストを強いる経路を取るのに対し、Hindsight は保持層(バックエンドコレクタ)の負荷をエッジケーストレース分のみに限定する(93 サービスで 2.6 MB/s 対 78 MB/s)。PMF がメトリクスの重要度で収集周波数を制御するのと同型の「分析価値に基づく選択的収集」だが、対象がメトリクス(time-oriented)でなくトレース(path-oriented)である点が異なる。(Source: [[@2023__NSDI__Hindsight - Tracing Edge-Cases in Distributed Systems]], [[@2025__Kyoto University__Scaling Telemetry Workloads in Cloud Applications - Techniques for Instrumentation, Storage, and Mining]]) - **トレースの伝送オーバーヘッドをオンライン圧縮で削減する経路が加わる**: 博士論文が計装層の低オーバーヘッド収集(in-kernel flow bundling)で path-oriented データの供給を扱ったのと同じ「テレメトリの収集コストを下げる」課題に対し、[[@2025__ISSTA__Tracezip - Efficient Distributed Tracing via Trace Compression|Tracezip]] はスパンのバイトサイズをサービス側でオンライン圧縮する別経路を示す。SRT(Span Retrieval Tree)でスパン間のキー・バリュー冗長性を大域的に抽出し、Alibaba 本番トレース(26.15GB)で lzma 併用時に圧縮率 13.69、スループット約 8 倍を達成する。これはサンプリング(トレースの本数を減らす)ではなく圧縮(各スパンのサイズを減らす)であり、両者は直交して併用できる。計装→伝送→保持→分析の 4 層で「伝送」の負荷を下げる手段が、サンプリング(本数削減)・圧縮(サイズ削減)・遅延収集(Hindsight の遡及的サンプリング)の 3 系統に分岐した。(Source: [[@2025__ISSTA__Tracezip - Efficient Distributed Tracing via Trace Compression]], [[@2025__Kyoto University__Scaling Telemetry Workloads in Cloud Applications - Techniques for Instrumentation, Storage, and Mining]]) - **MELT 4 型のクエリは 97% 超が直近 24 時間以内のデータを対象とし、「鮮度バイアス」がオブザーバビリティワークロードの構造的特性として確立された**: Karumuri ら([[@2021__SIGMOD Record__Towards Observability Data Management at Scale]])は Slack の 1 ヶ月以上のクエリ統計(表2)で、Logs(99.8%)・Metrics(99.8%)・Traces(97.3%)いずれも <24h クエリが 97% 超であることを実測した。これは HTAP(OLTP+OLAP)とは本質的に異なるワークロード形状であり、リアルタイム層と履歴層の独立最適化を正当化する構造的根拠である。インシデント発生時には通常の 2 倍のユーザー数が直近数時間のデータを集中参照するという負荷特性も、同じ鮮度バイアスから導かれる。(Source: [[@2021__SIGMOD Record__Towards Observability Data Management at Scale]] 表2・§2.5) - **Events は Logs のサブカテゴリとする従来の扱いを覆し、独立したデータ型として分離することが適切である**: Karumuri ら(2021)は、事象が発生する有限の値セット（HTTP メソッド・ステータスコード等）からなる高度構造化データが、テキスト全文検索を要する Logs とはデータモデル・クエリ・アクセスパターンの全てにおいて根本的に異なると示した。Slack では Events が 250TB/日(生)・70PB 超を蓄積して 3〜24 ヶ月保持されるのに対し、Logs は 90TB/日で 7 日保持という対照的なライフサイクルを持つ。この観察は MELT 4 分類の定着に繋がった。(Source: [[@2021__SIGMOD Record__Towards Observability Data Management at Scale]] §2.2) - **ヘテロジニアスなテレメトリの「意味」を統一モデルで付与することが、エージェントの情報取得精度を根本から規定する**: 既存の横断的知見が計装/保持層での「削減」に着目するのに対し、[[UModel]] は分析層への「提供品質」を問題にする。メトリクス名 `node_cpu_seconds_total` は LLM にとって単位・型・用途が不明な文字列にすぎず、PromQL の直接生成精度が GPT-4-Turbo でも 2.6% にとどまる（既往研究）。UModel のオブジェクト中心モデリング（EntitySet へのセマンティクス付与・EntitySetLink によるトポロジーグラフ）はこの問題を「フォーマット」でなく「モデル」の次元で解決し、エージェントが方言なしで全テレメトリにアクセスできるようにする。Alibaba Cloud 本番で RCA 精度 8% 向上・OS +9〜+13 ポイントを達成した。(Source: [[@2026__arXiv__UModel - An Agent-Ready Observability Data Modeling Method at Scale]] §III-IV, §VI) - **テレメトリ保持に「プライバシー」という次元が加わる**: 博士論文(Kyoto)はテレメトリを「収集→保持→分析」の 3 層で整理した。PrvTel はその保持層に形式的 ε-差分プライバシー保証を組み込む問題設定を定式化し、「learn-all, store-model」方式(生のレコードでなく生成モデルのデコーダのみ保持)が資源効率・クエリ精度・プライバシー準拠の三者を同時に充足できることを示す。GDPR/CCPA は IP 等の明示的識別子だけでなく「行動推定を可能にするフィールド(トラフィックパターン・CPU/メモリ使用率)」も対象とするため、テレメトリの収集・保持設計にプライバシー要件が直接介入する。IP マスクのみでは MIA の AUC が 1.0 になることが示され、フィールド組み合わせによる再識別リスクを形式的保証で封じる必要性が明確化された。(Source: [[@2026__NSDI__PrvTel - Lightweight Models for Private and Accurate Telemetry Data Retention]], [[@2025__Kyoto University__Scaling Telemetry Workloads in Cloud Applications - Techniques for Instrumentation, Storage, and Mining]]) - **Collector パイプライン内のログ重複排除は「中流フィルタ」として計装/分析層の削減を補完する**: [[OpenTelemetry]] Collector のログ重複排除プロセッサ（[[@2026__OTelBlog__Log Deduplication Processor]]）は、リソース属性・メッセージ本文・重大度等のハッシュで同一ログを集約し、`log_count` と時間範囲を保持しつつ冗長ストレージを排除する。LogReducer がカーネル空間でディスク書き込み前にホットスポットを除去する「最上流フィルタ」であるのに対し、Collector 重複排除は「中流フィルタ」として位置づけられる。両者は博士論文の「文脈最良の両端で削減」の間を埋める手段であり、eBPF カーネルフィルタ → Collector パイプライン処理 → バックエンド保持 のチェーン上で異なる段階で量を絞る。（Source: [[@2026__OTelBlog__Log Deduplication Processor]]、[[@2023__ICSE__LogReducer - Identify and Reduce Log Hotspots in Kernel on the Fly]]） - **Collector のデプロイ規模拡大（65% が 10 台超）と VM ハイブリッド化（51%）がテレメトリパイプラインの運用複雑性を押し上げている**: End User SIG のフォローアップ調査（[[@2026__OTelBlog__OTel Collector Follow-up Survey]]）では、46% がカスタム Collector をビルドし、設定管理（63%）と安定性（52%）が最優先改善領域に挙がった。全再起動なしの単一パイプライン再構成への要望が強く、テレメトリの「保持層」設計だけでなく「計装→保持間のパイプライン運用」が独立した課題として浮上している。博士論文が「計装→保持→分析」の 3 層で構造化したフレームに「パイプライン管理」という横断的な運用層を加える必要性を示す。（Source: [[@2026__OTelBlog__OTel Collector Follow-up Survey]]） - **テレメトリーの歴史は 1960 年代の制御工学→ 2025 年の LLM オブザーバビリティまでの 5 時代に整理される**: [[@2025__YAPC Fukuoka 2025__SREのためのテレメトリー技術の探究]] は 3 枚の年表（p.8–11）でテレメトリー史を俯瞰し、UNIX とインターネット→クラウド→SRE→オブザーバビリティの 4 区分に加え、2025 年以降の「年表のその先」として (1) テレメトリー界の SDGs（collect-first → use-first）、(2) AI for SRE、(3) Observability for AI Systems、(4) Controllability の 4 方向を位置づけた。この年表は博士論文の 3 層モデル（計装→保持→分析）を時間軸に展開したものであり、各時代に計装技術（SNMP→eBPF→ゼロコード計装）・保持技術（RRDtool→TSDB→クラウドストレージ）・分析技術（閾値→統計→ML→LLM）の進展を並列に追える。特に 2019 年の OpenTelemetry 登場を「標準化」の起点に置く整理は、wiki 内の [[オブザーバビリティ]] と [[分散トレーシング]] の関係を補完する。(Source: [[@2025__YAPC Fukuoka 2025__SREのためのテレメトリー技術の探究]], [[@2025__Kyoto University__Scaling Telemetry Workloads in Cloud Applications - Techniques for Instrumentation, Storage, and Mining]]) - **テレメトリのスケーリング 3 貢献が招待講演で俯瞰的に位置づけ直された**: [[@2025__IOTS2025__SREはサイバネティクスの夢をみるか]] は、博士論文([[@2025__Kyoto University__Scaling Telemetry Workloads in Cloud Applications - Techniques for Instrumentation, Storage, and Mining]])の 3 貢献——計装層の eBPF ソケットベースフローバンドリング(CPU ≤2.2%)、保持層の [[HeteroTSDB]](3.98 倍スループット)、分析層の [[MetricSifter]](+4.5% 精度)——を「計測→保存→分析の 3 層モデル」として招待講演の文脈で提示した。個々の手法の詳細は論文に譲りつつ、テレメトリのスケーリング課題全体を SRE のサイバネティクス的再解釈(フィードバックループ・創発・セカンドオーダー)の中に位置づけた点が新しい。（Source: [[@2025__IOTS2025__SREはサイバネティクスの夢をみるか]], [[@2025__Kyoto University__Scaling Telemetry Workloads in Cloud Applications - Techniques for Instrumentation, Storage, and Mining]]） - **CNCF Whitepaper（2023）は従来の「三本柱」を「5 シグナル」に拡張し、プロファイルとダンプを独立したオブザーバビリティシグナルとして公式化した**: メトリクス・ログ・トレースの三本柱に加え、[[継続的プロファイリング]]（コード行レベルの「なぜ」）とダンプ（クラッシュ時メモリイメージ）が加わった。「万能のシグナルは存在しない——各シグナルはビジネス目標に基づいて選択する」という設計原則は、博士論文の「文脈最良の層で削減せよ」と同じ「目的先行」の思想を共有する。メトリクス基数を「ストレージコストの律速因子」として明示した点も重要で、高基数ラベル（PID等）の排除が Prometheus エコシステムの設計を規定してきた歴史的経緯と一致する（Source: [[@2023__CNCF TAG Observability__Observability Whitepaper]]）。 - **SRE ゴールデンシグナル（レイテンシ・トラフィック・エラー・飽和）は三本柱の統合から導出されるアラート/診断基盤であり、単一の柱だけでは計測できない**: Usman ら 2022 のサーベイ([[@2022__IEEE ACCESS__A Survey on Observability of Distributed Edge & Container-Based Microservices]])はログ・メトリクス・トレースを「三本柱」として整理し、それらを統合して初めて 4 つのゴールデンシグナルが得られることを示す。Kyoto U サーベイが「time-oriented / path-oriented」で 2 分類するのと同じデータを「目的別の役割」で 3 分類している——どちらの分類も「マイクロサービスの動作を丸ごと捉える」ために複数種類のテレメトリを組み合わせる必要があるという点では一致する。(Source: [[@2022__IEEE ACCESS__A Survey on Observability of Distributed Edge & Container-Based Microservices]], [[@2025__Kyoto University__Scaling Telemetry Workloads in Cloud Applications - Techniques for Instrumentation, Storage, and Mining]]) ## 未解決の問い - 博士論文の future direction「collect-first → use-first」(分析層から計装/保持層へフィードバックする閉ループ)に対し、[[PMF]]([[@2024__IEEE CLOUD__Enabling Programmable Metric Flows]])は異常検知のメトリクス重要度を収集周波数に反映するトップダウン最適化で部分的に答えた。ただし PMF の重みは静的付与であり、AIOps エージェント([[AIOpsLab]]/[[Bits AI SRE]])のテレメトリ利用パターンを**動的に**還流する閉ループは未達。重みの自動更新(異常検知モデルの再学習時の重み変化をオプティマイザへフィードバック)は実現可能か。 - 博士論文の future direction「LLM 向け failure snapshot 生成」は [[特徴量削減]]([[MetricSifter]])や [[根本原因分析]] のノイズ削減と同型の問題。統計的な前処理を LLM エージェントの入力整形に転用する具体手法は何か。 - Karumuri ら(2021)が提案した ODMS ポリストア型アーキテクチャ（Replicated Log Service → Real-Time Indexing → Persistent Storage → Hot Data Cache）は 2021 年時点でプロトタイプ段階だった。その後 Slack を含む産業でどの程度実装・定着したか、Lambda アーキテクチャとの実際的な差異は何かを追跡する文献はあるか。 - path-oriented データ(trace/call graph)の分析(trace-based RCA)を扱う一次ソースが wiki に無い。メトリクス中心の AIOps 群と path 中心の計装をつなぐ trace-based 手法を ingest して横断的知見を厚くする。 - INTFusion の Centralizer(Elasticsearch)は 2 ホストのプロトタイプ評価にとどまり、数千ホスト規模での融合処理の性能が未検証。ネットワーク + ホストテレメトリの per-flow 融合をリアルタイムで行うコレクタのスケーラビリティ設計は未開拓。 - 大規模・異種テレメトリをエージェントに与える最適経路は「コンテキスト埋め込み」「サンプリング」「コード実行で載せずに捌く([[OpenRCA]])」「事前計算 snapshot + ツール([[Cloud-OpsBench]])」のどれか。KPI 1263 種級のテレメトリ規模での 4 経路の直接比較は未確立。コード実行は raw を載せずに済むが反復呼び出しのコストがかかり、事前計算 snapshot は平均 487 呼び出し分を先に固めるが新規の問いに即応しにくい——この trade-off を規模軸で測った研究はあるか。([[@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]]) - 能動プローブ([[@2024__SIGCOMM__R-Pingmesh - A Service-Aware RoCE Network Monitoring and Diagnostic System]])と受動フルスタック計装([[@2025__SIGCOMM__Astral - A Datacenter Infrastructure for Large Language Model Training at Scale]])を併用したとき、計装オーバーヘッドと箇所特定精度はどう配分されるか。R-Pingmesh は単層・能動・低オーバーヘッド(Agent CPU 約 3%)で展開容易性を、Astral は 4 層相関で可観測性を取る。両者を重ねた設計点はあるか。`[[RDMAネットワーク監視]]` に詳述。 - 施設テレメトリの長期(7 年)データから代表窓(3 ヶ月)を選ぶ基準は、運用条件のドリフトにどれだけ代表性を保つか。([[@2025__ISAV__From Exploration to Explanation - ML-Driven Causal Discovery for Datacenter Reliability at Scale]]) - テレメトリ保持での生成モデル方式(PrvTel の VAE デコーダ保持)は長期縦断クエリに有利だが、分布ドリフトが起きたとき再訓練タイミングをどう自動検知するか。新しいトラフィックパターン(新攻撃手法等)の出現を既存モデルがどの程度カバーできるかは未検証。([[@2026__NSDI__PrvTel - Lightweight Models for Private and Accurate Telemetry Data Retention]]) ## 関連 - ソース: [[@2025__YAPC Fukuoka 2025__SREのためのテレメトリー技術の探究]] / [[@2021__SIGMOD Record__Towards Observability Data Management at Scale]] / [[@2018__Google SRE Workbook__Monitoring]] / [[@2018__Google SRE Workbook__Alerting on SLOs]] / [[@2023__NSDI__Hindsight - Tracing Edge-Cases in Distributed Systems]] / [[@2025__ISSTA__Tracezip - Efficient Distributed Tracing via Trace Compression]] / [[@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__NeurIPS2025__This Time is Different - An Observability Perspective on Time Series Foundation Models]] / [[@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__IOTS2025__SREはサイバネティクスの夢をみるか]] - 概念: [[Scaling Telemetry Workloads]] / [[時系列データベース]] / [[分散トレーシング]] / [[AIOps]] / [[Fault Localization]] / [[特徴量削減]] / [[時系列基盤モデル]] / [[根本原因分析]] / [[RDMAネットワーク監視]] / [[GPU観測性]] / [[動的計装]] / [[ハードウェアカウンタ]] - エンティティ: [[HeteroTSDB]] / [[go-conntracer-bpf]] / [[Mackerel]] / [[AgentSight]] / [[OpenRCA]] / [[Cloud-OpsBench]] / [[PMF]] / [[Hindsight]] / [[Astraea]] / [[Tracezip]] / [[OpenTelemetry]] / [[OBI]] - 概念(隣接層): [[eBPF]] - 関連 MOC: [[SRE - MOC]] / [[異常検知 - MOC]] / [[Project AI4SRE - MOC]] ## 出典 - [[@2025__Kyoto University__Scaling Telemetry Workloads in Cloud Applications - Techniques for Instrumentation, Storage, and Mining]](§1.1–1.4 テレメトリ 3 層とワークロード、§6.2 設計指針、§6.3 future directions) - [[@2025__NeurIPS2025__This Time is Different - An Observability Perspective on Time Series Foundation Models]](観測データの統計的特異性) - [[@2025__ICLR__OpenRCA - Can Large Language Models Locate the Root Cause of Software Failures]](§2.1 metrics/traces/logs を CSV で提供し異種フォーマット横断推論を必須化、§4.1 KPI 1263 種 → oracle 53 種(95% 減)・RCA-agent がコード実行で raw telemetry を載せずに捌く) - [[@2026__arXiv__Cloud-OpsBench - A Reproducible Benchmark for Agentic Root Cause Analysis in Cloud Systems]](§3.2 State Snapshot Paradigm=メトリクス・ログ・制御/データプレーンの凍結、§3.3.2 表3 診断ツール T1〜T10・平均 487 呼び出しの事前計算=Maximum Information Coverage) - [[@2024__SIGCOMM__R-Pingmesh - A Service-Aware RoCE Network Monitoring and Diagnostic System]](§4.2.1 UD QP + CQE タイムスタンプによる RTT・処理遅延の能動測定、§7.4 Traceroute 採用と ERSPAN/INT 回避による展開容易性優先、図7 Agent CPU 約 3%・帯域 300Kbps 未満の低オーバーヘッド) - [[@2025__SIGCOMM__Astral - A Datacenter Infrastructure for Large Language Model Training at Scale]](§3.3 4 層監視:アプリ層 NCCL/CUDA・トランスポート層 RDMA エラー/ミリ秒級レート・ネットワーク層 sFlow+INT・物理層 HW カウンタ、クロスホスト/階層相関で MTTLF 最大 25 倍短縮) - [[@2025__eBPF__eInfer - Unlocking Fine-Grained Tracing for Distributed LLM Inference with eBPF]] / [[@2026__arXiv__ProfInfer - An eBPF-based Fine-Grained LLM Inference Profiler]] / [[@2025__HCDS__eGPU - Extending eBPF Programmability and Observability to GPUs]](GPU/推論演算子層への eBPF/PTX 計装) - [[@2025__SOSP__Mycroft - Tracing Dependencies in Collective Communication Towards Reliable LLM Training]](集合通信ライブラリ内部状態の計装) - [[@2026__NSDI__PrvTel - Lightweight Models for Private and Accurate Telemetry Data Retention]](§3.1 保持目標の定式化・プライバシー要件、§4.3 DP 強制方法論と後処理不変性、§5.6 MIA 実験・IP マスクのみでは AUC=1.0 になることの示示) - [[@2024__IEEE CLOUD__Enabling Programmable Metric Flows]](§IV 動的周波数最適化=メトリクス重要度と帯域制約のトップダウン LP、§V-D 同一帯域で WRE 約 600 倍削減) - [[@2023__NSDI__Hindsight - Tracing Edge-Cases in Distributed Systems]](§3 遡及的サンプリング=全数生成+症状トリガー駆動の遅延的収集、§6.1 93 サービスで 2.6 MB/s 対テイルサンプリング 78 MB/s、§6.4 tracepoint 約 8 ns・55 GB/s 書き込みスループット) - [[@2025__ISSTA__Tracezip - Efficient Distributed Tracing via Trace Compression]](§2.2 KV ペアの約 70% が反復、§3 SRT でオンライン圧縮、§5 Alibaba 本番 lzma 併用 CR 13.69・スループット約 8 倍——テレメトリ伝送層のサイズ圧縮経路) - [[@2021__SIGMOD Record__Towards Observability Data Management at Scale]](§2 MELT 4 類型と特性・表1 Slack 規模データ・表2 鮮度バイアス(>97% <24h)・§2.2 Events 独立型の主張・§2.5 共通特性・§3 Slack 産業事例) - [[@2022__IEEE ACCESS__A Survey on Observability of Distributed Edge & Container-Based Microservices]](§II-C モニタリング vs オブザーバビリティの定義・Figure 2、§IV-A 三本柱とゴールデンシグナルの整理、§IV-B/C F*/C* 枠組み)