@2023__TSC__LogKG - Log Failure Diagnosis through Knowledge Graph

# LogKG: Log Failure Diagnosis through Knowledge Graph ## 論文情報 | 項目 | 内容 | |---|---| | タイトル | LogKG: Log Failure Diagnosis through Knowledge Graph | | 掲載誌 | IEEE Transactions on Services Computing (TSC) | | 著者 | Yicheng Sui, Yuzhe Zhang, Jianjun Sun, Ting Xu, Shenglin Zhang, Zhengdan Li, Yongqian Sun, Fangrui Guo, Junyu Shen, Yuzhi Zhang, Dan Pei, Xiao Yang, Li Yu | | 所属 | [[Nankai University]](第一著者・責任著者)、China Mobile Communications Corporation、[[Tsinghua University]]([[Dan Pei]]) | | 対応著者 | Shenglin Zhang([email protected]) | | データセット公開 | https://anonymous.4open.science/r/LogKG-A6BD | | 実験環境 | CMCC の Jiutian プラットフォーム(TeslaV100・16コアCPU・32GB DRAM) | ## 概要(アブストラクト日本語訳) ログはサービスの動作状態を記述する最も重要なデータの一つである。ログを用いた障害診断はサービスの信頼性とセキュリティにとって不可欠だが、現在の自動ログ障害診断手法はログの複数フィールドを十分に活用できず、フィールド間の関係を捉え損ねている。本論文では、ログの知識グラフ(KG)に基づく障害診断フレームワーク LogKG を提案する。LogKG はログから実体(エンティティ)と関係を完全に抽出し、KG を通じてマルチフィールド情報とその関係をマイニングする。KG が表現する情報を最大限活用するため、障害に特化したログ表現(FOLR)手法を提案し、障害関連パターンを抽出する。OPTICSクラスタリングを用いて、LogKG は過去の障害事例を集約し、典型的な障害事例にラベルを付与して、根本原因を特定する障害診断モデルを訓練する。実世界のログデータセットと公開ログデータセットでの評価により、LogKG が既存手法を上回ることを示した。さらに、世界トップクラスのインターネットサービスプロバイダ(ISP)への展開によって、LogKG の性能と実用性を実証した。 ## 問題設定 ### 背景と動機大規模サービスでは、1 つのサービスが障害を起こすと他のサービスにも連鎖し、数百万ユーザに影響が及ぶ。ログベースの障害診断は根本原因(ネットワーク断・ソフトウェアバグ・ハードウェアクラッシュ・設定誤り等)の特定に広く使われてきた。ログは以下の複数フィールドから構成される: - **構造化フィールド**: タイムスタンプ・ログレベル・IP・コンポーネント・タスクID - **非構造化フィールド**: コンテンツ(自然言語に近いイベント記述) ### 既存手法の課題 1. 既存の多くの手法は非構造化コンテンツフィールドのみを解析し、構造化フィールドの情報を無視する 2. SLOGERT・LEKG など KG を活用する手法も存在するが、構造化フィールドのセマンティクスはマイニングしていない 3. KG ベースログ診断には3つの技術課題が存在する: - **CH.1 エンティティ抽出**: 1 つのログテンプレートが複数イベントを表す場合がある(例: "instance: VAR1 Starting instance do build and run instance VAR2" は「VAR1 is instance」「instance is Starting」など複数イベントを含む) - **CH.2 エンティティアライメント**: 異なるテンプレート上の類似セマンティクスを持つエンティティを同一エンティティに統合する必要がある - **CH.3 障害事例表現**: ノイズログが多く、TF-IDF 等の標準的 NLP 手法では障害に特化した表現が得にくい ## 提案手法: LogKG LogKG はオフライン訓練とオンライン診断の 2 フェーズで構成される。 ### 全体フレームワーク(図3) ``` [Raw Logs] ↓ [エンティティ抽出(§3.2)] → 構造化エンティティ / キーワードエンティティ / イベントエンティティ ↓ [エンティティアライメント(§3.3)] → アライン済みエンティティ ↓ [知識グラフ構築・KGE(§3.4)] → テンプレート埋め込みベクトル ↓ [FOLR(§3.5)] → 障害事例表現ベクトル ↓ [オフライン訓練] クラスタリング → 典型事例に根本原因ラベル付与 [オンライン診断] 新障害 → 既存クラスタに割り当て or 更新 → 根本原因出力 ``` ### エンティティ抽出(§3.2) ログを構造化テキストとテンプレートに分割し、以下の 3 種類のエンティティを抽出する: 1. **構造化エンティティ**: タイムスタンプ・レベル・IP・コンポーネント・タスクID を直接抽出 2. **キーワードエンティティ**: CoreNLP を用いて品詞タグ付けでテンプレートからキーワードを抽出(例: "MySQL"・"DataBase"・"AMQP"・"Error") 3. **イベントエンティティ**: ルール抽出(RE)と OpenIE の組み合わせで意味的トリプル(主語・述語・目的語)を抽出 ### エンティティアライメント(§3.3) - **キーワードアライメント**: CEE ライブラリと領域知識でキーワードをコンセプトエンティティにマッピング(例: "AMQP" → "message middleware") - **トリプルアライメント**: Sentence-BERT ベースの事前訓練モデルでトリプルをベクトル化し、OPTICS クラスタリングで類似セマンティクスのトリプルを同一エンティティにまとめる。これにより CH.1(複数イベント含むテンプレート)と CH.2(異なる構文・同一意味)を解決する。 ### 知識グラフ構築と KGE(§3.4) 構築した KG はエンティティタイプとして Log・RequestID・PID・Level・Component・CEE・Template・Event を持ち、Neo4j グラフデータベースで管理する。 KGE モデルとして RotatE を採用し、エンティティと関係を連続ベクトル空間に埋め込む。各ログテンプレートの埋め込みベクトルを得ることで、多フィールド情報の融合が実現される。 ### FOLR — Failure-Oriented Log Representation(§3.5) 障害発生時刻 τ を中心とした時間窓 ω(= 20 分、前後 10 分ずつ)でログを収集し、以下の手順で障害表現ベクトルを算出する: **IFF(Inverse Failure Frequency)の算出**: $w_{iff}(t) = \begin{cases} \log(N/n_t) & \text{if } \log(N/n_t) \geq \theta_{iff} \\ 0 & \text{otherwise} \end{cases}$ 全障害に頻出するテンプレート(IFF が小さい)は障害非依存のノイズとして閾値 θiff でフィルタリングする。 **TF(Template Frequency)の算出**: $w_{tf}(t, f_i) = \frac{n_{t,i}}{n_i}$ 各テンプレートの障害 f_i における出現頻度を算出する。 **障害表現ベクトル**: $V_i = \sum_{j=1}^{m} w_{tf}(t_j, f_i) \times w_{iff}(t_j) \cdot e_j$ TF-IFF 重み付きの加重和で各障害の表現ベクトルを算出する。 ### 診断(§3.6) **オフライン訓練**: OPTICS(密度ベースクラスタリング)で障害表現ベクトルをクラスタリングし、各クラスタの典型事例(クラスタ重心に最も近い事例)に運用者が根本原因ラベルを付与する。クラスタ数は 10 程度に収まるため、全障害事例をラベル付けするより大幅に省力化できる。 **オンライン診断**: 新規障害発生時にリアルタイムでログを収集・ベクトル化し、既存クラスタに割り当てる。未知の障害種別が出現した場合はクラスタリングモデルを更新する。 ## 実験設定 ### データセット(表5) | データセット | ログ数 | 障害種別数 | 障害事例数 | |---|---|---|---| | GAIA | 13,554,024 | 4 | 1,083 | | CMCC | 1,461,006 | 6 | 93 | - **GAIA**: マイクロサービス障害をシミュレートした公開データセット。ログイン障害・メモリ異常・ファイル未発見・アクセス権限拒否の 4 種別 - **CMCC**: OpenStack ベースの 4G/5G コアネットワーク実環境から収集。AMQP サーバ到達不能・MySQL接続切断・Nova-conductor接続切断・コンピュートノード停止・フレーバーディスク不足・Linuxbridge-agent異常の 6 種別前 70% を訓練データ、後 30% をテストデータとして使用。 ### ベースライン - **LogCluster**: 教師なし。ログシーケンスベクトルのクラスタリングで障害種別を決定 - **Cloud19(Yuan et al., 2019)**: 教師あり。異常ログから表現ベクトルを抽出し、Random Forest で障害種別を分類 ## 実験結果 ### 全体性能(図6) | 手法 | CMCC 精度 | CMCC Macro-F1 | GAIA 精度 | GAIA Macro-F1 | |---|---|---|---|---| | LogKG | **1.00** | **1.00** | **0.98** | **0.99** | | Cloud19 | 0.90 | 0.87 | 0.92 | 0.60 | | LogCluster | 0.96 | 0.96 | 0.29 | 0.29 | GAIA では Cloud19 が精度 0.92 を達成しながら Macro-F1 が 0.60 に留まることから、クラス不均衡に対して脆弱であることが示された。LogKG はマルチフィールド融合による豊かな表現でこの差を克服した。 ### アブレーション研究(図7) - **KGE なし(one-hot ベクトル)**: CMCC/GAIA ともに精度・Macro-F1 が低下 - **KGE を GloVe に置換**: GAIA で大幅低下(Macro-F1 0.84 等)。ログデータは自然言語と異なり繰り返しが多く文法規則に従わないため、GloVe・Word2Vec は不適 - **FOLR なし**: Macro-F1 が 0.08 低下。ノイズログの悪影響が確認された ### ハイパーパラメータ感度(図8) - **θiff(IFF 閾値)**: CMCC では 0.40〜0.50、GAIA では 0.10〜0.20 が最適。小さすぎるとノイズを多く含み、大きすぎると有用なログを捨てる - **MS(OPTICS 最小サンプル数)**: CMCC では 3、GAIA では 10 が最適 - **ω(時間窓長)**: 20〜25 分が最適。短すぎると障害情報を取り逃し、長すぎると非関連ログが混入する ### エンティティアライメントの頑健性(図9・10) 言語モデル(MPNet・RoBERTa・MiniLM)やクラスタリングアルゴリズム(OPTICS・AC・DBSCAN)を変えても CMCC では精度 1.0、GAIA でも精度 0.95 以上を安定して達成する。アライメントの選択が最終診断精度に与える影響は小さい。 ### 障害クラスタリングアルゴリズム(図11) DBSCAN のみが CMCC で大幅に低精度となる。OPTICS・KMeans・AC(d)・AC(n)は GAIA でも 0.95 以上を達成し、KMeans が OPTICS と同等の最高性能を示した。 ## CMCC への本番展開(§5) ### ワークフロー(図12) ``` [ログ収集・処理] Filebeat → Kafka → Logstash → データベース ↓ [障害検知・診断] 障害検知 → LogKG(ログ収集→ベクトル化→クラスタ割当) → 根本原因 ↓ [レポートと通知] Web ページ表示 + SMS + メール送信 ``` ### 実績 - 対象: Guangdong Mobile Communications Co., Ltd(GMCC)、2000 以上のサービスインスタンス、1 日数億件のログを処理 - 5 か月の運用で 1 日平均 47 件の障害を処理 - 1 障害の診断が 5 分以内に完了 - 手動障害緩和時間を平均 20 分以上短縮 - MySQLコンポーネント障害の手動対応では 2500 件超のログを検索する必要があったのに対し、LogKG は自動で根本原因レポートを生成 ## 考察 ### 強み 1. **マルチフィールド融合**: ログの構造化・非構造化フィールドを統合し、既存手法が捉えられなかった障害パターンを抽出できる 2. **ラベリングコスト削減**: クラスタリング + 典型事例ラベル付けにより、全障害事例への正解付与が不要になる(クラスタ数 ≈ 10 のみ) 3. **新規障害種別への適応**: オンライン診断でクラスタを動的更新し、未知の障害タイプにも対応できる 4. **エンティティアライメントの頑健性**: 言語モデルやクラスタリングの選択に依存しない安定性 5. **実本番実績**: 世界規模 ISP での 5 か月展開による実用性の実証 ### 弱点・課題 1. **ログテンプレート品質依存**: 複雑なテンプレートや不良フォーマットの場合、マルチフィールド抽出の精度が低下する 2. **時間窓の固定設計**: 障害の種類によって適切な ω が異なり、実環境では障害継続時間が不定なため調整が難しい 3. **実験規模の限界**: CMCC データセット 93 件は小規模で、大規模システムでの評価が不十分 4. **LogM との比較**: KG を利用する先行手法 LogM は事前知識を必要とするため比較外とされているが、事前知識を必要とする高精度手法との本格比較がない 5. **シングルモダリティ**: ログのみを扱い、メトリクスや分散トレーシングとの統合は将来課題 ## 関連 - 実体: [[Yicheng Sui]] / [[Shenglin Zhang]] / [[Dan Pei]] / [[Nankai University]] / [[Tsinghua University]] - 概念: [[ログ解析]] / [[根本原因分析]] / [[知識グラフ]] - 比較手法: LogCluster / Cloud19(Yuan et al. 2019) / SLOGERT / LEKG / LogM / LOGAN / Onion / FDiagV3 ## 出典 - Yicheng Sui et al., "LogKG: Log Failure Diagnosis through Knowledge Graph," IEEE Transactions on Services Computing (TSC).