# Fault Localization ## 定義 Fault Localization(障害箇所特定)は、障害や異常が検知された後に、原因候補となるコンポーネント、サービス、ホスト、メトリクス、ログ系列、ネットワーク経路、GPU/ランクなどの「場所」を絞り込む取り組みである。[[AIOps]] の 4-level taxonomy では検知の後、[[根本原因分析]] の前に置かれるが、LLM 系サーベイでは RCA の下位タスクとして扱われることもある。(Source: [[@2025__MLSys2025__AIOpsLab - A Holistic Framework to Evaluate AI Agents for Enabling Autonomous Clouds]], [[@2025__CSUR__A Survey of AIOps in the Era of Large Language Models]]) このページは親概念であり、詳細は隣接ページへ分ける。RCA の評価指標は [[RCA評価設計]]、入力削減は [[RCA入力選別]] と [[特徴量削減]]、ログ由来の component localization は [[ログ解析]]、トレース由来の手法は [[分散トレーシング]]、訓練クラスタと RDMA 網の箇所特定は [[LLM学習モニタリング]]・[[RDMAネットワーク監視]]・[[GPUクラスタ運用]] に置く。 ## 横断的知見 - **障害箇所特定は「どこ」を答え、RCA は「なぜ」を答えるが、境界は手法ごとに揺れる**: MetricSifter や Minder は root fault metrics / faulty machine を絞る段階で止まり、根本原因の説明は後段に残す。一方 LogPilot はログから faulty component と root cause summary を同時に出すため、箇所特定と RCA が一体化する。(Source: [[@2024__IEEE Access__MetricSifter - Feature Reduction of Multivariate Time Series Data for Efficient Fault Localization in Cloud Applications]], [[@2025__NSDI__Minder - Faulty Machine Detection for Large-scale Distributed Model Training]], [[@2025__ASE__LogPilot - Intent-aware and Scalable Alert Diagnosis for Large-scale Online Service Systems]]) - **信号源は、ドメインの構造に従って変わる**: マイクロサービスでは依存グラフと伝播、分散トレースではリクエスト経路と処理時間、ログではイベント系列と言語情報、LLM 訓練クラスタでは均質な並列ワークロードからの逸脱、RDMA/ネットワークでは経路・層・来歴が信号源になる。単一の localizer を全ドメインに転用するより、信号源ごとに手法を分ける方が自然である。(Source: [[@2021__JSEP__TraceRank - Abnormal service localization with dis-aggregated end-to-end tracing data in cloud native systems]], [[@2025__NSDI__Minder - Faulty Machine Detection for Large-scale Distributed Model Training]], [[@2024__SIGCOMM__R-Pingmesh - A Service-Aware RoCE Network Monitoring and Diagnostic System]]) - **粒度は component → metric → machine/rank → network layer へ細分化している**: Pinpoint はリクエストトレースと統計検定でコンポーネントを絞った。MetricSifter はメトリクスレベルへ下り、Minder/Pulse は訓練クラスタでマシン・ランク単位へ下り、R-Pingmesh/Astral/Hawkeye は物理リンク、スイッチ、end-host、PFC backpressure の起点へ降りる。粒度が細かくなるほど、監視解像度とデータ量の制約が強くなる。(Source: [[@2002__DSN__Pinpoint - Problem Determination in Large, Dynamic Internet Services]], [[@2024__IEEE Access__MetricSifter - Feature Reduction of Multivariate Time Series Data for Efficient Fault Localization in Cloud Applications]], [[@2026__ASPLOS__Pulse - Fine-grained and Non-intrusive LLM Training Monitoring via Microsecond-level Traffic Measurement]], [[@2025__SIGCOMM__Hawkeye - Diagnosing RDMA Network Performance Anomalies with PFC Provenance]]) - **入力削減は古典統計手法と LLM エージェントの共通課題である**: MetricSifter は無関係メトリクスが因果探索へノイズを持ち込むため事前に削る。AIOpsLab や Bits AI SRE では、エージェントがテレメトリを取りすぎるとコンテキストウィンドウを圧迫し性能が落ちる。箇所特定の精度は、推論器の賢さだけでなく、どの信号を見せないかにも依存する。(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]]) - **Baidu のメトリクススクリーニングは、FluxRank 論文化前の実務向け箇所特定パターンを示す**: [[@2018__SREcon18 Americas__Automatic Metric Screening for Service Diagnosis|Chen SREcon18 Americas]] は、コールグラフを見ながら上流から下流へモジュールを調べる診断作業を、メトリクス異常度測定・インスタンス単位のクラスタリング・ダイジェストランキングで置き換える。後続の [[@2019__ISSRE__FluxRank - A Widely-Deployable Framework to Automatically Localizing Root Cause Machines for Software Service Failure Mitigation|FluxRank]] が「根本原因マシン箇所特定」として詳細化する前に、SRE 実務者向けには「ゴールデンメトリクス設定を不要にし、読むべきメトリクス集合を推薦する」問題として提示されていた。これは障害箇所特定が、説明生成より先に「どこを見るか」を縮小する運用支援として導入されたことを示す。(Source: [[@2018__SREcon18 Americas__Automatic Metric Screening for Service Diagnosis]], [[@2019__ISSRE__FluxRank - A Widely-Deployable Framework to Automatically Localizing Root Cause Machines for Software Service Failure Mitigation]]) - **評価指標は SE FL と AIOps FL で似ているが、同一ではない**: Kochhar+ 2016 は実務者が Top-5 成功、成功率 75%、100kLOC、1 分以内、判断根拠を強く求めることを示した。AIOps 系では AC@K、Avg@K、Exact Match、Top-3 などが使われる。どれも「上位 K に原因候補が入るか」を測るが、ランキング品質、説明品質、緩和への有用性は別に評価する必要がある。(Source: [[@2016__ISSTA__Practitioners' Expectations on Automated Fault Localization]], [[@2025__ASE__LogPilot - Intent-aware and Scalable Alert Diagnosis for Large-scale Online Service Systems]]) - **運用目的によって、精密な箇所特定と粗い隔離は分岐する**: 研究ベンチマークは正しい root cause entity を細かく当てる方向へ進むが、LLM 訓練基盤では継続を優先して並列グループ単位で過剰排除する設計もある。復旧時間を最小化する場面では、正確な箇所特定より迅速な隔離が合理的になる。(Source: [[@2025__SC__Fine-grained Automated Failure Management for Extreme-Scale GPU Accelerated Systems]], [[@2025__NSDI__Minder - Faulty Machine Detection for Large-scale Distributed Model Training]]) - **「どこ」と「どの種類」を同時に推薦するアクション可能な箇所特定が実務家の本来のニーズである**: DéjàVu([[@2022__ESEC FSE__Actionable and Interpretable Fault Localization for Recurring Failures in Online Service Systems]])は「障害ユニット(failure unit = コンポーネント × メトリクスグループ)」という概念を導入し、「個別メトリクス(細かすぎて緩和策が見えない)」と「コンポーネント単体(粗すぎて種別が分からない)」の中間を狙う。産業調査では平均診断時間 28.98 分のうち障害ユニット特定に 9.2 分かかっており、ここを自動化すれば緩和策への接続が直接速くなる。(Source: [[@2022__ESEC FSE__Actionable and Interpretable Fault Localization for Recurring Failures in Online Service Systems]] §2.3) - **[[再帰障害]](74〜94%)は監督学習の強力な根拠であり、GNN ベース手法が有効**: DéjàVu は[[障害依存グラフ]](FDG)上で GAT を 8 層スタックし、障害伝播を多ホップでモデル化する。同クラス内の過去障害から学習した特徴抽出器は、初めて現れる箇所(未知ユニット)の同種障害にも汎化する。これは「コンポーネントの場所でなくメトリクスパターンで種別を認識する」設計による。(Source: [[@2022__ESEC FSE__Actionable and Interpretable Fault Localization for Recurring Failures in Online Service Systems]] §3.1, §5.5) - **障害特徴の不均衡分布は GAT+アテンション系手法でも残る構造的課題であり、損失関数設計で補完できる**: [[FL-AIer]]([[@2025__TOSEM__Making Fault Localization in Online Service Systems More Actionable and Interpretable]])は DéjàVu と同一データセット・同一「障害ユニット」概念を使いながら、多層 GAT（残差付き）＋ 1D-CNN で長距離依存と時空間特徴を強化し、マルチヘッドアテンションで障害特徴間の複雑な依存関係を解消し、Fault Knowledge Balancing（重み付き KL ダイバージェンス損失＋過剰サンプリング）で低頻度障害クラスへの過小学習を是正した。結果 DéjàVu に対し A@1 で +5.82〜+15.56%（平均 +9.24%）を達成。アーキテクチャ改善ではなく、同粒度設計のままトレーニング設計と依存関係処理が性能向上の源泉である。(Source: [[@2025__TOSEM__Making Fault Localization in Online Service Systems More Actionable and Interpretable]], [[@2022__ESEC FSE__Actionable and Interpretable Fault Localization for Recurring Failures in Online Service Systems]]) - **解釈可能性は「内部機構の理解」より「診断経路の提示」が産業実務に合っている**: FL-AIer は LIME・LR のような特徴重要度スコアを使わず、特徴符号化の出力を入力として意思決定木(DT)を代理モデルとして訓練し、「伝送キュー 1 → 2 → ss_total で障害」というステップ別の診断経路をエンジニアに提示する。LLM ベースの障害説明と異なり、DT の分岐ルールは決定論的で再現可能である。これは Kochhar+ 2016 の実務者ニーズ調査（判断根拠の提示を強く求める）と一致する。(Source: [[@2025__TOSEM__Making Fault Localization in Online Service Systems More Actionable and Interpretable]], [[@2016__ISSTA__Practitioners' Expectations on Automated Fault Localization]]) - **変更後サービスの不均衡障害データは GAT 系・深層学習系手法の共通の盲点であり、損失関数設計だけでは対処できない**: FL-AIer の FKB（Fault Knowledge Balancing）は同一データセット内の障害クラス不均衡を重み付き損失で補正するが、これは「既存サービスの障害種別のサンプル数が多すぎる」第一の不均衡への対応にすぎない。新規デプロイサービスで「その障害種別のサンプルが 1〜2 件しかない」第二の不均衡には対処できない。SLIM はこの第二の不均衡に対し、DNF ルールセットと劣モジュラ最適化により F1 スコアを直接最大化するアルゴリズム設計レベルの解答を与えた最初の手法である。DejaVu は再サンプリングでこれを解決しようとしたが、実験上では効果が限定的であることが示された。(Source: [[@2024__ASE__SLIM - A scalable and interpretable light-weight fault localization algorithm for imbalanced data in microservice]], [[@2025__TOSEM__Making Fault Localization in Online Service Systems More Actionable and Interpretable]], [[@2022__ESEC FSE__Actionable and Interpretable Fault Localization for Recurring Failures in Online Service Systems]]) - **ラベル不要の RCL は「システム偏差との類似度ランキング」で実現できる**: ART([[@2024__ASE__ART - A Unified Unsupervised Framework for Incident Management in Microservice Systems]])は、インスタンスレベル偏差(ILD)とシステムレベル偏差(SLD)のコサイン類似度をランキング指標として使う教師なし RCL を提案した。実証研究では根本原因インスタンスの ILD-SLD 類似度が 0.71〜0.77 に対し非根本原因は 0.49 と定量的に分離可能であることを示し、監視ありの Dejavu・DiagFusion を上回った。このアプローチは「どのモジュールが根本原因か」を「どのインスタンスの偏差パターンがシステム全体の偏差パターンに最も近いか」という距離問題として再定式化する——ラベル付き障害事例が蓄積されていない初期段階でも即座に適用できる。(Source: [[@2024__ASE__ART - A Unified Unsupervised Framework for Incident Management in Microservice Systems]], §2.1, §4, Table 6) - **LagRCA(FSE Companion '26)は箇所特定の「時刻の整合性」を明示的な設計対象とした——原因と症状の時間的位置ずれ自体を箇所特定の失敗要因として定量化**: 従来の箇所特定研究は「どのサービス/メトリクスが原因か」という空間的な問いに集中してきたが、LagRCA は D1(46 インスタンス・本番銀行データ)の実インシデント分析で最大伝播ラグ Δt_max が 2 分以上の非同期伝播を示すインシデントが 81.5%を占めることを定量化し、「原因と症状の時間的整列」自体を箇所特定精度を左右する独立した設計変数として扱った。既存の同期集約前提の時空間 GNN(アブレーション c1: 静的呼び出しグラフのみ、c3: 標準 GCN)はいずれもフルモデルに劣り(D1 AC@1: 0.583/0.583 vs 0.667)、時刻整合性の欠如が箇所特定精度を直接下げることを実証した。(Source: [[@2026__FSE Companion__Bridging the Delay - Lag-Aware Spatio-Temporal Causal Inference for Microservice Root Cause Analysis]]) - **[[バッチ障害診断]](Aloha, FSE Companion '26)は、単一障害の箇所特定とは異なる「集団としての異常パターン」を対象とし、実務適用の障壁が「アルゴリズムの欠如」ではなく「usability gap」にあることを指摘した**: 対照分析(contrast analysis)ベースの既存アルゴリズム [[CONAN]] は高精度な根本原因パターン抽出を提供する一方、シナリオ適用可能性の判定・データ品質の検証・目的関数/パラメータ選択という前後工程が手動である限りエンジニアの採用意欲が上がらない。Aloha はこれらを Fault Tree Analysis 由来の基準ベース判定・実行可能な検証ツールキット・RAG ベースの過去ケース検索という human-in-the-loop エージェントで補い、127 件のパイロットで CONAN に対し全 ACC@k で上回った(ACC@5: 0.9370 vs 0.6963)うえ、診断時間を約 10 時間から約 0.5 時間に短縮した。「精度の高いアルゴリズムを持つだけでは実務に採用されない」という知見は、他の箇所特定手法にも一般化しうる論点である。(Source: [[@2026__FSE Companion__Aloha - Localizing Batch Failures in Large-scale Cloud Systems via Contrast Analysis and Human-in-the-Loop Agent]]) ## 未解決の問い - **LagRCA の上流調整(β パラメータ)と DéjàVu/FL-AIer の不均衡対処は「下流被害者の過大評価」という共通課題への異なる解答であり、統合の可能性は未検証**: FL-AIer は障害クラス不均衡を損失関数(FKB)で補正するのに対し、LagRCA は推論時に上流由来の異常スコアを因果的に差し引く(s=ReLU(r−β·p))。両者は「見かけ上目立つが根本原因でない箇所を抑制する」という同じ目標を異なる段階(訓練時 vs 推論時)で達成しており、組み合わせた場合の効果は未検証。(Source: [[@2026__FSE Companion__Bridging the Delay - Lag-Aware Spatio-Temporal Causal Inference for Microservice Root Cause Analysis]], [[@2025__TOSEM__Making Fault Localization in Online Service Systems More Actionable and Interpretable]]) - Top-K 型の箇所特定成功と、説明の妥当性、調査過程の健全性、緩和への有用性をどのように接続して評価すべきか。 - メトリクス、ログ、トレース、ネットワーク経路、GPU/集合通信カウンタを統合する localizer は、どの障害クラスで単一モダリティを上回るか。 - 監視粒度を下げたとき、どの粒度の障害まで検出・箇所特定可能か。サンプリング率、トレース欠落、メトリクス集約が精度に与える影響を体系化できるか。 - 正確な箇所特定と迅速な隔離のトレードオフは、MTTR、偽陽性隔離コスト、再発防止のどの条件で切り替えるべきか。 - LLM エージェントに統計的な特徴量削減結果を前処理として与えると、探索効率と説明品質は上がるか。 - SREcon18 の top 1 = 60/70 と FluxRank 論文の top 1 = 55/70 は、評価対象・ラベル定義・ダイジェスト定義のどれが異なるのか。スライドと論文の評価差を追うことで、研究発表へ進む過程で何が厳密化されたかを確認できる。 - DéjàVu の「障害ユニット」概念は、GAT を活用する他の AIOps システムにも適用できるか。サービスメッシュの KPI ではなくデプロイ関係と組み合わせた FDG 自動構築のコスト対効果はどれくらいか。 - FL-AIer の未知障害種別への対応(同種の別場所への転移でなく、全く新しい種別)は開放課題である。未知障害と履歴障害の類似度計算をどのように設計すれば対処できるか。 - FL-AIer は訓練データの 80% でほぼ最良性能を達成するが、訓練データが 10〜30% 台では急激に性能が劣化する。初期の少数ショット期間に産業導入する際の実際的な最低障害収集数はどこか。 - SLIM は新規デプロイサービスで 2 件の訓練事例から正確な箇所特定が可能だが、1 件での対応はゼロショット学習の問題として再定式化できるか。LLM に障害の意味を事前学習させて 1 件でも汎化できるか。 - DNF ルールの「IF (cpu_usage>80 AND file_disk_read>180) OR ...」形式は解釈可能だが、障害種別ごとに個別モデルを訓練するため種別数が多い場合にスケールするか（Dataset D では種別 5、最大種別数はどのくらいまで対応可能か）。 ## 関連 - 上位/隣接概念: [[AIOps]] / [[根本原因分析]] / [[異常検知]] / [[RCA評価設計]] / [[RCA入力選別]] / [[特徴量削減]] / [[不均衡障害分類]] / [[バッチ障害診断]] - 入力別概念: [[分散トレーシング]] / [[ログ解析]] / [[マルチモーダル障害診断]] / [[テレメトリ]] - ドメイン別概念: [[LLM学習モニタリング]] / [[GPUクラスタ運用]] / [[RDMAネットワーク監視]] / [[耐障害LLM訓練]] - 関連 MOC: [[LLM for SREの障害原因診断論文の分類]] / [[異常検知 - MOC]] / [[Project AI4SRE - MOC]] ## 出典 - [[@2024__ASE__ART - A Unified Unsupervised Framework for Incident Management in Microservice Systems]](§2.1 実証研究 Table 3 ILD-SLD 類似度差、§4 RCL 手法 cosine similarity ランキング、§5 Table 6 監視あり手法との比較) - [[@2002__DSN__Pinpoint - Problem Determination in Large, Dynamic Internet Services]](リクエストトレースと統計的コンポーネント特定) - [[@2016__ISSTA__Practitioners' Expectations on Automated Fault Localization]](実務者採用閾値、Top-5、判断根拠) - [[@2021__JSEP__TraceRank - Abnormal service localization with dis-aggregated end-to-end tracing data in cloud native systems]](非集計トレース、スペクトル解析、PageRank 補完) - [[@2022__IEEE CLOUD__Localizing and Explaining Faults in Microservices Using Distributed Tracing]](スパンツリー因果推論による障害箇所特定) - [[@2024__IEEE Access__MetricSifter - Feature Reduction of Multivariate Time Series Data for Efficient Fault Localization in Cloud Applications]](特徴量削減、root fault metrics、因果探索前処理) - [[@2025__MLSys2025__AIOpsLab - A Holistic Framework to Evaluate AI Agents for Enabling Autonomous Clouds]](4-level taxonomy、localization 評価) - [[@2025__CSUR__A Survey of AIOps in the Era of Large Language Models]](LLM 時代の failure localization 分類) - [[@2025__ASE__LogPilot - Intent-aware and Scalable Alert Diagnosis for Large-scale Online Service Systems]](ログベース component localization と root cause summarization) - [[@2025__NSDI__Minder - Faulty Machine Detection for Large-scale Distributed Model Training]](分散訓練クラスタの machine-level similarity) - [[@2026__ASPLOS__Pulse - Fine-grained and Non-intrusive LLM Training Monitoring via Microsecond-level Traffic Measurement]](sub-OP-level 監視と rank-level 箇所特定) - [[@2024__SIGCOMM__R-Pingmesh - A Service-Aware RoCE Network Monitoring and Diagnostic System]](RoCE パス単位監視とリンク/スイッチ特定) - [[@2025__SIGCOMM__Astral - A Datacenter Infrastructure for Large Language Model Training at Scale]](層間相関による起因層切り分け) - [[@2025__SC__Fine-grained Automated Failure Management for Extreme-Scale GPU Accelerated Systems]](GPU 単位の細粒度修復対象切り分け) - [[@2025__SIGCOMM__Hawkeye - Diagnosing RDMA Network Performance Anomalies with PFC Provenance]](PFC 来歴追跡と原因フロー/ホスト特定) - [[@2026__arXiv__Which Types of Heterogeneity Matter for Root Cause Localization in Microservice Systems]](異質性と root cause localization) - [[@2026__Cluster Computing__Anomaly detection and root-cause identification in microservices - a survey]](グラフベース RCI と手法比較) - [[@2018__SREcon18 Americas__Automatic Metric Screening for Service Diagnosis]](サービス診断向け自動メトリクススクリーニング、70 件中 60 件 top 1、実行時間 6 分以下) - [[@2022__ESEC FSE__Actionable and Interpretable Fault Localization for Recurring Failures in Online Service Systems]](DéjàVu: 障害ユニット × GAT で再帰障害を行動可能かつ解釈可能に箇所特定、MAR 1.66〜5.03) - [[@2025__TOSEM__Making Fault Localization in Online Service Systems More Actionable and Interpretable]](FL-AIer: 多層 GAT + マルチヘッドアテンション + FKB で DéjàVu を A@1 平均 +9.24%、DT 代理モデルで診断経路提示) - [[@2024__ASE__SLIM - A scalable and interpretable light-weight fault localization algorithm for imbalanced data in microservice]](SLIM: 劣モジュラ最適化によるルールセット学習で変更後サービスの不均衡障害データに対応、2 件の訓練事例で正確な箇所特定) - [[@2026__FSE Companion__Aloha - Localizing Batch Failures in Large-scale Cloud Systems via Contrast Analysis and Human-in-the-Loop Agent]](Aloha: 対照分析ベースのバッチ障害診断における usability gap の指摘と human-in-the-loop エージェントによる解消、CONAN 比較で ACC@5: 0.9370 vs 0.6963)