# ログ解析 ## 定義 ログ解析(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)にまたがるモダリティ特化の手段で、メトリクス・トレースと並ぶオブザーバビリティの一次データである。 研究領域としてのログ解析は、単一タスクでなく**エンドツーエンドのパイプライン全体**として捉えるのが現在の到達点である。[[@2026__arXiv__LLM4Log - A Systematic Review of Large Language Model-based Log Analysis]] は 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, [[@2025__CSUR__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」(診断)を中心に育ったが、[[@2026__arXiv__LLM4Log - A Systematic Review of Large Language Model-based Log Analysis]] は LLM ベースログ解析を [[ログ生成]]→[[ログパース]]→表現学習→下流タスク([[異常検知]]・[[障害予測]]・[[根本原因分析]]・ログ要約)のエンドツーエンドのパイプラインとして体系化し(Fig.1)、2020–2025 の 145 論文を統一タスク駆動タクソノミーで地図化する。これは [[@2025__CSUR__A Survey of AIOps in the Era of Large Language Models]] が AIOps 全工程を「ログは複数モダリティの 1 つ」として広く俯瞰したのと相補的で、LLM4Log は**ログを中心証拠源に固定**してパイプライン全段を覆う。本 wiki の LogPilot/MonitorAssistant/L4 が攻めていた「診断」は、この地図では下流タスク 1 段に位置づく——ログ解析研究の全体像が、診断中心の見方からパイプライン 7 タスクの見方へ拡張された。(Source: [[@2026__arXiv__LLM4Log - A Systematic Review of Large Language Model-based Log Analysis]], [[@2025__CSUR__A Survey of AIOps in the Era of Large Language Models]]) - **「情報を絞ってから LLM を選択的に呼ぶ階層設計」がパイプライン全段で反復する、とサーベイが横断的に定式化する**: 本 wiki の [[LogPilot]] は request クラスタリングで LLM 呼び出しを 98.71% 削減し、[[OpenRCA]] は生テレメトリをコンテキストに載せずコード実行で捌いた——個別論文で観測してきたこの骨格を、[[@2026__arXiv__LLM4Log - A Systematic Review of Large Language Model-based Log Analysis]] は全タスク共通の設計原理として明言する。すなわち成功システムは無制約な end-to-end 生成に頼らず、前処理・検索・フィルタ・グルーピング・軽量スコアリングで探索空間を絞ってから、強い LLM を意味解釈・説明・レポートに選択的に呼ぶ(§7.1)。[[ログパース]] の cache/grouping(LILAC/LogParser-LLM)、[[異常検知]] の小モデルによる候補窓の絞り込み + LLM 説明、[[根本原因分析]] の retrieval-then-generate がすべて同じパターン。**「LLM は大きなパイプライン内の高価値な推論・説明コンポーネントであり、全段の置換ではない」**がサーベイの中核結論で、本 wiki が個別ソースで積み上げた観察の上位一般化に当たる。(Source: [[@2026__arXiv__LLM4Log - A Systematic Review of Large Language Model-based Log Analysis]], [[@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)をこの構造に対応づける。[[@2025__CSUR__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]], [[@2025__CSUR__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]]) ### ログイベント削減（入力層の前処理） - **ログ異常検知の入力イベントは大半が不要で、情報理論的選別で 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]]) ### ログボリューム削減（書き込み前の最上流介入） - **ログオーバーヘッドは少数テンプレートに集中し、カーネル層での書き込み抑止で最上流から削減可能である**: [[@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]]) ### ログ品質・評価・研究地図 - **従来のログ異常検知が依拠する 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]], [[@2025__CSUR__A Survey of AIOps in the Era of Large Language Models]]) - **LLM4Log の研究は「ベンチマーク学術プロトタイプ」が支配的で、産業/deployment 証拠は希少——本 wiki の産業ソースの貴重さを裏づける**: [[@2026__arXiv__LLM4Log - A Systematic Review of Large Language Model-based Log Analysis]] は 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: [[@2026__arXiv__LLM4Log - A Systematic Review of Large Language Model-based Log Analysis]], [[@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 の系譜)。さらに [[@2026__arXiv__LLM4Log - A Systematic Review of Large Language Model-based Log Analysis]] はパイプライン全体を地図化する [[Concordia University]] SPEAR lab([[Tse-Hsun Chen]])由来で、Lyu/Pei の診断系一次論文に「フィールド全体のメタ研究」を重ねる。[[@2025__CSUR__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]], [[@2026__arXiv__LLM4Log - A Systematic Review of Large Language Model-based Log Analysis]]) ## 未解決の問い ### パイプライン全体・評価をめぐる問い - パイプライン上流(ログ生成・パース)の改善は下流診断(scoping・RCA)の精度をどれだけ底上げするか。サーベイはパイプラインを「必須の逐次でなく共通の分析構造」と読むよう促すが、生成→パース→診断の各段の品質が連鎖する経路は系統的に未測定([[ログパース]]/[[ログ生成]] の同じ問いと接続)。(Source: [[@2026__arXiv__LLM4Log - A Systematic Review of Large Language Model-based Log Analysis]]) - サーベイが LLM4Log の希少な「明確な deployment 証拠」と位置づけうる本 wiki の産業ソース([[LogPilot]]/[[AlertGuardian]]/[[L4]])は、HDFS/BGL 中心のベンチ評価とどれだけ乖離するか。公開ベンチで強い手法が long causal chain・mixed-source・privacy 制約の本番でも通用する保証はない——ベンチ性能と deployment 成熟度の相関は測れるか。(Source: [[@2026__arXiv__LLM4Log - A Systematic Review of Large Language Model-based Log Analysis]]) - サーベイが指摘する「ログベース異常検知は T5/GPT-2 等の小型前処理モデル依存で、単純なデータセットでは従来 ML と差が出にくい」課題([[@2025__CSUR__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 するか。アラート起点でない探索的ログ診断への一般化は可能か。 ### ログイベント削減をめぐる問い - [[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]]) ### ログ品質をめぐる問い - ログ品質 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]]) ## 関連 - ソース: [[@2026__arXiv__LLM4Log - A Systematic Review of Large Language Model-based Log Analysis]] / [[@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__CSUR__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]] - 概念: [[ログパース]] / [[ログ生成]] / [[根本原因分析]] / [[異常検知]] / [[障害予測]] / [[Fault Localization]] / [[AIOps]] / [[テレメトリ]] / [[インシデント管理]] / [[特徴量削減]] - エンティティ: [[LogPilot]] / [[MonitorAssistant]] / [[Bits AI SRE]] / [[Michael R. Lyu]] / [[Dan Pei]] / [[Zhihan Jiang]] / [[Tse-Hsun Chen]] / [[Concordia University]] / [[LogCleaner]] / [[LogReducer]] / [[Guangba Yu]] / [[Pengfei Chen]] - 関連 MOC: [[AIOps - Log Analysis - MOC]] / [[LLM for SREの障害原因診断論文の分類]] ## 出典 - [[@2026__arXiv__LLM4Log - A Systematic Review of Large Language Model-based Log Analysis]](§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 実用的異常の定義) - [[@2025__CSUR__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% 削減)