# ログ解析 ## 定義 ログ解析(log analysis)は、システムの実行時イベントを時系列に記録したログから、障害の検知・箇所特定・根本原因分析に必要な情報を抽出する取り組み。ログは分散システムで最も広く使われる重要な診断資源で、ある実証研究では分散システムの障害の 93% がログに現れ、障害の 90% 近くの診断にログが寄与すると報告される([[@2025__ASE__LogPilot - Intent-aware and Scalable Alert Diagnosis for Large-scale Online Service Systems]] が引用する Yuan+ 2020)。生ログは非構造で大量なため、何らかの構造化と絞り込みが解析の前提になる。[[AIOps]] の 4-level taxonomy では Level 1(検知)〜Level 3(RCA)にまたがるモダリティ特化の手段で、メトリクス・トレースと並ぶオブザーバビリティの一次データである。 研究領域としてのログ解析は、単一タスクでなく**エンドツーエンドのパイプライン全体**として捉えるのが現在の到達点である。[[LLM4Log]] は LLM ベースログ解析を [[ログ生成]](最上流の observability 設計)→[[ログパース]](生ログを logging path・テンプレートから構造化ログイベントへ変換する前処理)→表現学習→下流タスク([[異常検知]]・[[障害予測]]・[[根本原因分析]]・ログ要約)の連なりとして体系化する(Fig.1)。本 concept が当初の中心に据えてきた「障害診断」——一般に **log scoping**(billions のログから関連サブセットへ絞る)と **log-based RCA**(絞ったログから根本原因を推論)の 2 段からなる([[@2025__ASE__LogPilot - Intent-aware and Scalable Alert Diagnosis for Large-scale Online Service Systems]] §IX, [[A Survey of AIOps in the Era of Large Language Models]] §4.2)——は、このパイプラインの下流側 1 段に位置づく。なお [[@2025__ASE__LogPilot - Intent-aware and Scalable Alert Diagnosis for Large-scale Online Service Systems]] が前処理に使う Drain は固定深度木によるオンライン parser で、[[Michael R. Lyu]] グループの基盤手法である。 ## 子概念 - [[ログパース]] - [[ログ生成]] - [[知識グラフ]] ## 横断的知見 ### パイプライン全体としての地図と共通設計原理 - **「ログ解析」は単一タスクでなく、ログ生成→パース→表現→下流診断のパイプライン全体だとフィールドの地図が確定する**: 本 concept は当初「scoping + RCA」(診断)を中心に育ったが、[[LLM4Log]] は LLM ベースログ解析を [[ログ生成]]→[[ログパース]]→表現学習→下流タスク([[異常検知]]・[[障害予測]]・[[根本原因分析]]・ログ要約)のエンドツーエンドのパイプラインとして体系化し(Fig.1)、2020–2025 の 145 論文を統一タスク駆動タクソノミーで地図化する。これは [[A Survey of AIOps in the Era of Large Language Models]] が AIOps 全工程を「ログは複数モダリティの 1 つ」として広く俯瞰したのと相補的で、LLM4Log は**ログを中心証拠源に固定**してパイプライン全段を覆う。本 wiki の LogPilot/MonitorAssistant/L4 が攻めていた「診断」は、この地図では下流タスク 1 段に位置づく——ログ解析研究の全体像が、診断中心の見方からパイプライン 7 タスクの見方へ拡張された。(Source: [[LLM4Log]], [[A Survey of AIOps in the Era of Large Language Models]]) - **「情報を絞ってから LLM を選択的に呼ぶ階層設計」がパイプライン全段で反復する、とサーベイが横断的に定式化する**: 本 wiki の [[LogPilot]] は request クラスタリングで LLM 呼び出しを 98.71% 削減し、[[OpenRCA]] は生テレメトリをコンテキストに載せずコード実行で捌いた——個別論文で観測してきたこの骨格を、[[LLM4Log]] は全タスク共通の設計原理として明言する。すなわち成功システムは無制約な end-to-end 生成に頼らず、前処理・検索・フィルタ・グルーピング・軽量スコアリングで探索空間を絞ってから、強い LLM を意味解釈・説明・レポートに選択的に呼ぶ(§7.1)。[[ログパース]] の cache/grouping(LILAC/LogParser-LLM)、[[異常検知]] の小モデルによる候補窓の絞り込み + LLM 説明、[[根本原因分析]] の retrieval-then-generate がすべて同じパターン。**「LLM は大きなパイプライン内の高価値な推論・説明コンポーネントであり、全段の置換ではない」**がサーベイの中核結論で、本 wiki が個別ソースで積み上げた観察の上位一般化に当たる。(Source: [[LLM4Log]], [[@2025__ASE__LogPilot - Intent-aware and Scalable Alert Diagnosis for Large-scale Online Service Systems]], [[@2025__ICLR__OpenRCA - Can Large Language Models Locate the Root Cause of Software Failures]]) ### 下流の障害診断段の構造 - **ログ診断の「scoping + RCA」2 段構造が一次論文とサーベイで一致する**: [[@2025__ASE__LogPilot - Intent-aware and Scalable Alert Diagnosis for Large-scale Online Service Systems]] は §IX でログ診断を log scoping(関連サブセットへの絞り込み)と log-based RCA(根本原因の推論)の 2 段と整理し、自身の 3 フェーズ(intent-aware scoping → request-centric processing → clustering-based diagnosis)をこの構造に対応づける。[[A Survey of AIOps in the Era of Large Language Models]] も独立に同じ 2 段でログ診断を地図化する(§4.2)。一次論文(LogPilot)とフィールドの地図(サーベイ)が同じ骨格を裏付け、下流診断段の研究はこの 2 段のどちらを攻めるかで整理できる。(Source: [[@2025__ASE__LogPilot - Intent-aware and Scalable Alert Diagnosis for Large-scale Online Service Systems]], [[A Survey of AIOps in the Era of Large Language Models]]) - **「情報を取りすぎる病理」がログでも前景化し、絞り込みが診断の骨格になる**: [[@2025__ASE__LogPilot - Intent-aware and Scalable Alert Diagnosis for Large-scale Online Service Systems]] は「ログ volume が LLM の context window を超える」「インターリーブされ断片化したイベントが推論力を損なう」を中心課題に挙げ、request をクラスタリングして代表だけを LLM に渡すことで LLM 呼び出しを平均 198.65 request → 最大 13(平均 2.56)に **98.71% 削減**する。これはメトリクス側で [[MetricSifter]] が無関係メトリクス $M_C$ を削る [[特徴量削減]]、LLM エージェントが get_metrics/get_traces を雑に消費して性能を落とす病理([[AIOpsLab]] §3.6・[[Bits AI SRE]] の初期版、[[根本原因分析]] に詳述)と同根。**「情報を絞ってから推論する」骨格が、メトリクス・テレメトリ・ログというモダリティを越えて通底する**——ログ解析はこの骨格を「request 単位のクラスタリングで代表抽出」という具体形で実装した一例で、前項のパイプライン全段の階層設計原理を診断段で体現したものでもある。(Source: [[@2025__ASE__LogPilot - Intent-aware and Scalable Alert Diagnosis for Large-scale Online Service Systems]], [[@2024__IEEE Access__MetricSifter - Feature Reduction of Multivariate Time Series Data for Efficient Fault Localization in Cloud Applications]]) - **産業側は「アラート/インシデントの文脈でシグナルを絞る」点で一致する**: [[@2025__ASE__LogPilot - Intent-aware and Scalable Alert Diagnosis for Large-scale Online Service Systems]] は keyword search や anomaly detection に基づくログ scoping を「alert-agnostic でアラート固有の文脈を欠く」と批判し、PromQL アラート定義の意味的意図で causally related logs を絞る intent-aware scoping を据える。[[MonitorAssistant]]([[@2024__ESEC-FSE__MonitorAssistant - Simplifying Cloud Service Monitoring via Large Language Models]])も「実用的異常 = 統計的逸脱 **かつ** インシデントで裏付けられた逸脱」と定義し、純粋な統計的外れ値を業務上無関係として退ける。**両者は産業側から「文脈なしのシグナル検出は不十分」と主張し、アラート定義・インシデント履歴という文脈をシグナル選別に組み込む**——検知精度の向上([[異常検知]] の主流路線)とは別の、「何を見るべきか」を文脈で決める産業の発想([[根本原因分析]] の「RCA の起点」議論とも接続)。(Source: [[@2025__ASE__LogPilot - Intent-aware and Scalable Alert Diagnosis for Large-scale Online Service Systems]], [[@2024__ESEC-FSE__MonitorAssistant - Simplifying Cloud Service Monitoring via Large Language Models]]) - **「ログ単一モダリティの深掘り」対「マルチモーダル横断」という設計分岐**: [[@2025__ASE__LogPilot - Intent-aware and Scalable Alert Diagnosis for Large-scale Online Service Systems]] はログ単一モダリティに絞り、その代わり request-centric な構造化(spatiotemporal log chain + クラスタリング)で深掘りする。一方 [[Bits AI SRE]]([[@2026__Datadog__Building Bits AI SRE - Autonomous Incident Investigation Agent]])はログ・トレース・メトリクスを横断して仮説駆動で診断する。LogPilot 自身も §VIII でメトリクス・トレース・oncall record はサイロ化しており融合が今後課題だと明言する。**モダリティを絞って構造で深掘りする設計と、複数モダリティを横断融合する設計の対比**——前者は単一モダリティでの組織化(scoping・chain・clustering)に投資し、後者はモダリティ間の相関に投資する。(Source: [[@2025__ASE__LogPilot - Intent-aware and Scalable Alert Diagnosis for Large-scale Online Service Systems]], [[@2026__Datadog__Building Bits AI SRE - Autonomous Incident Investigation Agent]]) - **ログ専門エージェントは「チャンク化 + 根拠照合」で幻覚を抑える方向へ進む**: [[LogPilot]] は request-centric chain とクラスタリングで代表 request を選び、[[RCAgent]] はログ行の埋め込み類似度と文書距離減衰に基づく Louvain 分割で長大ログをチャンク化し、専門エージェントの証拠がチャンクに fuzzy match しない場合は分析を捨てる。両者は実装は違うが、ログをそのまま LLM に渡さず、構造化された小単位に分け、出力を原ログ根拠に戻すという設計を共有する。(Source: [[@2025__ASE__LogPilot - Intent-aware and Scalable Alert Diagnosis for Large-scale Online Service Systems]], [[@2024__CIKM__RCAgent - Cloud Root Cause Analysis by Autonomous Agents with Tool-Augmented Large Language Models]]) - **[[知識グラフ]] でログの複数フィールドを統合する設計は、コンテンツのみを扱う LLM ベースと相補的な軸を形成する**: [[@2023__TSC__LogKG - Log Failure Diagnosis through Knowledge Graph|LogKG]]([[@2023__TSC__LogKG - Log Failure Diagnosis through Knowledge Graph]], TSC 2023)は、タイムスタンプ・ログレベル・IP・コンポーネント・タスクID という構造化フィールドとコンテンツを単一の知識グラフに統合し、RotatE による知識グラフ埋め込み(KGE)と障害特化ログ表現(FOLR)の組み合わせで障害診断を行う。LLM ベースのログ解析手法(LogPilot・RCAgent 等)がテキストの意味理解に強みを持つのに対し、LogKG は構造化フィールド間の関係グラフを明示的にモデル化するアプローチで、CMCC(実 ISP 環境)で精度 1.0・GAIA(マイクロサービスシミュレーション)で精度 0.98 を達成し、Guangdong Mobile の本番環境に 5 か月展開して手動障害緩和時間を平均 20 分以上短縮した。ログ解析のパイプライン全体を見ると、LLM4Log サーベイが指摘する「LLM は高価値な推論・説明コンポーネント」という役割に対し、KGE はフィールド間の構造的な依存関係をコンパクトに学習する役割として並立しうる。(Source: [[@2023__TSC__LogKG - Log Failure Diagnosis through Knowledge Graph]]) ### 統計/ルール・機械学習・深層学習という原理軸のサーベイと、パイプライン軸・タスク軸との関係 - **原理(統計・ルール/機械学習/深層学習)で3分類し、各分類の内部をさらに手法の型で下位分類するタクソノミーが、パイプライン軸([[LLM4Log]])やscoping+RCAの2段構造(LogPilot)と直交する第3の切り口として現れた**: [[@2024__arXiv__Failure Diagnosis in Microservice Systems - A Comprehensive Survey and Analysis - Chapter 4.1 Failure Diagnosis Through Logs]] は、ログベース障害診断技術(LOGAN・LogCluster・SwissLog・LogKG等17手法)を「統計/ルール→検索・相関分析・スペクトラム」「機械学習→クラスタリング・分類・相関分析・グラフ分析」「深層学習→教師あり・教師なし・両方」という原理ベースの3階層タクソノミーで整理する(Fig.4)。これは LLM4Log の「生成→パース→表現→下流タスク」というパイプライン軸、LogPilot の「scoping→RCA」という処理段階軸とは異なる第3の軸——**どのアルゴリズム原理を使うか**——であり、同じログ診断という下流タスクを3通りの直交する視点(パイプライン段階・処理フェーズ・アルゴリズム原理)で地図化できることを示す。(Source: [[@2024__arXiv__Failure Diagnosis in Microservice Systems - A Comprehensive Survey and Analysis - Chapter 4.1 Failure Diagnosis Through Logs]], [[LLM4Log]], [[@2025__ASE__LogPilot - Intent-aware and Scalable Alert Diagnosis for Large-scale Online Service Systems]]) - **診断粒度は、統計/ML時代(2012-2023)のコンポーネントレベル集中から、LLM時代のインスタンス/リクエストレベルへ拡張している**: 本 concept が扱う統計/ML/DL手法17件のうち根本原因箇所特定はログ行[78,79,84,85,88]・イベント[82,86,87]・システム問題[83]といったコンポーネントレベルに集中し、インスタンスレベルを対象とするのはCloud'19(2019, word2vec+教師ありクラシファイア)のみである。これに対し、本wikiのLLM時代のシステム(LogPilotのリクエスト単位クラスタリング、L4のLLM訓練ジョブ単位の障害診断)はより細かい粒度(リクエスト・ジョブインスタンス)を標準的に扱う。**粒度の細分化は深層学習・LLMの導入と並行して進んだ**という仮説を、原理ベースタクソノミーの粒度分布(サーベイ)とLLM時代システムの粒度(一次ソース)を突き合わせることで裏付けられる。(Source: [[@2024__arXiv__Failure Diagnosis in Microservice Systems - A Comprehensive Survey and Analysis - Chapter 4.1 Failure Diagnosis Through Logs]], [[@2025__ASE__LogPilot - Intent-aware and Scalable Alert Diagnosis for Large-scale Online Service Systems]], [[@2025__ESEC-FSE__L4 - Diagnosing Large-scale LLM Training Failures via Automated Log Analysis]]) - **「ログ+ユーザ知覚メトリクス」の組み合わせは2012年のDISTALYZERまで遡り、本wikiが観察してきたマルチモーダル統合の系譜を10年以上さかのぼって延長する**: 本 concept は [[Bits AI SRE]] のログ・トレース・メトリクス横断診断を「マルチモーダル統合」の代表例として扱ってきたが、[[@2024__arXiv__Failure Diagnosis in Microservice Systems - A Comprehensive Survey and Analysis - Chapter 4.1 Failure Diagnosis Through Logs]] が整理するLog3C(2018、ログ系列クラスタリングとユーザ知覚メトリクスの相関で性能劣化への影響を判定)とDISTALYZER(2012、ログ由来特徴とユーザ知覚メトリクスを結ぶ依存ネットワークをアテンションで絞り込む)は、いずれもログ単一モダリティに閉じず前段でメトリクスと突き合わせる設計を採る。マルチモーダル統合という発想自体は、LLM時代のBits AI SREを待たずログ解析研究の初期(2012年)から存在していたことになる。(Source: [[@2024__arXiv__Failure Diagnosis in Microservice Systems - A Comprehensive Survey and Analysis - Chapter 4.1 Failure Diagnosis Through Logs]], [[@2026__Datadog__Building Bits AI SRE - Autonomous Incident Investigation Agent]]) ### ネットワーク syslog への因果推論（ドメイン特化の前処理設計） - **ネットワーク syslog はクラウドサービスログより桁違いにスパースで、この差が前処理設計の全体を変える**: [[@2018__TNSM__Mining Causality of Network Events in Log Data]] は PC アルゴリズム + G-square 検定によるネットワーク syslog の因果マイニングを提案する。クラウドサービスログ（アクセスログ等の大量連続データ）ではデータが十分大きく Fisher-Z（正規分布仮定の Pearson 相関ベース検定）が成立するが、ネットワーク syslog は離散的・スパースなため Fisher-Z の正規分布前提が崩れ偽陽性が多発し 7% タイムアウトが発生した。G-square（二値時系列 + クロスエントロピー情報理論）はこの制約を回避し、低偽陽性・実用的処理時間を実現した。**「データの疎密がどの条件付き独立性検定を使えるかを決める」**というログ解析の設計原則が、ネットワーク管理ドメインで定量化された初期の論文の一つ。(Source: [[@2018__TNSM__Mining Causality of Network Events in Log Data]]) - **周期的イベントの除去はネットワーク syslog の因果推論で 93% を占める前処理課題で、フーリエ + 線形回帰の組み合わせが互いの欠点を補完する**: 全メッセージの 93% が cron・NTP 同期・定期監視等の周期的イベントで、これが PC アルゴリズムの偽陽性を大量に生む。フーリエ解析（等間隔ピーク検出）は短い/非固定間隔の周期を見逃し、線形回帰解析（累積時系列の線形増加判定）はその補完として機能する。どちらも**周期コンポーネントを除去しつつアウトライヤ（障害時の例外的出現）を保持する**設計で、残り 7% のみが PC アルゴリズムの入力となる。この「不要な定常挙動を除去して障害シグナルを浮かび上がらせる」前処理は、本 wiki の [[LogPilot]] の request クラスタリング・[[LogCleaner]] のイベント 3 類型と同じ「情報を絞ってから推論する」骨格のネットワーク管理版といえる。(Source: [[@2018__TNSM__Mining Causality of Network Events in Log Data]]) - **後処理の「頻出エッジ除去（上位 5%）」は、「何がいつも起きているか」ではなく「何がまれに起きているか」を可視化する本質的な選択である**: PC アルゴリズムは因果関係を出力するが重要度を付与しない。全 843 種のエッジのうち上位 42 種（5%）が全出現の 85% を占め、そのほとんどは定常のコマンドと ACK の因果（管理ログイン → UI 起動等）だとわかった。これを除去することでエッジ数は 16,196 → 2,438（5.3 エッジ/日）に絞られ、演算者が注目すべき「通常でない因果関係」が浮かび上がる。**「ログの長尾分布に由来する常在エッジをフィルタして稀なシグナルを抽出する」**という設計は、ログ解析の一般原則として再利用可能。(Source: [[@2018__TNSM__Mining Causality of Network Events in Log Data]]) ### ネットワークOSの運用ログ:自由記述syslogと構造化recordログの二層設計 - **ネットワーク機器のログ診断には「free-text syslogを後から解析する」路線と「専用の構造化recordログを最初から書く」路線の2つがあり、[[@2018__TNSM__Mining Causality of Network Events in Log Data]] と [[@2025__Gihyo__実践SONiC入門 - Chapter 11 SONiCのトラブルシューティング]] はそれぞれ異なる路線の具体例を提供する**: Kobayashi+ の因果マイニングは、SINET4 が既に持つ free-text syslog(離散的・スパースでFisher-Zが破綻する)を後から統計的に解析する路線である。一方 SONiC は同じ「ネットワーク機器の状態変化を追う」問題に対し、通常の syslog(NOTICE 既定、`swssloglevel` で INFO/DEBUG に変更可能な自由記述ログ)とは別に、APPL_DB の変更を記録する `swss.rec` と SAI 呼び出しを記録する `sairedis.rec` という、テーブル名・キー・操作コード(sairedis.rec は c/g/r/s の1文字コード)を持つ構造化レコードログを最初から書き出す設計を取る。**後解析で構造を復元する(パース・因果推論)か、書き込み時点で構造を確定させる(record化)かは、ログ設計の分岐点である**。前者はログ生成側を変更できない環境(汎用 syslog しかない機器・過去ログ)向けの解、後者はログ生成そのものを設計できるアプリケーション(SONiC の swss/syncd)向けの解であり、[[ログ生成]] の設計判断が下流の解析コストをどれだけ左右するかを対比する具体例になる。(Source: [[@2025__Gihyo__実践SONiC入門 - Chapter 11 SONiCのトラブルシューティング]] §11.2-11.3, [[@2018__TNSM__Mining Causality of Network Events in Log Data]]) - **SONiC の grep ベースのキーワード絞り込みは、本 concept が一般化した「情報を絞ってから推論する」骨格の、自動化以前・人手による最小実装である**: `swss.rec`/`sairedis.rec` は通常動作時でも大量に記録され、本章は「MAC/IP アドレス・テーブル名・`SAI_STATUS_FAILURE` といったキーワードで検索しながらデバッグする」ことを推奨する。これは [[LogPilot]] の request クラスタリングや [[LogCleaner]] の情報理論的イベント選別が自動化している「絞り込んでから読む」原理を、人間がドメイン知識(このキーワードが失敗を示す、というエンジニアの経験則)で手動実行した形であり、産業のログ基盤が自動選別を導入する以前の段階でも同じ設計原理が有効であることを示す。(Source: [[@2025__Gihyo__実践SONiC入門 - Chapter 11 SONiCのトラブルシューティング]] §11.3.1) ### ログイベント削減（入力層の前処理） - **ログ異常検知の入力イベントは大半が不要で、情報理論的選別で 70% 超を安全に除去できる**: [[@2024__ESEM__Reducing Events to Augment Log-based Anomaly Detection Models - An Empirical Study]] は 6 モデル×3 データセットの実証で、ログイベントを anti-event（ラベルと無相関でモデルを誤導）・duplicative-event（情報が重複）・key-event（相互補完的で不可欠）の 3 類型に分類し、anti/duplicative の除去でほぼ全モデルの F1 が向上することを示す。[[LogCleaner]] は TF-IDF→相互情報量→OPTICS クラスタリングの 3 段でモデル実行なしにイベントを選別し、推論速度を約 300% 向上させる。これは本 wiki の「情報を絞ってから推論する」骨格——[[LogPilot]] のリクエストクラスタリング、[[MetricSifter]] の無関係メトリクス削減——と同じ設計思想のログイベント版であり、パイプライン上流（パース直後）に位置する前処理として、下流の検知モデルの性能と効率を同時に改善する。(Source: [[@2024__ESEM__Reducing Events to Augment Log-based Anomaly Detection Models - An Empirical Study]], [[@2025__ASE__LogPilot - Intent-aware and Scalable Alert Diagnosis for Large-scale Online Service Systems]]) ### ログクラスタリングによる調査対象の圧縮(2016 年時点の産業実績) - **ログ系列クラスタリング + 知識ベース再発識別の 2 段構成が、調査必要系列数を 1〜3 桁削減しつつ再発障害への対処を自動化できる**: [[@2016__ICSE-C__Log Clustering Based Problem Identification for Online Service Systems|LogCluster]]([[@2016__ICSE-C__Log Clustering Based Problem Identification for Online Service Systems]], ICSE Companion 2016)は、IDF(逆文書頻度)と対比重み付け(本番環境のみに現れるイベントを高重みとする)を組み合わせたベクトル化 → コサイン類似度による凝集型階層クラスタリング → 代表系列の抽出 → 知識ベースとの照合(再発障害は緩和策を即返却、新規は人手確認)という 4 段フローで動作する。Microsoft の実サービス評価では、生ログ 10 百万件のうちキーワード検索が 200,119 件を要調査としたのに対し LogCluster では 40 件(55% の適合率)に削減した。**この「クラスタリングで代表を抽出し、知識を使って既知/新規を振り分ける」構造は、LogPilot の「クラスタリングで LLM 呼び出しを 98.71% 削減」と同型の設計を 2016 年時点で実装していた**。(Source: [[@2016__ICSE-C__Log Clustering Based Problem Identification for Online Service Systems]]) - **「知識ベースに蓄積して再発を識別する」パターンは 2016 年から産業規模で稼働しており、L4 の fault library・AlertGuardian の RAG 知識ベースと同型**: LogCluster が 2013 年以来 Microsoft 複数製品チームへ本番投入(Service A・Product G・Product L・Service C)し、運用を続けるほど再発確認件数が減る「蓄積型の削減効果」を示したことは、単一ソース論文レベルを超えた 4 年間の実証を提供した。ログ重大度レベルが問題診断の手がかりとして不十分(高重大度ログの 10% 未満しか実際の障害に関係せず、30% 超の障害は INFO レベルに関係)という観察は、L4 が LLM 訓練ログで確認した「3 指標(ログレベル・頻度・エラー意味)が障害ログを弁別できない」という 2025 年の知見の先行事例である。(Source: [[@2016__ICSE-C__Log Clustering Based Problem Identification for Online Service Systems]], [[@2025__ESEC-FSE__L4 - Diagnosing Large-scale LLM Training Failures via Automated Log Analysis]]) ### 障害注入テスト特有のノイズログ問題(起点: 2011 年) - **「障害注入テスト中に発生するノイズログ」は 2011 年に定量化されており、空間/時間圧縮だけでは解消できない**: Rao et al.([[@2011__SRDS__Identifying Faults in Large-Scale Distributed Systems by Filtering Noisy Error Logs]])は Alibaba Cloud 100 ノードクラスタの障害注入テスト(2,800,973 ログ)で、注入した対象障害以外にもランダムハードウェア障害・ソフトウェアバグ・設定誤り・ログ重大度誤設定という 4 種類のノイズ障害が必然的に発生し、Apriori/Decision Tree による障害特徴抽出を誤導することを定量化した。既存手法 CFC(空間/時間圧縮)は time window 500 秒で再現率が 30% まで低下する。SBF はログ発生パターンを時系列モデル化し Haar ウェーブレット変換 + DTW 類似度でノイズログを除去することで、100 秒 window で適合率 96%・再現率 94% を達成した。本 wiki の [[LogCleaner]] による anti-event 除去([[@2024__ESEM__Reducing Events to Augment Log-based Anomaly Detection Models - An Empirical Study]])や [[LogReducer]] によるカーネル層ログ削減([[@2023__ICSE__LogReducer - Identify and Reduce Log Hotspots in Kernel on the Fly]])の先駆けとして、「ノイズログを源流で除去する」設計思想の初期形態を示す。(Source: [[@2011__SRDS__Identifying Faults in Large-Scale Distributed Systems by Filtering Noisy Error Logs]]) ### ログボリューム削減（書き込み前の最上流介入） - **ログオーバーヘッドは少数テンプレートに集中し、カーネル層での書き込み抑止で最上流から削減可能である**: [[@2023__ICSE__LogReducer - Identify and Reduce Log Hotspots in Kernel on the Fly]] は WeChat（2 万超マイクロサービス、1 日 16–20 PB）のストレージ上位 20 サービスを調査し、19/20 サービスにログホットスポット（ストレージ比率 > 5% の少数テンプレート）が存在し、平均 57.86% のストレージを占有すると報告する。根本原因の 63.15% はログレベル誤設定とテストログ消し忘れという**ログ品質の問題**で、[[ログ生成]] と直結する。LogReducer は eBPF でカーネル空間の `sys_write()` をインターセプトし、2,000 ns/ログ・CPU 0.008% の極低オーバーヘッドでホットスポットをドロップする。本 wiki が積み上げてきた「情報を絞ってから推論する」骨格は診断段([[LogPilot]] の request クラスタリング)やイベント段([[LogCleaner]] の anti-event 除去)で展開してきたが、LogReducer はそれをさらに上流——**ディスクへの書き込み前**——に押し上げ、下流のすべての段（パース・異常検知・RCA）が処理すべきデータ総量を源流で削る。ログ圧縮（CLP/LogZip/Cowic 等）はストレージ削減に効くが書き込みコストとネットワーク帯域は削減できないのに対し、カーネル層フィルタはライフサイクルの 4 段すべてのコストを削減する点で相補的である。(Source: [[@2023__ICSE__LogReducer - Identify and Reduce Log Hotspots in Kernel on the Fly]]) ### ロギング配置の最適化(ログ生成前のソースコード意思決定) - **ログ配置最適化は、本 concept が整理する「ログ量削減」パイプラインの最上流——ソースコードにどこで print 文を書くか——に位置する初期の系譜である**: [[@2021__TIST__A Survey of AIOps Methods for Failure Management - Chapter 4.3 Failure Detection]] §4.3.3 がレビューする LogAdvisor(Zhu et al. [168])と Log20(Reference [163])は、いずれもログが実際に書き込まれる前の設計段階——コードスニペットのどこにログ文を置くか——を最適化する。LogAdvisor は構造的・構文的・テキスト的特徴量と情報利得から決定木でロギング要否を二値分類し、Log20 はエントロピーを情報量の指標として貪欲な動的計画法で設置箇所を決め、4種の分散システムで1リクエストあたりの print エントリ数を1.58から INFO レベルで0.08まで削減した。本ページが整理する [[ログ生成]] 概念の what-to-log 設計、および [[LogReducer]] のカーネル層書き込み抑止(eBPF での `sys_write()` インターセプト、2023年)と並べると、**ログ量制御の介入点は「コード設計時(LogAdvisor/Log20、2015・2019年)→書き込み直前(LogReducer、2023年)→パース後のイベント選別(LogCleaner)→診断時のクラスタリング(LogPilot)」という4段階のパイプラインに沿って上流から下流まで存在する**ことが分かる。LogAdvisor/Log20 はこの中で最も上流(ソースコード設計時点)の介入であり、他の3段が「既に生成されたログをどう扱うか」を問うのに対し、「そもそも生成するか」を問う点で質的に異なる。(Source: [[@2021__TIST__A Survey of AIOps Methods for Failure Management - Chapter 4.3 Failure Detection]] §4.3.3, [[@2023__ICSE__LogReducer - Identify and Reduce Log Hotspots in Kernel on the Fly]], [[@2024__ESEM__Reducing Events to Augment Log-based Anomaly Detection Models - An Empirical Study]]) - **Log20 の「情報理論をログ生成の設計指標として用いる」発想は、下流の異常検知が採る情報理論的選別(PCA/TF-IDF)と同じ道具立てを別の介入点に転用した先例である**: Notaro 2021 の同じサーベイの §4.3.1 がレビューする Xu et al. [151] は TF-IDF と PCA でログの異常度を判定する(下流の検知段)。一方 Log20 はエントロピーで「どこにログを置けば情報量が最大化されるか」を判定する(上流の生成段)。両者はともに情報理論的な尺度を道具に使うが、適用点が「生成前のソースコード」と「生成後のログストリーム」で正反対である。この対比は、情報理論的手法がログ解析パイプラインの特定の段に固有の道具ではなく、複数の介入点に転用可能な汎用的な設計原理であることを示す。(Source: [[@2021__TIST__A Survey of AIOps Methods for Failure Management - Chapter 4.3 Failure Detection]] §4.3.1, §4.3.3) ### ログ品質・評価・研究地図 - **従来のログ異常検知が依拠する 3 指標が LLM 訓練ログには通用しない**: 既存のログ異常検知(サーベイが整理する LogRobust/LogAnomaly 系)はログレベル・イベント頻度・エラー意味の 3 指標を手がかりにするが、[[@2025__ESEC-FSE__L4 - Diagnosing Large-scale LLM Training Failures via Automated Log Analysis]] では障害指示ログの 54.8% のみが error レベル、57.9% が頻度下位 25% だが 16.3% は上位 25% という分布を示し、3 指標がいずれも障害ログを安定に弁別できないことを定量化する。L4 は fault library に確認済み障害パターンを蓄積し新規ログと照合する(インシデント知識の再利用)。ログ品質そのものが下流診断の精度を左右する点で、最上流の [[ログ生成]] とも接続する。(Source: [[@2025__ESEC-FSE__L4 - Diagnosing Large-scale LLM Training Failures via Automated Log Analysis]], [[A Survey of AIOps in the Era of Large Language Models]]) - **LLM4Log の研究は「ベンチマーク学術プロトタイプ」が支配的で、産業/deployment 証拠は希少——本 wiki の産業ソースの貴重さを裏づける**: [[LLM4Log]] は 162 task-paper レコードのうち産業/proprietary 文脈の言及は 25・人手/ユーザ study は 17・deployment 系メトリクスは 23・明確な deployment 証拠は 5 のみと定量化し、公開ベンチ(特に HDFS/BGL)への過度な依存が long causal chain・mixed-source stream・privacy 制約・rapid drift といった運用現実を部分的にしか反映しないと述べる(§7.2)。これは本 wiki が一次ソースで持つ産業展開済みのログ解析([[LogPilot]] が Volcano Engine に展開・[[AlertGuardian]] が Tencent で MTTR 156→21 分・[[L4]] が Platform-X で 428 障害研究)が、サーベイ全体でも希少な「明確な deployment 証拠」の側に属することを意味する。さらにサーベイは deployment 成熟度がタスク間で不均一で、**[[根本原因分析]] が産業/deployment 評価の最も明確な集中を持つ**一方、パース/異常検知/要約は依然ベンチ駆動だと指摘する。(Source: [[LLM4Log]], [[@2025__ASE__LogPilot - Intent-aware and Scalable Alert Diagnosis for Large-scale Online Service Systems]], [[@2025__ASE__AlertGuardian - Intelligent Alert Life-Cycle Management for Large-scale Cloud Systems]]) - **ログ解析を牽引する研究ハブの一次論文が wiki に揃いつつある**: [[@2025__ASE__LogPilot - Intent-aware and Scalable Alert Diagnosis for Large-scale Online Service Systems]] は [[The Chinese University of Hong Kong]] の [[Michael R. Lyu]] グループ由来(Drain・LILAC・無教師ログ parser・生成的 RCA の COCA・LLM 訓練障害診断の L4 の系譜)。本 wiki の [[MonitorAssistant]] は [[Tsinghua University]] の [[Dan Pei]] グループ(LogAnomaly・NetManAIOps の系譜)。さらに [[LLM4Log]] はパイプライン全体を地図化する [[Concordia University]] SPEAR lab([[Tse-Hsun Chen]])由来で、Lyu/Pei の診断系一次論文に「フィールド全体のメタ研究」を重ねる。[[A Survey of AIOps in the Era of Large Language Models]] が地図化する LLM 時代のログ解析(LogGPT・Knowlog・OASIS 等)の上で、ログ解析を牽引する複数グループの一次・メタ論文が wiki に並び始めた。(Source: [[@2025__ASE__LogPilot - Intent-aware and Scalable Alert Diagnosis for Large-scale Online Service Systems]], [[@2024__ESEC-FSE__MonitorAssistant - Simplifying Cloud Service Monitoring via Large Language Models]], [[LLM4Log]]) ### ドメイン特化ログ診断(カーネルパニック RCA) - **カーネルパニックログの「スパース性 + 長距離依存」という 2 課題は、既存の障害指示ログ抽出手法(TF-IDF/TextRank・Onion・SwissLog 等)と RNN/Transformer 系異常検知(DeepLog・LogBERT・NeuralLog 等)のいずれもカバーしない設計空隙として定量化される**: LogSage([[@2025__FCS__From Chaos to Clarity - Log-based Kernel Panic Root Cause Analysis for Large-Scale Cloud Services]], FCS 2025)は、ByteDance 大規模クラウド基盤の実例(4,445 行の生ログのうち根本原因を示すのは末尾 67 行のみ)で、カーネルパニックを直接示すログがごく一部にとどまる**スパース性**と、"memblock allocation failed"(38 行目)と "Kernel panic not syncing: Out of memory"(323 行目)のように同一根本原因を指すログが抽出後も大きく離れる**長距離依存**を、教師なしクラスタリング+LLM要約(FILE)とグラフニューラルネットワーク+能動学習(GARCA)の 2 段パイプラインで解く。本 concept が整理してきた「情報を絞ってから推論する」骨格([[LogPilot]] のリクエストクラスタリング、[[LogCleaner]] のイベント選別)の延長線上に位置しつつ、FILE は「最新タイムスタンプを持つクラスタを障害指示クラスタとする」という**カーネルパニック特有のドメイン知識**(クラッシュ直前にログ記録される)を組み込む点で、汎用のログ選別手法とは異なる。(Source: [[@2025__FCS__From Chaos to Clarity - Log-based Kernel Panic Root Cause Analysis for Large-Scale Cloud Services]]) - **LogSage は「情報選別(FILE)」と「グラフベース長距離依存モデリング(GARCA)」を独立変数として分離し、アブレーションで各々の寄与を定量化した稀な事例である**: 生ログ直接入力(w/o FILE、F1=60.1)→クラスタリングのみ(No LLM、F1=70.8、+10pt)→クラスタリング+LLM要約(Full、F1=92.2)という段階的改善(Table 6)、および平均プーリング(w/o GARCA、F1=66.7)→汎用 BERT エンコーダ(F1=74.4)→BigLog+GraphSAGE(Full、F1=92.2)という段階的改善(Table 7)がそれぞれ独立に測定された。本 concept の「情報を絞ってから LLM を選択的に呼ぶ階層設計」原理(LLM4Log §7.1)がログベース RCA に適用される際、選別段階(FILE)と推論段階(GARCA)のどちらが精度により大きく寄与するかを定量分離した点で、[[LogKG]] の知識グラフ埋め込み単体設計より粒度の細かいアブレーション証拠を提供する。(Source: [[@2025__FCS__From Chaos to Clarity - Log-based Kernel Panic Root Cause Analysis for Large-Scale Cloud Services]], §4.4) - **ログ専用ドメイン特化事前学習モデル([[BigLog]])によるケース埋め込みが、汎用埋め込みに対する優位性を長距離依存モデリングの文脈で再確認する**: LogSage の GARCA は各障害ケースを BigLog でベクトル化しコサイン類似度に基づきグラフを構築するが、汎用 BERT エンコーダへの置換(GARCA(BERT))は F1 が 7〜9 ポイント低下する。本 concept が整理してきた「ログ解析はドメイン特化前処理設計が成否を分ける」という観察(ネットワーク syslog の G-square vs Fisher-Z、[[@2018__TNSM__Mining Causality of Network Events in Log Data]])と同型のパターンが、埋め込みモデルの選択という別の設計点でも確認された。(Source: [[@2025__FCS__From Chaos to Clarity - Log-based Kernel Panic Root Cause Analysis for Large-Scale Cloud Services]], §4.4) ### 産業規模の高スループットログ基盤(索引化インフラそのもの) - **本 concept が扱う「診断」の前提となる、ログの収集・索引化・クエリのインフラ自体が産業規模で公開された**: 本ページは主にログを入力とした診断(異常検知・RCA・要約)を扱ってきたが、[[Meta]] の [[Logarithm]]([[@2024__EngineeringAtMeta__Logarithm - A logging engine for AI training workflows and services]])は診断の一段手前——100+GB/s のログをリアルタイムに索引化し毎秒数千件のクエリに応える基盤——を報告する。[[LogPilot]] や [[L4]] が「ログ volume が LLM の context window を超える」ことを診断アルゴリズムの課題として扱うのに対し、Logarithm は同じ課題をストレージ・クエリの tiering(物理メモリ→ローカル SSD→[[Manifold]])と Bloom フィルタベースの軽量セカンダリインデックスで解く、インフラ層の解を示す。ログ解析のパイプライン([[ログ生成]]→[[ログパース]]→表現学習→下流タスク)のさらに上流に、「そもそも高スループットログをどう保存・索引化・クエリするか」という産業インフラの層が存在することを、本 concept に具体的な一次ソースとして加える。(Source: [[@2024__EngineeringAtMeta__Logarithm - A logging engine for AI training workflows and services]]) - **ログの tiering・disaggregation という設計は、[[LogReducer]]/[[LogCleaner]] の「情報を絞ってから処理する」骨格とは別の「読み取り頻度に応じて物理配置を変える」骨格を示す**: LogReducer はカーネル層で書き込み前にログを削除し、LogCleaner はパース後のイベントを情報理論的に選別するが、いずれも「不要なログを捨てる」方向である。Logarithm は逆に「全てのログを保持しつつ、直近ログほど低レイテンシな層(メモリ・SSD)に置き、古いログは高レイテンシだが低コストな層(Manifold)に落とす」という tiering で読み取りコストを制御する。「捨てて減らす」と「保持しつつ階層化する」は、ログ量が爆発的に増える環境で並立するコスト管理戦略であり、Logarithm は後者の産業実装を示す。(Source: [[@2024__EngineeringAtMeta__Logarithm - A logging engine for AI training workflows and services]]) ### ログをメトリクスとして手動活用する実務(2011年の起源) - **「ログをメトリクスとして読む」という発想は、自動パイプラインの13年前に手動の実務として存在していた**: 本 concept はログ解析を「ログ生成→パース→表現学習→下流タスク」という自動化パイプラインとして地図化してきたが、[[@2011__OReillyJapan__ウェブオペレーション - Chapter 3 インフラとアプリケーションのメトリクス]] は 2011 年時点で「最良のメトリクスはアプリケーションが書き込むログにある」と述べ、Apache の応答時間(マイクロ秒単位)・MySQL のスロークエリログ(Percona の独自パッチで閾値を動的チューニング)・Squid のキャッシュ HIT/MISS など、アプリケーションログを人手でメトリクスとして読み替える実務を報告する(§3.5)。これは [[ログ生成]] 概念が整理する what-to-log(何を記録するか)の決定を、LLM ではなくエンジニアの経験則で行っていた例であり、ログとメトリクスの境界が実務上もともと曖昧だったことを示す一次資料である。(Source: [[@2011__OReillyJapan__ウェブオペレーション - Chapter 3 インフラとアプリケーションのメトリクス]] §3.5) - **[[Mike Brittain]] のエラーログ種別・比率のグラフ化は、LogCluster(2016)が自動化した「ログ系列のクラスタリングによる調査対象圧縮」を、Munin による手動グラフ化として 5 年先取りしていた**: 本 concept が扱う [[@2016__ICSE-C__Log Clustering Based Problem Identification for Online Service Systems]](LogCluster)は、ログをベクトル化・クラスタリングして代表系列を抽出し調査対象を数桁圧縮する自動パイプラインだが、Mike Brittain は 2011 年以前に CafeMom.com で、エラーログの種類と比率を Munin で収集・グラフ化し傾向を発見する実践を独自に行っていた(§3.5)。両者はともに「個々のログ行ではなく、種類ごとに集約した比率・傾向を見る」という同じ発想を共有するが、LogCluster が IDF ベクトル化とコサイン類似度で自動的に代表系列を抽出するのに対し、Brittain の手法は人手でエラー種別を定義しグラフ化するという、自動化以前の素朴な実装である。(Source: [[@2011__OReillyJapan__ウェブオペレーション - Chapter 3 インフラとアプリケーションのメトリクス]] §3.5, [[@2016__ICSE-C__Log Clustering Based Problem Identification for Online Service Systems]]) ### ログパース研究の発展段階(実証研究→プロンプトベース→ファインチューニング) - **サーベイ横断で「ログパースが LLM ベースログ解析の中で最も活発に研究されるタスク」という位置づけが再確認され、研究の発展を 3 段階として粒度の粗い形で整理し直せる**: [[@2025__CSUR__A Survey of AIOps in the Era of Large Language Models - Chapter 3 RQ1 - Transformations in Data with LLM Integration]] は、[[LLM4Log]] が生成→パース→表現学習→下流タスクの 7 タスク粒度で地図化するのとは異なる粒度で、ログパース研究を「①実証研究(既存 LLM をそのまま試し限界を確認: Priyanka et al. のゼロショット ChatGPT・Le et al. のプロンプト手法比較)→②プロンプトベース(ICL・キャッシュ・サンプリングで限界を緩和: LILAC・LLMParser・Lemur・DivLog・Sun et al.)→③ファインチューニング(専門特化: OWL・LogLM・Mehrabi et al.)」という 3 段の発展として整理する。これは LLM4Log のタスク駆動タクソノミー(Fig.1)を横から見た**手法アプローチ軸**の整理であり、両サーベイを突き合わせることで「ログパース研究はどのタスクを解くか」(LLM4Log)と「どうアプローチが進化してきたか」(本サーベイ)という直交する 2 つの地図が得られる。(Source: [[@2025__CSUR__A Survey of AIOps in the Era of Large Language Models - Chapter 3 RQ1 - Transformations in Data with LLM Integration]], [[LLM4Log]]) - **「小型 LLM の方が専門タスクで有利な場合がある」という観察が、LILAC のキャッシュ設計と矛盾しない形でログパースに現れる**: LLMParser は Flan-T5-small/base・LLaMA-7B・ChatGLM-6B の 4 モデルを 16 のオープンソースシステムで比較し、より小型の LLM がログパースにより有効な場合があると報告する(§3.1)。これは本 concept が既に蓄積してきた「情報を絞ってから LLM を選択的に呼ぶ階層設計」(LLM4Log §7.1)——強い LLM を全段に投入せず高価値な推論・説明コンポーネントに限定する——という原則と整合する。ログパースという定型度の高いタスクでは、大型 LLM の汎用推論力よりもタスク特化のファインチューニングやモデル選択が効くという具体例を提供する。(Source: [[@2025__CSUR__A Survey of AIOps in the Era of Large Language Models - Chapter 3 RQ1 - Transformations in Data with LLM Integration]]) - **固定深さ木パーサ(Drain3)とシャノンエントロピーによる2層圧縮の組み合わせが、LLM 前段のコンテキスト圧縮において決定論的かつ高圧縮率(1,000〜7,000倍)な前処理基盤を提供する**: [[@2026__ASE__Log-Insight - Automating Microservice Incident Diagnosis via Neuro-Symbolic Log Analysis]] は、構文クラスタリングにとどまる Drain3 の出力に対し、列レベルとテンプレート内パラメータスロットレベルの2層でエントロピーに基づく分類・抽象化を実施した。これにより、従来のナイーブな生ログ注入や単純なテンプレート抽出と比較して、300万行規模のストリームであっても7,000〜20,000文字の安定したトークン枠に収めつつ、下流の障害根因特定精度(MRR)を大幅に向上させられることを示した。(Source: [[@2026__ASE__Log-Insight - Automating Microservice Incident Diagnosis via Neuro-Symbolic Log Analysis]]) - HPC エクサスケール syslog(約 900GB)を変数除去パターンと Aho-Corasick(pat-AHO/seq-AHO)に圧縮し、回顧分析で学習した系列をリアルタイム照合・オートコンプリートするワークフローが示された。Spell/Drain 型の手動ヒューリスティックパースより、進化するテンプレートへの耐性を主張する。(Source: [[@2026__arXiv__A Scalable Pattern Mining Workflow for Interpretable Machine Log Analysis in High-Performance Computing Environments]]) ## 未解決の問い ### 原理タクソノミーと診断粒度をめぐる問い - [[@2024__arXiv__Failure Diagnosis in Microservice Systems - A Comprehensive Survey and Analysis - Chapter 4.1 Failure Diagnosis Through Logs]] の統計/ML/DLタクソノミーは2023年時点のログベース障害診断17手法を対象とし、LLMベース手法(LogPilot・LogKG以降)を含んでいない。原理軸のタクソノミーにLLMベース手法を位置づけると、既存の「教師あり/教師なし/両方」という下位分類は維持できるか、それとも新たな軸(プロンプトベース/ファインチューニング等、既存 concept が §3.1 サブセクションで扱う軸)へ置き換わるか。 - コンポーネントレベルからインスタンス/リクエストレベルへの粒度細分化が深層学習・LLMの導入と相関するという仮説(横断的知見)は、原理(ML/DL)と粒度(コンポーネント/インスタンス)の間の因果関係を主張するものではなく相関の観察にとどまる。手法の原理と診断粒度の関係を体系的に分析したメタ研究は本 concept の範囲では見つかっていない。 ### ログパース研究の発展段階をめぐる問い - 実証研究(ChatGPT のゼロショット限界)→プロンプトベース(ICL・キャッシュ)→ファインチューニング(専門特化)という 3 段階の発展は、[[ログパース]] 概念が扱う個別手法(Drain・LILAC 等)の系譜とどう対応するか。本サーベイの粗い 3 段階分類と LLM4Log の細粒度タスク分類を統合したメタタクソノミーは構築可能か。(Source: [[@2025__CSUR__A Survey of AIOps in the Era of Large Language Models - Chapter 3 RQ1 - Transformations in Data with LLM Integration]], [[LLM4Log]]) - LLMParser が報告する「小型 LLM の方がログパースに有効な場合がある」という知見は、どのログの性質(テンプレート多様性・語彙のドメイン特化度)に依存するか。大型 LLM が優位になる条件と小型 LLM が優位になる条件を分ける要因は、本サーベイの範囲では明示されていない。 ### 産業規模ログ基盤をめぐる問い - Logarithm が実現する「ログストリームの schema-on-write・行単位のメタデータ抽出」という索引化インフラは、本ページの LLM ベースログ解析パイプライン([[ログ生成]]→[[ログパース]]→下流タスク)の[[ログパース]]段とどう接続するか。Logarithm の正規表現ベース parse-and-extract ルールは、Drain のような教師なしログパーサとは異なる設計(ユーザー定義ルール)だが、テンプレート未知の新規ログにどこまで頑健か。 - Logarithm の Bloom フィルタベースの軽量セカンダリインデックスは、テキスト検索(正規表現)とメタデータ述語の両方を索引化するが、LLM ベースの意味検索(embedding 類似度によるログ scoping)とは異なる。本ページが蓄積する scoping 手法(LogPilot の request クラスタリング等)は Logarithm のようなインフラの上でどう実装されるべきか、あるいは専用の意味索引が別途必要か。 ### ドメイン特化ログ診断をめぐる問い - LogSage のオンライン推論は $k=10$(履歴グラフへの新規ノード接続数)を教師なし環境ではチューニングできない非クリティカルなハイパーパラメータとして固定するが、この非最適性がオンライン推論精度にどう影響するかは論文内で定量化されていない。またオフライン訓練済みグラフへの一時ノード挿入という設計は、履歴ケースグラフ自体の経時的なドリフト(障害パターンの進化)に追従できるか——[[LogCleaner]]/[[ログパース]] が扱う「テンプレートの経時変化」と同種の問いがグラフ RCA の文脈でも未解決である。(Source: [[@2025__FCS__From Chaos to Clarity - Log-based Kernel Panic Root Cause Analysis for Large-Scale Cloud Services]]) - LogSage の LLM 要約(DeepSeek-V3 等)は投機を避けるようプロンプト設計されるが、要約の忠実性・幻覚リスクの体系的な定量評価(人手評価やハルシネーション率)は論文内で報告されていない。本 concept が整理する「ログ証拠の忠実性は文字列近似だけで足りるか」という問い([[@2024__CIKM__RCAgent - Cloud Root Cause Analysis by Autonomous Agents with Tool-Augmented Large Language Models]] に関する既存の問い)と同根で、カーネルパニック RCA という高スパース性ドメインでも未解決である。 ### パイプライン全体・評価をめぐる問い - パイプライン上流(ログ生成・パース)の改善は下流診断(scoping・RCA)の精度をどれだけ底上げするか。サーベイはパイプラインを「必須の逐次でなく共通の分析構造」と読むよう促すが、生成→パース→診断の各段の品質が連鎖する経路は系統的に未測定([[ログパース]]/[[ログ生成]] の同じ問いと接続)。(Source: [[LLM4Log]]) - サーベイが LLM4Log の希少な「明確な deployment 証拠」と位置づけうる本 wiki の産業ソース([[LogPilot]]/[[AlertGuardian]]/[[L4]])は、HDFS/BGL 中心のベンチ評価とどれだけ乖離するか。公開ベンチで強い手法が long causal chain・mixed-source・privacy 制約の本番でも通用する保証はない——ベンチ性能と deployment 成熟度の相関は測れるか。(Source: [[LLM4Log]]) - サーベイが指摘する「ログベース異常検知は T5/GPT-2 等の小型前処理モデル依存で、単純なデータセットでは従来 ML と差が出にくい」課題([[A Survey of AIOps in the Era of Large Language Models]] §7.2)は、LogPilot のような LLM ベース log RCA にも当てはまるか。評価データ(単一企業・202 アラート)の性質がゲインを過大評価していないか。 ### 下流診断段の設計をめぐる問い - LogPilot のログ単一モダリティ + 構造化深掘り設計と、[[Bits AI SRE]] のマルチモーダル横断設計は、どの障害クラスで優劣が分かれるか。LogPilot が検出する「silent failure」(error code を返すのに全コンポーネントが info レベルで記録)のようにログに根本原因情報が欠ける場合、ログ単一では原理的に限界があり、メトリクス/トレース融合が要るのでは。(Source: [[@2025__ASE__LogPilot - Intent-aware and Scalable Alert Diagnosis for Large-scale Online Service Systems]]) - log parsing(Drain 等)の精度が下流(scoping・RCA)にどう波及するか。LogPilot は two-tier parsing(logging path で粗くクラスタリング → Drain)を使うが、parsing 誤りが log chain・クラスタリング・RCA に伝播する影響は未評価。 - LogPilot の intent-aware scoping は PromQL アラート定義に依存する。アラート定義が無い/貧弱な環境(アドホックな障害調査、アラート発火前の予兆調査)ではどう log scoping するか。アラート起点でない探索的ログ診断への一般化は可能か。 ### 障害注入テストのノイズログをめぐる問い - SBF は「注入前の時間窓 $W^t$ に定常的に現れていたログ型はノイズ候補」という仮定(A4)に依存する。本番連続監視(注入前後の窓が定義しにくい)でこの仮定を代替するベースライン窓の定義方法はあるか。また「定常的に現れる = ノイズ」という判定は、正常時から徐々に悪化するグレー障害の兆候まで誤ってノイズ扱いしないか。(Source: [[@2011__SRDS__Identifying Faults in Large-Scale Distributed Systems by Filtering Noisy Error Logs]]) - SBF の時系列類似度フィルタリング(Haar ウェーブレット + DTW)と [[LogCleaner]] のイベント類型分類(TF-IDF → 相互情報量 → OPTICS クラスタリング)は、どちらも「無関係なログを除去する」が手法が異なる。DTW の時間パターン比較と LogCleaner の情報理論的選別は補完的か、競合的か。([[@2011__SRDS__Identifying Faults in Large-Scale Distributed Systems by Filtering Noisy Error Logs]], [[@2024__ESEM__Reducing Events to Augment Log-based Anomaly Detection Models - An Empirical Study]]) ### ネットワークOS運用ログの二層設計をめぐる問い - SONiC の `sairedis.rec` は既に構造化されている(タイムスタンプ・操作コード・SAIオブジェクトタイプ・属性が行内でキー化されている)ため、[[ログパース]] の教師なしテンプレート抽出(Drain等)を経ずに直接、[[@2018__TNSM__Mining Causality of Network Events in Log Data]] のような統計的因果マイニング(PC + G-square)の入力にできるのではないか。構造化 record ログは、パース段を省略した「よりクリーンな入力」として下流の異常検知・RCA にどれだけ有利か、書籍・論文いずれからも定量的な比較は得られない。 - 通常運用は NOTICE ログレベルで、DEBUG は再現手順が明確なときのみ・調査後は戻す運用が推奨されるが(ch.11 §11.2.2)、これは [[@2023__ICSE__LogReducer - Identify and Reduce Log Hotspots in Kernel on the Fly]] が指摘する「ログレベル誤設定がストレージホットスポットの主因(63.15%)」という知見と表裏の関係にある。ネットワーク OS のように運用者が手動でログレベルを切り替える環境では、切り替えの戻し忘れ(常時 DEBUG 化)がどの程度実際に発生し、ホットスポット化するかは未計測。 ### ネットワーク syslog 因果推論をめぐる問い - Kobayashi+ 2018 の PC + G-square アプローチは [[SINET4]] という特定の全国学術ネットワークで評価された。商用 ISP や DC ファブリックなど異なるトポロジー・ベンダー混在環境でも同じ G-square の優位性が成立するか。スパースさの程度がドメインによって異なれば適切な検定が変わりうる。(Source: [[@2018__TNSM__Mining Causality of Network Events in Log Data]]) - PC アルゴリズムは各サブネットを 1 日ウィンドウで独立処理する。障害が複数サブネット・複数日にまたがる場合（グローバル障害）の因果グラフをどう統合するか、論文内で未解決。長期因果（ウィンドウサイズ依存性は「固有エッジ数が不変」と示すが方向性は不明）の扱いは。(Source: [[@2018__TNSM__Mining Causality of Network Events in Log Data]]) - 本論文の周期フィルタ + PC + 頻出エッジ除去のパイプラインを LLM ベースのログ診断（[[ログ解析]] の LLM ベース手法）と組み合わせた場合、どちらのアプローチが実用的なネットワーク管理の RCA により貢献するか。PC アルゴリズムが生成する構造的因果 DAG は LLM への入力として有効か。 ### ログイベント削減をめぐる問い - [[LogCleaner]] のイベント 3 類型は教師ありラベルに依存する。教師なしモデルや、ラベルが存在しない本番環境で anti-event と key-event をどう区別するか。相互情報量は教師なしに拡張できるか。([[@2024__ESEM__Reducing Events to Augment Log-based Anomaly Detection Models - An Empirical Study]]) - LogCleaner のイベント選別はパース後の静的テンプレートに基づく。LogPilot の二段パース(logging path + Drain)やコード変更による新規テンプレートの出現にどう追従するか。再プロファイリングの頻度・コストと未知イベントの偽陰性リスクのトレードオフは。([[@2024__ESEM__Reducing Events to Augment Log-based Anomaly Detection Models - An Empirical Study]]) ### ログボリューム削減をめぐる問い - LogReducer はホットスポットを全量ドロップするが、「合理的ホットスポット」（5.26%）のように障害診断に必要なログが含まれうる。ホットスポット内のサンプリング（全量ドロップでなく一定割合を残す）は検討されておらず、診断有効性とストレージ削減のトレードオフの定量評価が未解決。([[@2023__ICSE__LogReducer - Identify and Reduce Log Hotspots in Kernel on the Fly]]) - ホットスポットの修正後 2 か月以内に 18/19 サービスで新たなホットスポットが出現し、削減は反復タスクである。開発プロセスへの品質フィードバック（[[ログ生成]] の where/what/how 推薦）を組み合わせれば、発生自体を予防できるか。([[@2023__ICSE__LogReducer - Identify and Reduce Log Hotspots in Kernel on the Fly]]) ### ロギング配置の最適化をめぐる問い - LogAdvisor(2015年)・Log20(2019年)はいずれもログ配置の最適化を主張するが、本ページが2023年以降蓄積してきた LogReducer・LogCleaner の実証(WeChat の少数テンプレートがストレージの過半を占める等)と比べ、配置最適化を本番の大規模マイクロサービス環境に適用した産業デプロイ証拠は Notaro 2021 の章に記載がない。ソースコード設計時点の最適化(LogAdvisor/Log20)は、LogReducer が指摘する「ログレベル誤設定・テストログ消し忘れ」という開発プロセス起因の問題(根本原因の63.15%)をそもそも防げるのか、それとも別種の問題(有用なログの欠落)を生むのか。(Source: [[@2021__TIST__A Survey of AIOps Methods for Failure Management - Chapter 4.3 Failure Detection]] §4.3.3, [[@2023__ICSE__LogReducer - Identify and Reduce Log Hotspots in Kernel on the Fly]]) - Log20 のエントロピーベース設置最適化と、本ページが整理する「情報を絞ってから推論する」骨格([[LogPilot]] のリクエストクラスタリング、[[LogCleaner]] のイベント選別)を組み合わせた場合、上流(生成時)と下流(選別時)で二重に情報理論的最適化をかけることに相乗効果はあるか、それとも上流で最適化済みのログに下流の選別を重ねても限界効用が小さいか。(Source: [[@2021__TIST__A Survey of AIOps Methods for Failure Management - Chapter 4.3 Failure Detection]] §4.3.3) ### 知識グラフ統合ログ診断をめぐる問い - [[@2023__TSC__LogKG - Log Failure Diagnosis through Knowledge Graph|LogKG]] は構造化フィールドの関係を知識グラフで明示するが、LLM ベース手法(LogPilot・RCAgent 等)と組み合わせた場合にどちらの設計が優位になるか。KGE が捉える構造的依存と LLM が捉えるテキスト意味は相補的か競合的か、またどの障害クラスで各アプローチが優位になるかは未検証である。([[@2023__TSC__LogKG - Log Failure Diagnosis through Knowledge Graph]]) - LogKG の FOLR が使う IFF 閾値(θiff)は CMCC では 0.40–0.50、GAIA では 0.10–0.20 と大きく異なり、データセット依存性が高い。本番環境でのドメイン適応をどう自動化するか。また時間窓 ω の最適値も障害継続時間の分布に依存するため、適応的なウィンドウ設計が必要ではないか。 ### ログ品質をめぐる問い - ログ品質 feedback(LogPilot が検出する silent failure・inconsistent logging)を開発プロセスへ還元する Dev-Ops ループは、実際に observability gap を縮めるか。LogPilot は「ログ品質を開発チームの engineering discipline 評価に組み込んだ」と述べるが、その長期的効果は未測定。 - LLM 訓練ログ品質の根本改善(レベル/配置/内容の標準化・推薦)はどこまで自動化できるか。ログ単独で診断できない約 46.1% をマルチモーダル統合でどこまで埋められるか。([[@2025__ESEC-FSE__L4 - Diagnosing Large-scale LLM Training Failures via Automated Log Analysis]]) - RCAgent のログ専門エージェントは証拠の fuzzy match で幻覚を落とすが、類似した無関係ログを根拠として誤採用する危険は残る。ログ証拠の忠実性は文字列近似だけで足りるか、それとも時間・トポロジー・コードパスとの整合検査が必要か。 - **テンプレートパーサの出力スロット分類(CONST, NUM, ENUM, ID)における閾値設定(出現割合やユニーク値数)が、動的なログストリームや未知のマイクロサービスにおいてどの程度ドリフトに対して頑健か**: Log-Insight のパラメータ層分類ルールは一定のヒューリスティック閾値に依存しており、ログ形式が頻繁に更新される継続的デプロイ環境での長期的な安定性は検証が必要。(Source: [[@2026__ASE__Log-Insight - Automating Microservice Incident Diagnosis via Neuro-Symbolic Log Analysis]]) - HPC ログのパターン/系列圧縮は、LLM ベースログパースや RAG 前処理として、どの程度トークン削減と診断品質を両立するか。単一施設 syslog 以外への転移は未検証。(Source: [[@2026__arXiv__A Scalable Pattern Mining Workflow for Interpretable Machine Log Analysis in High-Performance Computing Environments]]) ## 関連 - ソース: [[@2024__arXiv__Failure Diagnosis in Microservice Systems - A Comprehensive Survey and Analysis - Chapter 4.1 Failure Diagnosis Through Logs]] / [[@2025__CSUR__A Survey of AIOps in the Era of Large Language Models - Chapter 3 RQ1 - Transformations in Data with LLM Integration]] / [[@2025__Gihyo__実践SONiC入門 - Chapter 11 SONiCのトラブルシューティング]] / [[@2018__TNSM__Mining Causality of Network Events in Log Data]] / [[@2011__SRDS__Identifying Faults in Large-Scale Distributed Systems by Filtering Noisy Error Logs]] / [[LLM4Log]] / [[@2025__ASE__LogPilot - Intent-aware and Scalable Alert Diagnosis for Large-scale Online Service Systems]] / [[@2024__ESEC-FSE__MonitorAssistant - Simplifying Cloud Service Monitoring via Large Language Models]] / [[A Survey of AIOps in the Era of Large Language Models]] / [[@2026__Datadog__Building Bits AI SRE - Autonomous Incident Investigation Agent]] / [[@2025__ESEC-FSE__L4 - Diagnosing Large-scale LLM Training Failures via Automated Log Analysis]] / [[@2024__ESEM__Reducing Events to Augment Log-based Anomaly Detection Models - An Empirical Study]] / [[@2023__ICSE__LogReducer - Identify and Reduce Log Hotspots in Kernel on the Fly]] / [[@2025__FCS__From Chaos to Clarity - Log-based Kernel Panic Root Cause Analysis for Large-Scale Cloud Services]] / [[@2024__EngineeringAtMeta__Logarithm - A logging engine for AI training workflows and services]] / [[@2011__OReillyJapan__ウェブオペレーション - Chapter 3 インフラとアプリケーションのメトリクス]] / [[@2021__TIST__A Survey of AIOps Methods for Failure Management - Chapter 4.3 Failure Detection]] / [[@2026__arXiv__A Scalable Pattern Mining Workflow for Interpretable Machine Log Analysis in High-Performance Computing Environments]] - 概念: [[ログパース]] / [[ログ生成]] / [[根本原因分析]] / [[異常検知]] / [[障害予測]] / [[Fault Localization]] / [[AIOps]] / [[テレメトリ]] / [[インシデント管理]] / [[特徴量削減]] / [[グラフベースRCA]] / [[LLMによる根本原因分析]] / [[AI訓練ログデバッグ]] / [[デバッグアクセスの設計]] / [[シーケンスマイニング]] - エンティティ: [[LogPilot]] / [[MonitorAssistant]] / [[Bits AI SRE]] / [[Michael R. Lyu]] / [[Dan Pei]] / [[Zhihan Jiang]] / [[Tse-Hsun Chen]] / [[Concordia University]] / [[LogCleaner]] / [[LogReducer]] / [[Guangba Yu]] / [[Pengfei Chen]] / [[Xiang Rao]] / [[Huaimin Wang]] / [[National University of Defense Technology]] / [[Satoru Kobayashi]] / [[Kensuke Fukuda]] / [[University of Tokyo]] / [[LogCausalAnalysis]] / [[SINET4]] / [[Tianyu Cui]] / [[Shenglin Zhang]] / [[Nankai University]] / [[ByteDance]] / [[BigLog]] / [[GraphSAGE]] / [[Logarithm]] / [[Meta]] / [[Mike Brittain]] / [[Flickr]] - 関連 MOC: [[AIOps - Log Analysis - MOC]] / [[LLM for SREの障害原因診断論文の分類]] ## 出典 - [[@2024__arXiv__Failure Diagnosis in Microservice Systems - A Comprehensive Survey and Analysis - Chapter 4.1 Failure Diagnosis Through Logs]](Fig.4 統計/ルール・機械学習・深層学習の原理タクソノミー、Table 3 診断粒度、Log3C・DISTALYZERのログ+メトリクス統合) - [[@2025__CSUR__A Survey of AIOps in the Era of Large Language Models - Chapter 3 RQ1 - Transformations in Data with LLM Integration]](§3.1 ログパース研究の 3 段階: 実証研究[Priyanka et al.・Le et al.]・プロンプトベース[LILAC・LLMParser・Lemur・DivLog・Sun et al.]・ファインチューニング[OWL・LogLM・Mehrabi et al.]) - [[@2025__Gihyo__実践SONiC入門 - Chapter 11 SONiCのトラブルシューティング]](§11.2 syslog フォーマット・swssloglevel によるログレベル変更, §11.3 APPL_DB 変更ログ swss.rec・SAI 呼び出しログ sairedis.rec の記録形式と読み方) - [[LLM4Log]](§1/Fig.1 パイプライン全体, §2 タクソノミーと 145 論文, §7.1 階層設計の横断原理, §7.2 評価の comparability/realism と deployment 証拠の希少さ) - [[@2025__ASE__LogPilot - Intent-aware and Scalable Alert Diagnosis for Large-scale Online Service Systems]](§I 背景, §II-B 産業実践 2 段, §III 動機・log scoping/RCA のギャップ, §IV 手法, §IX Related Work) - [[@2024__ESEC-FSE__MonitorAssistant - Simplifying Cloud Service Monitoring via Large Language Models]](§3.1 実用的異常の定義) - [[A Survey of AIOps in the Era of Large Language Models]](§4.1 ログ異常検知, §4.2 log-based RCA, §7.2 ログ手法の限界) - [[@2025__ESEC-FSE__L4 - Diagnosing Large-scale LLM Training Failures via Automated Log Analysis]](障害指示ログの 3 指標分布・fault library) - [[@2026__Datadog__Building Bits AI SRE - Autonomous Incident Investigation Agent]](マルチモーダルなテレメトリ横断の RCA) - [[@2024__ESEM__Reducing Events to Augment Log-based Anomaly Detection Models - An Empirical Study]](§5 ログイベント 3 類型, §6 LogCleaner, パイプライン上流の入力削減による性能・効率向上) - [[@2023__ICSE__LogReducer - Identify and Reduce Log Hotspots in Kernel on the Fly]](§III 57 ホットスポット実証研究, §IV eBPF ログフィルタ, §VI WeChat 本番 39.08% 削減) - [[@2024__CIKM__RCAgent - Cloud Root Cause Analysis by Autonomous Agents with Tool-Augmented Large Language Models]](§3.2.2 ログ分析専門エージェント, Algorithm 1, §5.2 LLM expert agents アブレーション) - [[@2011__SRDS__Identifying Faults in Large-Scale Distributed Systems by Filtering Noisy Error Logs]](§I ノイズ障害 4 種類の定義, §II 定義 1〜3・SBF Algorithm 1, §IV 表 I・図 3 実験結果) - [[@2018__TNSM__Mining Causality of Network Events in Log Data]](§IV-B 周期フィルタ詳細, §IV-C G-square vs Fisher-Z 定量比較, §IV-D 後処理, §VI 前処理効果・ビンサイズ・偽陽性分析, §VII ケーススタディ・トラブルチケット比較) - [[@2016__ICSE-C__Log Clustering Based Problem Identification for Online Service Systems]](§3 LogCluster 4 段フロー, §4.1/4.2/4.3 RQ1〜3 評価, §5 産業展開事例 Service A/Product G/Product L/Service C, §6 教訓 ログ重大度レベルの限界) - [[@2025__FCS__From Chaos to Clarity - Log-based Kernel Panic Root Cause Analysis for Large-Scale Cloud Services]](§2 問題設定・Challenge 1/2, §3 FILE/GARCA 設計, §4.4 アブレーション Table 6/7, §5.1 ByteDance 本番デプロイ) - [[@2024__EngineeringAtMeta__Logarithm - A logging engine for AI training workflows and services]](Meta 産業規模の高スループットログ索引化インフラ、100+GB/s 取り込み・tiering・Bloom フィルタセカンダリインデックス) - マット・マッシー、ジョン・オルスポー, 「3章 インフラとアプリケーションのメトリクス」, 『ウェブオペレーション ―サイト運用管理の実践テクニック』, オライリー・ジャパン, 2011, §3.5(ログをメトリクスとして活用する実務、Mike Brittain のエラーログのグラフ化)。 - [[@2021__TIST__A Survey of AIOps Methods for Failure Management - Chapter 4.3 Failure Detection]](§4.3.3 Log Enhancement: LogAdvisor[168]・Log20[163]によるログ配置の情報理論的最適化、§4.3.1 Xu et al.[151]のTF-IDF+PCAとの対比)