# ログベース障害診断 ## 定義 ログベース障害診断(log-based fault diagnosis)は、システム実行時に生成されたログデータを解析して障害の種別を特定する取り組みの総称。[[ログ解析]]パイプラインの下流タスクの一つで、[[AIOps]] における障害管理の中核を担う。O&M（運用保守）エンジニアが実施する**障害トリアージ(fault triage)**——障害を適切なチームに割り当てて緩和作業を優先づけする——を自動化することが主目的である。 **障害診断**は**異常検知**とは異なる: 異常検知は「何か通常でないことが起きているか」を検出するのに対し、障害診断は「どのタイプの障害が発生したか」を特定する多クラス分類問題として定式化される。また**根本原因分析**とも役割が分かれる: RCA は「なぜ障害が起きたか（原因）」を特定し、障害診断は「どのカテゴリの障害か（症状の類型化）」を返す。両者は組み合わさることが多い。 ログベース障害診断の一般的なパイプラインは以下の通りである。(1) 障害発生前後の時間窓からログを収集し、(2) ログを構造化・前処理した後、(3) 機械学習・深層学習・LLM などの手法で障害種別を推定し、(4) 必要に応じて診断根拠の説明を提供する。(Source: [[@2025__nkcs.iops.ai__Accurate and Interpretable Log-Based Fault Diagnosis using Large Language Models]]) ## 横断的知見 - **解釈性（interpretability）が実務的障壁として前景化しつつある**: 機械学習・深層学習ベースの障害診断手法（LogCluster・Cloud19・LogKG 等）が性能面で成熟してきた一方で、「なぜその種別に分類されたか」の説明が欠如しているため、O&M エンジニアが診断結果を信頼して行動することが困難という問題が複数論文で指摘される。LogInsight([[@2025__nkcs.iops.ai__Accurate and Interpretable Log-Based Fault Diagnosis using Large Language Models]])は説明生成を第一級の設計目標として明示した初の包括的フレームワーク。同様の方向性は LogPrompt([[@2025__nkcs.iops.ai__Accurate and Interpretable Log-Based Fault Diagnosis using Large Language Models]]が引用 [11])でも見られ「解釈可能性」がフィールドの新たな競争軸になりつつある。(Source: [[@2025__nkcs.iops.ai__Accurate and Interpretable Log-Based Fault Diagnosis using Large Language Models]] §I) - **LLM のファインチューニングはプロンプトベース・RAG を障害診断タスクで圧倒する**: LogInsight の実験(Table IX)では、Mistral-7B ファインチューニング(Weighted F1: 0.883/0.997/0.997)に対して、同一モデルのプロンプトベース(0.508/0.292/0.591)と RAG ベース(0.302/0.461/0.141)は大幅に劣る。ベース LLM は指示に従わず非構造的な出力を頻繁に生成するのに対し、ファインチューニングはドメイン知識の内在化と出力形式の遵守を同時に達成する。一般的な LLM × ログ解析での「RAG vs ファインチューニング」の選択に対して、障害診断ドメインではファインチューニングが明確に有利という実証的根拠を提供する。(Source: [[@2025__nkcs.iops.ai__Accurate and Interpretable Log-Based Fault Diagnosis using Large Language Models]] Table IX) — 一方、[[@2025__FSE Companion__A Multimodal Intelligent Change Assessment Framework for Microservice Systems Based on Large Language Models]]（SCELM）ではデータ不足・リアルタイム要件・機密制約が重なる変更管理ではファインチューニングより RAG が実用的だと主張しており、タスク特性とデータ量によって最適手法が異なることに注意が必要。 - **「コンテンツ中心の直接処理」対「構造化フィールドの知識グラフ統合」という設計軸**: LogInsight([[@2025__nkcs.iops.ai__Accurate and Interpretable Log-Based Fault Diagnosis using Large Language Models]])は正規表現でコンテンツフィールドのみを抽出しログパースを不要とする——LLM が自然言語としてログコンテンツを理解することを前提とする設計。これに対し [[LogKG]]([[@2023__TSC__LogKG - Log Failure Diagnosis through Knowledge Graph]])はタイムスタンプ・ログレベル・IP・コンポーネント・タスク ID・コンテンツを単一の知識グラフに統合し、構造化フィールド間の関係を KGE（知識グラフ埋め込み）でモデル化する。両者は同一の Nankai/CMCC グループの成果であり、同じ CMCC 本番環境で評価されているため直接比較が可能: LogKG は CMCC データセットで精度 1.0 を達成しているが、外部への汎化性と説明性では LogInsight が優れる。この 2 系統の設計哲学——LLM の言語理解 vs 明示的グラフ構造——が障害診断の中心的設計分岐として浮かび上がる。(Source: [[@2025__nkcs.iops.ai__Accurate and Interpretable Log-Based Fault Diagnosis using Large Language Models]], [[@2023__TSC__LogKG - Log Failure Diagnosis through Knowledge Graph]]) - **DBSCAN + TF-IDF の 2 段コンテキスト圧縮は、LLM の実用展開における「長文ログ問題」を解く実践的解答の一つ**: LogInsight の FOLS モジュールは、故障期間中のログの多くが冗長・ノイジーであり、真の診断手がかりはスパースかつ非反復的という観察に基づく。Dataset 2 のような例では 1 ケースあたり最大 58,056 件ものログエントリが存在し、4096 トークンの LLM コンテキスト制限を大きく超える。クラスタリングによる冗長排除と TF-IDF による重要度フィルタリングを組み合わせる本設計は、[[LogPilot]] のリクエスト単位クラスタリングや [[RCAgent]] のチャンク化と同じ「情報を絞ってから LLM を呼ぶ」設計原理に収束している。ログパース系手法（Drain / DivLog / LILAC）がクラスタリング系手法より劣った原因は、パース誤りとプレースホルダ「*」が LLM の解析を誤導することにある。(Source: [[@2025__nkcs.iops.ai__Accurate and Interpretable Log-Based Fault Diagnosis using Large Language Models]] §IV-B, Table V) ## 未解決の問い - **未知障害種別への対応**: LogInsight は既知障害種別リストをプロンプトで明示する closed-set 分類に帰着しており、実運用で発生する未知障害種別を正しく「unknown」として分類できないことが多い。外部知識ベースや自己教師学習を組み込むことで、open-set の障害診断に拡張できるか。 - **説明品質の客観的評価**: 専門家評価（有用性 Mean 3.80/HIP 75.7%）はバイアスを含む可能性がある。ROUGE・BERTScore などの自動評価と専門家評価のどちらが障害診断説明の真の品質を反映するか。また、説明の「有用性」と「診断精度」の間の相関は測定されていない。 - **解釈性と性能のトレードオフの一般化**: LogInsight は説明生成によるオンライン推論時間の増加（平均 2.7〜8.5 秒）を許容範囲とするが、これはどの種の障害診断シナリオまで成立するか。マイクロ秒単位の応答が求められるサービスでの適用可能性は未検討。 - **マルチモーダル拡張**: ログパターンが高度に類似する障害種別（Port Failure と LACP Flapping など）はログ単一モダリティでは判別困難。性能メトリクスやトレース・コールグラフを統合したマルチモーダル障害診断への拡張は [[マルチモーダル障害診断]] の知見とどう接続するか。 - **テスト段階への適用**: SynthoDiag([[@2024__FSE__SynthoDiag - Fault Diagnosis for Test Alarms in Microservices through Multi-source Data]], FSE 2024)は SIT フェーズに特化したログベース障害診断で、実行ログ・トレースログ・テストケース情報というテスト特有のマルチソース構造を活用する。本番環境向けの LogInsight・LogKG と同じ「ログから障害カテゴリを特定する」問題を解くが、テスト操作という構造的区切りを利用できる点が本番環境と異なる。テスト環境固有のブロック差分フィルタリング(操作単位のログブロック比較)が有効であることは、本番環境での「どの粒度でコンテキストを保持するか」という設計問題に示唆を与える。(Source: [[@2024__FSE__SynthoDiag - Fault Diagnosis for Test Alarms in Microservices through Multi-source Data]] §3.2, §4.3.1) - **LLM ファインチューニングの継続学習**: 障害種別が時間とともに変化する動的環境（新種の障害、ソフトウェアアップデート後の挙動変化）で、ファインチューニングモデルをどう継続更新するか。再学習コストと更新頻度のバランスは未解決。 ## 関連 - 親概念: [[ログ解析]] / [[AIOps]] - 下位概念: [[障害トリアージ]] / [[根本原因分析]] - 関連概念: [[ログパース]] / [[ログベース異常検知]] / [[LLMによる根本原因分析]] / [[マルチモーダル障害診断]] - 主要システム: [[LogInsight]] / [[LogKG]] / [[LogCluster]] / [[LogPrompt]] / [[LogGPT]] - 関連 MOC: [[structures/AIOps - Log Analysis - MOC]] / [[structures/LLM for SREの障害原因診断論文の分類]] ## 出典 - [[@2025__nkcs.iops.ai__Accurate and Interpretable Log-Based Fault Diagnosis using Large Language Models]] §I（問題設定・既存手法の限界）、§III（先行研究分類）、§IV（LogInsight 手法）、§V（実験・結果） - [[@2023__TSC__LogKG - Log Failure Diagnosis through Knowledge Graph]]（知識グラフベース障害診断、CMCC 本番環境展開） - [[@2016__ICSE-C__Log Clustering Based Problem Identification for Online Service Systems]]（LogCluster、ログクラスタリングベース障害識別）