# 特徴量削減
## 定義
特徴量削減(feature reduction)は、[[Fault Localization]] の前処理として、障害と無関係な監視メトリクス(単変量時系列)を減らし、後段の箇所特定が扱う問題空間を縮小する取り組み。自動手法は 2 系統に大別される: **normality reduction**(統計的に異常と判定されたメトリクスだけを残す)と **redundancy reduction**(時系列の類似度=相関や形状ベースの距離に基づき冗長なメトリクスを除去する)。([[@2024__IEEE Access__MetricSifter - Feature Reduction of Multivariate Time Series Data for Efficient Fault Localization in Cloud Applications]]) 障害時のメトリクスは root fault metrics($M_A$)・伝播関与メトリクス($M_B$)・無関係メトリクス($M_C$)に分かれ、特徴量削減の目的は $M_C$ を最小化しつつ $M_A \cup M_B$ を保持することにある。
## 横断的知見
- **過剰削減と過少削減のトレードオフ**: [[@2024__IEEE Access__MetricSifter - Feature Reduction of Multivariate Time Series Data for Efficient Fault Localization in Cloud Applications]] は、redundancy reduction が $M_A \cup M_B$ の類似性ゆえ root fault metrics を誤除去して偽陰性を生み(箇所特定の精度が None より悪化しうる)、normality reduction は障害窓の外の異常(バッチジョブ等の周期スパイク)を残して偽陽性を生む、という両系統の構造的欠陥を示す。[[MetricSifter]] はこれを「多変量で障害のタイムウィンドウを局所化し、その窓内に変化点を持つメトリクスだけ残す」教師なし normality reduction で解く。redundancy reduction が箇所特定に有害(None 以下)という知見は、類似メトリクスの除去という直観的に妥当な操作が障害箇所特定では裏目に出ることを示す。(Source: [[@2024__IEEE Access__MetricSifter - Feature Reduction of Multivariate Time Series Data for Efficient Fault Localization in Cloud Applications]])
- **「情報を絞る」前処理の効用は LLM エージェント時代の教訓と通底する**: 特徴量削減が解く「$M_C$ がノイズとして箇所特定を阻害する」問題は、[[AIOpsLab]] §3.6 や [[Bits AI SRE]] が独立に観測した「テレメトリを取りすぎるとエージェント性能が落ちる」病理と同型。統計的な前処理([[MetricSifter]])とエージェント側の自己抑制(成功エージェントほど get_metrics を控える)は、ともに「障害関連シグナルだけに絞る」という同じ目標を別レイヤーで追っている([[Fault Localization]]・[[根本原因分析]] に詳述)。(Source: [[@2024__IEEE Access__MetricSifter - Feature Reduction of Multivariate Time Series Data for Efficient Fault Localization in Cloud Applications]], [[@2025__MLSys2025__AIOpsLab - A Holistic Framework to Evaluate AI Agents for Enabling Autonomous Clouds]])
- **ゴールデンメトリクス依存を外すと、特徴量削減は「設定負荷の削減」でもある**: [[@2018__SREcon18 Americas__Automatic Metric Screening for Service Diagnosis|Chen SREcon18 Americas]] は、障害種別ごとに新しいゴールデンメトリクスを設定する半自動診断の負担を問題化し、全メトリクスを対象に KDE ベースの異常度測定と DBSCAN クラスタリングでダイジェストへ縮約する。MetricSifter は後年、障害窓の局所化と変化点検知で無関係メトリクスを削る研究として定式化するが、Baidu のスライドは「人間が事前に選ぶべき重要メトリクスを、障害時に統計的に選ぶ」運用上の動機を先に示している。(Source: [[@2018__SREcon18 Americas__Automatic Metric Screening for Service Diagnosis]], [[@2024__IEEE Access__MetricSifter - Feature Reduction of Multivariate Time Series Data for Efficient Fault Localization in Cloud Applications]])
- **「メトリクスの不均等な重要度」を分析段でなく収集段で活用する相補的設計が存在する**: [[@2024__IEEE CLOUD__Enabling Programmable Metric Flows]] は異常検知への各メトリクスの貢献度(ピアソン相関で計測)が不均等であること(上位 20% と下位 20% で AU-ROC に大差)を複数のデータセットで実証し、この不均等性を収集周波数のトップダウン最適化に転用する。MetricSifter が分析段(mining 層)で障害窓内の変化点密集を基準に $M_C$ を削除するのに対し、PMF は収集段(計装-保持の中間層)で重要メトリクスに高周波数を割り当て非重要メトリクスの周波数を下げる。同じ「メトリクスの重要度の不均等」を別の層で活用する相補パターンであり、両者を組み合わせれば「収集段で非重要メトリクスの解像度を落とし、分析段で残存する $M_C$ をさらに削除する」2 段削減が成立しうる。(Source: [[@2024__IEEE CLOUD__Enabling Programmable Metric Flows]], [[@2024__IEEE Access__MetricSifter - Feature Reduction of Multivariate Time Series Data for Efficient Fault Localization in Cloud Applications]])
- **MetricSifter の変化点密度に基づく特徴量削減が、テレメトリスケーリングの俯瞰的文脈で「分析層の貢献」として位置づけ直された**: [[@2025__IOTS2025__SREはサイバネティクスの夢をみるか]] では、博士論文の 3 貢献(計装層: eBPF フローバンドリング、保持層: [[HeteroTSDB]]、分析層: [[MetricSifter]])を「計測→保存→分析」の 3 層モデルとして提示し、MetricSifter を分析層での特徴量削減(+4.5% 精度向上)として招待講演の俯瞰図に配置した。個別の手法論は MetricSifter 論文に譲るが、「テレメトリパイプライン全体のどの層がどの問題を解くか」という見取り図のなかに特徴量削減を位置づけた点が新しい。(Source: [[@2025__IOTS2025__SREはサイバネティクスの夢をみるか]], [[@2024__IEEE Access__MetricSifter - Feature Reduction of Multivariate Time Series Data for Efficient Fault Localization in Cloud Applications]])
- **データ削減は「文脈が豊富な層」で行うべき、という設計原理に昇華される**: [[@2025__Kyoto University__Scaling Telemetry Workloads in Cloud Applications - Techniques for Instrumentation, Storage, and Mining]] の博士論文(MetricSifter を mining 層の貢献として収録)は §6.2 で「データ削減(特徴量削減・集約・サンプリング)は文脈知識が最も豊富な層——instrumentation(プロセス/ソケット/トランザクションの文脈)と mining(アラート/障害の文脈)の両端——で行い、storage 層は文脈非依存の保持に徹せよ」と一般化する。特徴量削減(mining 層・障害文脈で $M_C$ を削る)は、この「両端で絞る」原理の mining 側の具体化であり、instrumentation 層のサンプリング/集約([[分散トレーシング]] の flow bundling 等)と対をなす。([[@2025__Kyoto University__Scaling Telemetry Workloads in Cloud Applications - Techniques for Instrumentation, Storage, and Mining]])
## 未解決の問い
- 特徴量削減を「障害関連か否か」の二値分類として評価する指標(balanced accuracy)は、AVG@5 の変動の 13.9–51.0% しか説明しない([[MetricSifter]] 表3)。削減の良さと箇所特定の良さのギャップは何に由来し、どう埋めるか。
- 統計的な特徴量削減の出力を LLM エージェントの入力に渡すと、エージェントのテレメトリ過剰消費問題は緩和されるか([[Fault Localization]] の問いと共通)。
- redundancy reduction は箇所特定に有害だが削減率には強い([[MetricSifter]] 表5)。冗長除去を「箇所特定の精度を落とさず」行う条件はあるか。
- 収集段の周波数最適化([[PMF]])と分析段の特徴量削減([[MetricSifter]])を組み合わせた 2 段削減は、単段より箇所特定精度を維持しつつ帯域コストを下げられるか。PMF の重要度重みが静的である点と、MetricSifter が障害時にのみ作動する事後的手法である点の組み合わせ方は未探索。([[@2024__IEEE CLOUD__Enabling Programmable Metric Flows]])
## 関連
- ソース: [[@2018__SREcon18 Americas__Automatic Metric Screening for Service Diagnosis]] / [[@2024__IEEE Access__MetricSifter - Feature Reduction of Multivariate Time Series Data for Efficient Fault Localization in Cloud Applications]] / [[@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]] / [[@2024__IEEE CLOUD__Enabling Programmable Metric Flows]]
- 概念: [[Fault Localization]] / [[変化点検知]] / [[AIOps]] / [[根本原因分析]] / [[テレメトリ]]
- エンティティ: [[MetricSifter]] / [[PyRCA]] / [[PMF]]
- 関連 MOC: [[異常検知 - MOC]] / [[Project AI4SRE - MOC]] / [[SRE - MOC]]
## 出典
- [[@2024__IEEE Access__MetricSifter - Feature Reduction of Multivariate Time Series Data for Efficient Fault Localization in Cloud Applications]](§I, §II-D, Table 2, §IV, §V)
- [[@2025__Kyoto University__Scaling Telemetry Workloads in Cloud Applications - Techniques for Instrumentation, Storage, and Mining]](§6.2 設計指針: データ削減は文脈が豊富な両端で)
- [[@2024__IEEE CLOUD__Enabling Programmable Metric Flows]](§I 図 1: メトリクスの異常検知への貢献度の不均等性、§IV トップダウン周波数最適化=収集段での重要度活用)
- [[@2018__SREcon18 Americas__Automatic Metric Screening for Service Diagnosis]](p.6–8 ゴールデンメトリクス依存から全メトリクススクリーニングへの移行、p.10–14 異常度測定・クラスタリング・評価)