# ログベース異常検知 ## 定義 ログベース異常検知(log-based anomaly detection)は、ソフトウェアシステムが出力するログを解析し、正常な実行パターンから逸脱した挙動を自動的に検知する取り組みである。[[異常検知]] のサブカテゴリとして、システムログという特定のデータソースに特化し、ログの系列的・定量的・意味的な特性を活用する点が特徴。 ログベース異常検知の標準的なプロセスは 3 段階: 1. **ログ解析(Log Parsing)**: 非構造化ログメッセージからイベントテンプレートを抽出。各テンプレートはソースコード内の print 文に対応し、可変パラメータをプレースホルダ(「\*」)で表現する。代表的手法: Drain / Drain3。 2. **ロググルーピング(Log Grouping)**: ログ系列をイベント系列に変換し、固定サイズのタイムウィンドウで整理。 3. **モデル訓練(Model Training)**: イベント系列の特性を捉えて異常を自動認識するモデルを構築。 ## 入力情報の 3 類型 分散システム、特に分散 DB のログは、異なる性質を持つ 3 種の情報を含む: ### 系列データ(Sequential Data) ログエントリの出力順序情報。正常な実行は特定のイベント系列パターンを持ち、その逸脱が異常のシグナルとなる。エクスポート・インポート操作のような特定の操作系列を持つ異常の検知に有効。(Source: [[@2024__KDD__Multivariate Log-based Anomaly Detection for Distributed Database]]) ### 定量データ(Quantitative Data) ウィンドウ内の各イベントテンプレートの出現頻度。正常な実行には「memtable を生成した回数 = flush した回数」のような定量的不変条件がある。過頻度ディスクフラッシュのような頻度異常の検知に有効。(Source: [[@2024__KDD__Multivariate Log-based Anomaly Detection for Distributed Database]]) ### 意味データ(Semantic Data) ログイベントを自然言語文として扱い、意味埋め込みベクトルとして表現。「error」「too high」等のキーワードを含む内部状態のログからデータベース固有の異常を検知できる。FastText + TF-IDF が代表的な埋め込み手法。(Source: [[@2024__KDD__Multivariate Log-based Anomaly Detection for Distributed Database]]) ## 手法の分類 ### 教師あり手法 ラベル付きデータ(正常/異常両方)を使って予測モデルを構築。 - **RobustLog**: TF-IDF + 単語ベクトル化でログイベントを意味ベクトルに変換。不安定なログデータへの対応力が特徴。 - **PLELog**: 確率的ラベル推定による半教師ありログ異常検知。 ### 教師なし手法 正常データのみから正常パターンを学習し、逸脱を異常と判定。 - **LogAnomaly**: 系列と定量の両方のパターンを利用した教師なし検知。 - **DeepLog**: LSTM でログ系列の正常パターンを学習。 ### LLM ベース手法(新興) BERT・GPT 等の大規模言語モデルを活用。詳細は [[ログ解析]] および LLM4Log サーベイ([[@2026__arXiv__LLM4Log - A Systematic Review of Large Language Model-based Log Analysis]])を参照。 ## データセット ### 既存データセット(Loghub) スタンドアロンシステムや分散フレームワーク・ファイルシステムのログを収録: - **BGL・Thunderbird**: スーパーコンピュータのスタンドアロンシステムログ - **HPC**: 高性能計算のログ - **Hadoop・Spark**: 分散コンピューティングフレームワークのログ - **HDFS・Zookeeper**: 分散ファイルシステムのログ ### MultiLog Dataset (2024) **初の分散 DB 特化データセット**: [[Apache IoTDB]] v1.2.2 上で 11 種の異常を注入して収集。 - サイズ: 216 GB、9 億レコード - 複数注入シナリオ: Single2Single / Single2Multi / Multi2Single / Multi2Multi - リポジトリ: https://github.com/AIOps-LogDB/MultiLog-Dataset (Source: [[@2024__KDD__Multivariate Log-based Anomaly Detection for Distributed Database]]) ## 分散環境における課題 ### 単一ノード依存の限界 スタンドアロンシステム向けに設計された手法を分散 DB に適用した場合、単一ノードのログだけでは異常検知が不十分であることが実証されている。異常が注入されたノード自身よりも、周辺ノードの方が異常をより確実に検知できる場合がある。(Source: [[@2024__KDD__Multivariate Log-based Anomaly Detection for Distributed Database]]) ### Single-Point Classification の偽陽性問題 「任意のノードが異常ならクラスタ全体を異常と判定する」Single-Point Classification は、複数ノードの情報を組み合わせると偽陽性が急増する。Low Speed Query 注入の実験では、RobustLog で F1 が 76.71%、LogAnomaly で 58.74% に留まり、実運用の品質基準を満たさない。(Source: [[@2024__KDD__Multivariate Log-based Anomaly Detection for Distributed Database]]) ### 多ノード集約の設計空間 | 手法 | 特徴 | 問題 | |---|---|---| | Single-Point | 任意ノードが異常ならクラスタ異常 | 偽陽性率が高い | | Vote-Based | 多数決による集約 | 再現率が低い(異常見逃し) | | Best-Node | 最高性能ノードに委任 | 実運用不可(理論的上限) | | **MultiLog** | AutoEncoder+メタ分類器で全ノードを統合 | 教師あり、計算コスト増 | ## 代表システム ### MultiLog (KDD 2024) [[Lingzhe Zhang]]・[[Tong Jia]]・[[Ying Li]] ら([[Peking University]])が提案。分散 DB 向け多変量ログベース異常検知フレームワーク。 2 段階のアーキテクチャ: 1. **Standalone Estimation**: LSTM + セルフアテンションで系列・定量・意味の 3 情報を統合し、各ノードの確率系列を生成。 2. **Cluster Classifier**: オートエンコーダで確率系列を固定長に正規化し、メタ分類器でクラスタ全体の異常判定。 実験結果: Multi2Multi データセットで F1 99.82%(LogAnomaly 比 +16.02 ポイント)。(Source: [[@2024__KDD__Multivariate Log-based Anomaly Detection for Distributed Database]]) ### LogDB (J. ACM 2025) MultiLog の**拡張版**。同グループが提案したログベース**障害診断**フレームワーク。タスクを「異常あり/なし」の二値検知から「7 種の障害種別分類」へ拡張した点が最大の差異。 3 モジュールのアーキテクチャ: 1. **Database Log Embedding**: 系列・定量・意味の 3 種の埋め込み(同 MultiLog)。意味埋め込みは FastText + TF-IDF。 2. **Standalone Node Feature Extraction**: LSTM + 自己アテンションで各ノードの異常特徴行列を生成。コンテキストベクトル $c$ と最終隠れ状態 $h_M$ を連結して拡張埋め込みを得る。 3. **Cluster Anomaly Classification**: VAE(変分オートエンコーダ)で全ノード特徴を統合・圧縮し、CNN 分類器で障害種別を識別。系列パディングでノード間の特徴行列長を $\beta$ に統一する。 実験結果(3 ワークロード): TSBS F1 98.06%・TPCx-IoT F1 95.76%・IoT-Benchmark F1 87.62%。Cloud19 比 F1 で最大 +26.83 ポイント。(Source: [[@2025__arXiv__LogDB - Multivariate Log-based Failure Diagnosis for Distributed Databases]]) ## 横断的知見 - **単一情報源では分散 DB の異常を捉えられない**: MultiLog は系列・定量・意味の 3 種の情報を統合することで、どれか一つだけを使うモデルが見逃す異常を捕捉できる。[[@2026__Cluster Computing__Anomaly detection and root-cause identification in microservices - a survey]] が報告する「ログ+トレースの F1 が 3 種統合より高い」という知見と同様、入力の選別が単純な統合より重要な場合がある。(Source: [[@2024__KDD__Multivariate Log-based Anomaly Detection for Distributed Database]]) - **ログイベントの大半は異常検知に無関係で、削減が精度を向上させる**: [[@2024__ESEM__Reducing Events to Augment Log-based Anomaly Detection Models - An Empirical Study]] は 55〜99.9% のイベント削減後に F1 が向上することを実証した。MultiLog が 3 種の情報を活用する一方で、それらの情報の密度(イベントあたりの有用情報量)を高める前処理の重要性を示す。(Source: [[@2024__ESEM__Reducing Events to Augment Log-based Anomaly Detection Models - An Empirical Study]]) - **ログ異常検知は「alert-agnostic だから診断には不十分」という産業側の批判がある**: [[LogPilot]] は、従来のログ異常検知(LogRobust の attention 付き Bi-LSTM、LogAnomaly の template2Vec 等)がアラート固有の文脈を欠き、無関係ログで結果が支配されると批判し、アラート intent ベースのフィルタリングで置換する。MultiLog の分散 DB 特化アプローチは、この「文脈なし検知の限界」に対してドメイン特化という別の解法を示す。(Source: [[@2025__ASE__LogPilot - Intent-aware and Scalable Alert Diagnosis for Large-scale Online Service Systems]]) - **分散 DB のログ異常検知は「どのデータセットで評価するか」が手法の見かけ上の性能を大きく左右する**: Loghub ベースの既存データセット(BGL・HDFS・Thunderbird)と分散 DB データセット(MultiLog Dataset)では、異常の種類・注入方法・ノード間の依存関係が根本的に異なる。Loghub で SOTA を達成したモデルが MultiLog Dataset では大幅に性能低下する事例は、「評価データセットの代表性」が手法評価の根本的な前提条件であることを再確認する。(Source: [[@2024__KDD__Multivariate Log-based Anomaly Detection for Distributed Database]]) - **異常検知から障害診断へのタスク拡張は「単一ノード前提」の根本的な設計の置き換えを要求する**: LogDB([[@2025__arXiv__LogDB - Multivariate Log-based Failure Diagnosis for Distributed Databases]])は MultiLog の 2 値検知(正常/異常)を 7 種の障害種別分類(CPU 飽和・メモリ飽和・ネットワーク帯域制限・エクスポート/インポート操作・バックグラウンドタスク過多・ディスクフラッシュ過多)に拡張した際、既存のグラフベース手法(LogKG・LogCluster)がワークロード変化に追従できず TPCx-IoT で F1 46〜48% に留まることを示した。深層学習ベースの Cloud19 も単一ノード前提ゆえ、クロスノード情報を要する障害種別(エクスポート/インポート)で精度が低い。LogDB は VAE によるクロスノード特徴融合で F1 87〜98% を達成し、「分散 DB の障害診断には構造的にマルチノード集約が必要」という設計命題を定量的に確認した。(Source: [[@2025__arXiv__LogDB - Multivariate Log-based Failure Diagnosis for Distributed Databases]]) - **VAE によるマルチノード特徴融合は、ノード数増加と共に性能が向上するという一方向の収束を示す**: LogDB のノード数感度分析は、シングルノード(TPCx-IoT)で F1 43.34% から全 4 ノード使用で F1 95.76% への単調増加を示す。これは「クロスノード情報の統合が診断精度を律速する」ことを実験的に確認したものであり、分散 DB のスタンドアロン手法の適用限界を定量的な証拠で裏づける。一方で、実運用規模(数十〜数百ノード)での VAE のスケーラビリティは未検証であり、潜在表現の次元 $\theta$ と入力行列長 $\beta$ のチューニングが必要。(Source: [[@2025__arXiv__LogDB - Multivariate Log-based Failure Diagnosis for Distributed Databases]]) - **エクスポート/インポート障害はログ差異が微小でクロスノード情報が不可欠な「難クラス」**: LogDB の障害種別分析において、エクスポート(No.4)・インポート(No.5)操作異常は TSBS ワークロードでも LogDB 自身が 93.33%・92.31% の F1 にとどまる(他の障害種別は 98〜100%)。これらの異常は単一ノードに関係するログが少量で、クロスノード情報なしでは正常操作との区別が困難。「ログのみ」でのドメイン特化でも残る困難クラスがあることを示し、マルチモーダル統合(メトリクス・トレース追加)の必要性を実験的に示唆する。(Source: [[@2025__arXiv__LogDB - Multivariate Log-based Failure Diagnosis for Distributed Databases]]) ## 未解決の問い - MultiLog は教師あり手法であるが、分散 DB の実運用環境でラベル付きデータを収集するコストはどの程度か。Chaos Mesh を使った異常注入による合成ラベルは、実運用の障害パターンと十分に一致するか。 - 分散 DB のリーダー/フォロワー構成に固有の「リーダーのみが特定情報を持つ」非対称性を、MultiLog の Standalone Estimation は十分に捉えられているか。ノード役割(役割情報)をモデルに入力する設計拡張は有効か。 - MultiLog のクラスタサイズ(ノード数 $N$)への感度は未検討。実運用のクラスタサイズ(数十〜数百ノード)では Cluster Classifier のメタ分類器の計算コストと性能がどう変化するか。 - ログベース異常検知とメトリクスベース異常検知の組み合わせは、分散 DB に対してログ単体より有効か。MultiLog が示した「系列・定量・意味の 3 種統合」の効果が、ログ以外のシグナル(メトリクス・トレース)の追加でさらに改善するかの検証が未着手。 - 実際の分散 DB 障害(注入ではなく自然発生)では、MultiLog Dataset の 11 種の異常タクソノミーで網羅できないパターンがどの程度あるか。Open World の未知異常への対応能力が課題。 - LogDB は Apache IoTDB のみで検証されており、他の分散 DB(OceanBase・TiDB・Cassandra 等)への転移可能性は未検証。ストレージエンジン(LSM ツリー vs. B ツリー)・レプリケーションプロトコル(Raft vs. Paxos)・ログ形式の違いが、系列・定量・意味の 3 種の埋め込みにどう影響するか。(Source: [[@2025__arXiv__LogDB - Multivariate Log-based Failure Diagnosis for Distributed Databases]]) - LogDB の VAE によるノード特徴融合は 4 ノード(DataNode × 3 + ConfigNode × 1)での実験にとどまる。実運用規模(数十〜数百ノード)では VAE の入力次元が増加し、潜在表現の品質・訓練安定性・推論レイテンシがどう変化するか。系列パディング長 $\beta$ の最適値もノード数に依存するはずだが、その関係は未分析。(Source: [[@2025__arXiv__LogDB - Multivariate Log-based Failure Diagnosis for Distributed Databases]]) - LogDB が示す「ログのみでの障害種別診断」は、メトリクス・トレースとの組み合わせでどの程度改善するか。著者らは将来的なマルチモーダル統合を課題として挙げるが、エクスポート/インポート障害(ログ差異微小な難クラス)に対する実際の改善幅はいかほどか。「単一モダリティの限界をドメイン特化で補う」vs.「マルチモーダル統合で補う」の費用対効果比較が未着手。(Source: [[@2025__arXiv__LogDB - Multivariate Log-based Failure Diagnosis for Distributed Databases]])