# Log-Insight: Automating Microservice Incident Diagnosis via Neuro-Symbolic Log Analysis Navigation: [[wiki/entities/Log-Insight|Log-Insight]] | [[Drain]] | [[Huawei]] | [[AIOps]] | [[LLMによる根本原因分析]] | [[ログベース障害診断]] | [[ログ解析]] | [[インシデント管理]] ## 完全な要約(Abstract 翻訳) 大規模マイクロサービスシステムにおける本番インシデントの診断は、サイトリライアビリティエンジニア(SRE)にとって労働集約的であり時間的制約が極めて厳しい。筆者らの本番環境におけるわずか30分間のインシデント時間窓であっても、相互依存する多数のサービス全体で200万行を超えるログ行（約12億文字、筆者らのエンタープライズLLM APIにおける1リクエストあたり46,000文字の制限枠の約26,000倍）が生成される可能性があり、直接的なLLMベースの根本原因分析(Root Cause Analysis: RCA)は実行不可能である。既存手法はいずれも課題を残している。テンプレートベースのパーサはデータ量を圧縮するものの意味的な異常推論を行えず、深層学習ベースの異常検知器はブラックボックスな2値シグナルを出力するにとどまり、LLMベースのパイプラインは生テレメトリに対するコンテキスト超過やドメイン固有の幻覚(ハルシネーション)に苦しんでいる。 本論文では、Huaweiの本番環境に配備された自動インシデント診断システムであるLog-Insightを提案する。中核となる設計原則は、SREの手動トリアージワークフローの自動化である。シンボリック処理ステージが、熟練したSREが実行する構造化された調査（サンプリング、スキーマ理解、パターンクラスタリング、統計的異常ランキング）を再現し、LLMには順位付けされた仮説レポートへと統合するためのコンパクトで事前ランキング済みの証拠調書(evidence dossier)のみを渡す。6段階のパイプライン（2パスサンプリング、スキーマ推論とメモリ、Drain3パターンクラスタリング、2層エントロピー誘導圧縮、対比的歪み分析、生成的統合）により、統計的に有意な障害シグナルを保持しながら、数百万件の生イベントを1,000〜7,000倍に圧縮する。 SREが検証した正解ラベルを持つ11件の過去の本番インシデント（計110回の試行）での評価において、Log-InsightはMRR = 0.790を達成し、90%以上の実行で上位3位以内の仮説の中に正解の根本原因を1分未満のエンドツーエンド遅延で返却した。また、2つの体系的故障モード、2つの能動的緩和策、および4つの今後の研究課題を報告する。正確なログテンプレートと歪み統計を列挙するForensic Evidence節は、運用担当者から主要な導入定着要因として一貫して認識され、システムの認識上の役割を不透明な神託から調査支援アシスタントへと転換させた。 --- ## 背景と動機 大規模マイクロサービスアーキテクチャにおいて、障害調査における最大のボトルネックはテレメトリの爆発的増加である。分散システム障害の約84%はログ中にトリガーイベントが存在すると報告されているものの、30分間のインシデント窓で200万行（12億文字）に達するログを生のままLLMに入力することは、コンテキスト長制限（Huawei社内APIでは46k文字）およびAPIコストの観点から完全に不可能である。 従来のAIOpsアプローチには以下の断絶が存在した: 1. **テンプレートパーサ(Drain, Spell等)**: 構文的な圧縮は行うが、なぜそのクラスタが異常なのかの意味的解釈を行えない。 2. **深層学習異常検知(DeepLog, LogAnomaly等)**: 2値フラグや再構成誤差を出力するブラックボックスであり、SREが介入するための診断的文脈が不足する。 3. **単純なLLM直接入力・ナイーブRAG**: トークン窓の溢れ、コンテキスト中央部の情報見落とし（Lost in the Middle現象）、ドメイン特有の異常に対する幻覚が発生する。 これに対しLog-Insightは、高負荷な生ログ処理を決定論的・統計的な「シンボリック層」で担い、集約・構造化された証拠調書（Forensic Case File）の推論・文章化のみを「ニューラル層（汎用LLM）」に委ねる**ニューロシンボリック(Neuro-Symbolic)アーキテクチャ**を採用した。 --- ## 提案手法: Log-Insight アーキテクチャ Log-Insightのパイプラインは、以下の6つのステージから構成される。 **Figure 1: Log-Insight システムアーキテクチャ** ![[_attachments/arxiv-2607.08529/fig01-architecture.png]] (Figure 1. Log-Insightの6段階アーキテクチャ。ClickHouseおよびSQLiteからの生ログ・メタデータに対し、シンボリックステージ(Stages 1〜5)がインデックス化、2層エントロピー圧縮、対比的歪み分析を実行。生成統合ステージ(Stage 6)のコンテキストオーケストレータが46k文字の制限内で証拠を優先配置し、汎用LLMが構造化RCAレポートを出力する。) ### 1. Stage 1: 2パスサンプリング (Two-Pass Intelligent Log Sampling) ClickHouse上の数百万行の生ログに対し、均一ランダムサンプリングではなく時間的・状態的に有意なログを抽出する2段階サンプリングを実施する。第1パスで全体の時間分布とエラー兆候をシードサンプリング(10^4行規模)し、第2パスでエラー集中時間帯や特定サービスに焦点を当てて重点収集する。 ### 2. Stages 2–3: 知識検索とスキーマメモリ (Schema Inference & Memory, Vector KB) 対象ログ空間に対応するドメインルールをベクトル知識ベース(Vector KB)から取得する（例: `flag='T'` は成功、`return_code='990000'` はデータベースタイムアウト）。このルールは後続の統計分析より優先される。さらに、多種多様なログ形式（最大398列のワイドテーブル）に対して Few-shot スキーマ推論を行い、エラーコード列やログレベル列を標準化されたForensic Schemaに射影する。 ### 3. Stage 4: 2層エントロピー誘導圧縮 (Two-Layer Entropy-Guided Compression) シャノンエントロピー $H(C) = - \sum_{v} P(v) \log_2 P(v)$ を用いて、情報理論的に不要な高エントロピー文字列を削減する。 - **Layer 1 (列レベル圧縮)**: ユニーク値数 $|V_C|$ および全行数に対する比率に基づき、エントロピーの低い列（例: `return_code` $H=1.56$ bits）はカテゴリ列挙として保持し、エントロピーの高い列（例: ランダムな `trace_id` $H=9.96$ bits）はユニーク性スコアと代表値1件に抽象化する。 - **Layer 2 (テンプレート内パラメータレベル圧縮)**: [[Drain]]3クラスタリング後のテンプレート内可変スロット $s_j$ について、定数(CONST)、数値(NUM)、列挙(ENUM, $|V_{s_j}| < 15$)、識別子(ID)に分類して抽象化する。 ### 4. Stage 5: 対比的歪み分析 (Contrastive Skew Analysis) 確定した成功ログ集合とエラーログ集合の間で、各カテゴリ値 $v$ の出現確率の比率を評価する。 $ \text{Hint}(v, C) = \mathbf{1}\left( P(v \mid \text{Err}) > 0.01 \land \frac{P(v \mid \text{Err})}{P(v \mid \text{Succ}) + \varepsilon} > 3.0 \right) $ この基準を満たすものを**Critical Hint**として抽出し、正確な出現割合（例: `hostAddr='10.140.111.13'` がエラーログの15.3%に現れ成功ログでは0%）をそのままプロンプトに注入する。 ### 5. Stage 6: オーケストレーションと生成的統合 (Generative Synthesis) 46k文字のAPI上限を厳格に守るため、コンテキストオーケストレータは以下の優先順位（Lost in the Middle回避のため最重要シグナルを先頭に配置）でForensic Case Fileを構築する: 1. KB正解ルール（成功/失敗の定義） 2. 正確な確率値を伴うランク付けされたCritical Hints 3. 圧縮済みログテンプレート（上位30件まで） 4. エラータイムライン（10秒〜5分解像度で再サンプリング） LLMには「提示された統計的ヒントとログテンプレートの意味内容を相関づけるシニアSRE」としての役割のみを与え、新しい事実の捏造を禁止する。 #### パイプライン実行トレース例 (Table 1) **Table 1: 代表的な1,000ログのインシデントにおけるパイプライン変換トレース** (Table 1. 代表的な障害事例における各ステージの内部データ変換。生JSONからエントロピー抽象化、歪みヒント抽出を経て最終LLM診断に至る。) | ステージ | 変換内容とエンジン出力 | |---|---| | 1. Raw Input | `{"timestamp":"2026-01-14T03:22:11Z", "flag":"F", "return_code":"990000", "hostAddr":"10.140.111.13"}` | | 2–3. Schema & KB | SREルール適用: `flag='F'` ⇒ failure; `return_code='990000'` ⇒ "Database Timeout". | | 4. Entropy | `timestamp` ($H=9.96$ bits) → 抽象化(ID)。`return_code` ($H=1.56$ bits) → ENUM保持。`Pos0=NUM(0.1/0.1/0.2) \| Pos1=CONST('tm-webcast')`. | | 5. Skew | Hint 1: `hostAddr='10.140.111.13'`: 15.3% errors, 0% successes. Hint 2: `clientVersion='12.11.30.303'`: 26.5% errors, 0% successes. | | 6. LLM Output | "Systemic failure on host range 10.140.111.13–20; version 12.11.30.303 responsible for 26.5% of errors." | --- ## 実験と評価 ### 実験設定 - **実環境**: Huawei本番環境のClickHouseテレメトリストア。SLAは60秒以内、LLM API枠は46,000文字。汎用エンタープライズLLM（CPU推論インフラ）を使用。 - **データセット**: 11の独立したログ空間（162行〜354万行、26列〜398列）における11件の過去インシデント。SREチームによる検証済み正解ラベル付き。 - **評価指標**: Mean Reciprocal Rank (MRR)。各ログ空間で10回実行（計110回試行）。 ### 主な結果 (Table 2) **Table 2: ログ空間ごとのMRR結果 (10回試行の平均)** (Table 2. 11のログ空間におけるMRR、平均ランク、未検出数、処理時間。行数は最大354万行、列数は最大398列。) | ログ空間 | ステータス | MRR (± SD) | 平均ランク | 未検出(回) | 処理時間 (s) | 行数 (Rows) | 列数 (Cols) | |---|---|---|---|---|---|---|---| | space_01 | Pass | 0.883 ± 0.249 | 1.30 | 0 | 22.4 | 1,325 | 98 | | space_02 | Pass | 0.700 ± 0.422 | 1.25 | 2 | 19.8 | 1,495 | 398 | | space_03 | Mix | 0.800 ± 0.258 | 1.40 | 0 | 31.2 | 500 | 98 | | space_04 | Mix | 0.758 ± 0.320 | 1.70 | 0 | 24.7 | 452 | 98 | | space_05 | Partial | 0.567 ± 0.335 | 1.89 | 1 | 38.5 | 1,000 | 98 | | space_06 | Mix | 0.758 ± 0.320 | 1.70 | 0 | 21.3 | 10,000 | 98 | | space_07 | Mix | 0.708 ± 0.317 | 1.80 | 0 | 27.6 | 100,000 | 98 | | space_08 | Pass | 0.950 ± 0.158 | 1.10 | 0 | 23.1 | 189 | 26 | | space_09 | Pass | 0.733 ± 0.370 | 1.44 | 1 | 35.8 | 162 | 26 | | space_010 | Pass | 0.883 ± 0.249 | 1.30 | 0 | 26.4 | 189 | 26 | | space_11 | Pass | 0.950 ± 0.158 | 1.10 | 0 | 31.0 | 3,540,000 | 29 | | **全体集計** | — | **0.790 ± 0.287** | **1.45** | **4 / 110** | **27.1** | — | — | 全体の平均MRRは0.790に達し、平均遅延は27.1秒とSLA（60秒）を大幅に下回った。正解ラベルが上位3位以内に含まれた割合は90%を超え、完全に見失った試行は110回中わずか4回であった。 ### ベースライン比較 (Table 3) **Table 3: ベースライン手法との比較 (3つの代表ログ空間における各10回試行平均)** (Table 3. ランダムサンプリング(RS)、Drain+テンプレートサンプリング(DTS)、Log-Insightの精度比較。) | 手法 / 対象空間 | ROUGE-L (%) | METEOR (%) | 意味的類似度 (%) | MRR | |---|---|---|---|---| | **Random Sampling (RS)** | | | | | | space_01 | 16.97 ± 1.36 | 21.90 ± 4.19 | 87.17 ± 0.47 | 0.80 | | space_07 | 3.47 ± 1.05 | 8.77 ± 1.48 | 81.78 ± 0.44 | 0.30 | | space_11 | 3.62 ± 2.75 | 7.66 ± 2.97 | 79.08 ± 0.14 | 0.25 | | *平均* | 8.02 | 12.78 | 82.68 | 0.45 | | **Drain + Template Sampling (DTS)** | | | | | | space_01 | 16.37 ± 0.67 | 22.25 ± 4.85 | 86.48 ± 1.05 | 0.80 | | space_07 | 4.29 ± 0.85 | 7.90 ± 0.27 | 81.75 ± 0.17 | 0.50 | | space_11 | 5.26 ± 1.12 | 8.56 ± 0.08 | 79.75 ± 0.27 | 0.40 | | *平均* | 8.64 | 12.90 | 82.66 | 0.56 | | **Log-Insight (提案手法)** | | | | | | space_01 | 28.83 ± 1.10 | 34.36 ± 0.29 | 87.98 ± 0.22 | **0.88** | | space_07 | 15.99 ± 0.47 | 27.35 ± 1.48 | 86.00 ± 0.28 | **0.70** | | space_11 | 9.06 ± 0.84 | 20.75 ± 1.67 | 81.93 ± 0.14 | **0.95** | | *平均* | **17.96** | **27.49** | **85.30** | **0.84** | 生ログをそのままサンプリングするRSや、統計スコアなしでDrainテンプレートのみを入れるDTSと比較して、Log-Insightは特にデータ規模の大きい空間（space_07: 10万行, space_11: 354万行）で圧倒的なMRR改善（space_11で0.25/0.40 → 0.95）を示した。 ### コンテキスト圧縮効果 (Figure 2) **Figure 2: 生ログ行数に対する消費文字数の推移** ![[_attachments/arxiv-2607.08529/fig02-character-consumption.png]] (Figure 2. 生ログを直接注入した場合、わずか50〜80行で46,000文字のAPI上限に到達する。対照的にLog-Insightは、生ログが300万行に達しても圧縮後コンテキスト長を7,000〜20,000文字の安定した範囲に抑制（1,000〜7,000倍の圧縮率）し、API上限内に確実に収める。) --- ## 考察と運用知見 ### 故障モード分析と緩和策 本番評価を通じて以下の2つの故障モードが判明した: 1. **コンテキスト脱落 (Context omission)**: 列数が極めて多いスキーマ(space_02: 398列)で、メタデータの列挙だけで文字数枠を消費し、対比的歪みレポートが途中で切り詰められ未検出が発生した。緩和策として、スキーマ幅に応じた文字配分調整を実施。 2. **物語優先の転倒 (Narrative override)**: Critical Hintとして正しい原因シグナルが注入されているにもかかわらず、LLM自身の事前学習知識にある「より一般的・魅力的な因果関係」に引っ張られ、ドメイン固有エラーコードの優先順位を下げてしまう現象。緩和策として、(1) JSON形式による証拠・主張マッピングを強制する構造化出力、(2) 注入された統計に厳密に従っているかを検証する批判エージェント(Critic-Agent)パスを導入中。 ### SREの信頼獲得と「Excellence Paradox」の打破 Shahediらが指摘した「高度な技術であっても操作性や信頼性と衝突すると現場導入が阻害される（Excellence Paradox）」に対し、Log-Insightは**Forensic Evidence節**の明示によって解決を図った。 - 各仮説の根拠となった具体的なログテンプレート、エラーログ中の出現率(%)、成功ログ中の出現率(%)、歪み比率を包み隠さず記載する。 - SREはレポートを読んだ後、ClickHouse上でそのSQL条件を即座に叩いて裏付けを取ることができる。この検証可能性が、ブラックボックスな「神託(oracle)」ではなく「信頼できる調査助手(investive assistant)」としての受容を生んだ。 --- ## 関連研究との位置づけ - **テンプレートパーサ**: [[Drain]] や Spell はログ構造化の基礎技術であるが、単体では異常の因果関係を説明できない。Log-InsightはDrain3を第1段階のクラスタリングとして組み込み、その上にエントロピー圧縮と対比的歪み分析を重ねた。 - **LLMベースRCA**: [[LLMによる根本原因分析]] において、生ログの直接入力はコンテキスト窓の制約と幻覚に直面する。Log-Insightはシンボリック処理によって決定論的に証拠を絞り込み、LLMには要約と自然言語化のみを担わせるハイブリッドアプローチの有効性を実証した。 --- ## 出典 - Garcia-Hernandez, C., Abdali, A., Wu, G., Wang, M., Shen, F., Pang, Z., & Zhang, Y. (2026). Log-Insight: Automating Microservice Incident Diagnosis via Neuro-Symbolic Log Analysis. In *Proceedings of the 41st IEEE/ACM International Conference on Automated Software Engineering (ASE '26)*. arXiv:2607.08529 [cs.IR].