# Log Clustering Based Problem Identification for Online Service Systems ## 概要 本論文は、大規模オンラインサービスシステムのログ解析を通じた問題特定を支援する手法 LogCluster を提案する。[[Qingwei Lin]] ・[[Hongyu Zhang]] ・[[Jian-Guang Lou]] ・Yu Zhang・Xuewei Chen(すべて [[Microsoft Research]] 北京または Microsoft Corporation Redmond)による研究で、ICSE 2016 Companion として Austin, TX にて 2016 年 5 月に発表された。DOI: `10.1145/2889160.2889232`。 4 年間にわたる Microsoft サービスチームとの共同研究から生まれたアプローチで、2013 年 ICSE(Shang+)の手法を進化させ、ログ系列のクラスタリングと知識ベースによる再発障害の識別を組み合わせることで、問題特定の手間と精度を改善する。 ## 問題設定 大規模オンラインサービスのログには以下の特性がある(Microsoft との共同研究から導出)。 1. **膨大なログ量**: 大規模サービスでは 1 日あたり数十テラバイト、場合によっては 1 ペタバイトを超えるログが生成される。 2. **フェイルオーバー機構による偽陽性**: フェイルオーバーにより "kill"・"fail" キーワードを含む正常動作ログが多数生成され、単純なキーワード検索では偽陽性が多発する。 3. **再発障害の多さ**: 根本原因を修正する前に一時的な回避策(サーバ再起動など)を採ることが多いため、同じ障害が繰り返し発生し、過去に対処済みのログを再度確認する無駄が生じる。 4. **ログメッセージの多様性**: 同一障害でも実行パスの違い・環境変化・機能追加により、ログ系列の内容が大きく異なる。 既存の ICSE 2013 手法(Shang+)は本番環境とテスト環境のログ系列差分を比較するが、(a) 適合率が低い(10〜38%)、(b) 再発障害を識別できないという制限がある。 ## 提案手法 — LogCluster LogCluster は**構築フェーズ**と**本番フェーズ**の 2 段階で動作する。 ### 3.1 ログベクトル化(Log Vectorization) 生ログメッセージを [[ログパース]] 技術でログイベントに変換した後、同一タスク ID のイベントを結合してログ系列を構成する。ログ系列はイベントの重み付きベクトルとして表現する。 **IDF ベース重み付け**: イベントを「語」、ログ系列を「文書」とみなして逆文書頻度を計算する。多くの系列に頻出するイベントは弁別力が低いとみなし低重みを与える。 $w_{idf}(t) = \log\left(\frac{N}{n_t}\right)$ **対比重み付け(Contrast-based)**: テスト環境に現れず本番環境のみに現れるイベントを高重みとする(重み=1)、両環境に現れるイベントは低重み(重み=0)とする。本番のみに現れるイベントは障害を反映しやすいという考え方。 $w_{con}(t) = \begin{cases} 1 & \text{if } t \text{ appears only in production} \\ 0 & \text{otherwise} \end{cases}$ 最終的な重みは IDF 重みを Sigmoid 関数で正規化した値と対比重みの平均: $w(t) = 0.5 \times \text{Norm}(w_{idf}(t)) + 0.5 \times w_{con}(t)$ ### 3.2 ログクラスタリング(Log Clustering) ベクトル化したログ系列間のコサイン類似度を計算し、**凝集型階層クラスタリング(Agglomerative Hierarchical Clustering)**を適用して類似系列をまとめる。距離尺度にはクラスタ内の全要素ペアの最大距離を採用(完全連結法)。距離閾値 θ(デフォルト 0.5)を停止基準とする。 ### 3.3 代表系列の抽出(Extracting Representative Log Sequence) 各クラスタから重心に最も近い系列(クラスタ内の他系列との平均距離が最小)を代表系列として選択する。 $\text{Score}(i) = \frac{1}{n-1} \sum_{j=1}^{n}(1 - \text{Similarity}(S_i, S_j))$ ### 3.4 再発確認(Checking Recurrence) 知識ベースには過去のクラスタの代表系列と対応する緩和策(mitigation)が蓄積されている。新しいクラスタの代表系列を知識ベースと照合(コサイン類似度・閾値 θ を使用)し、既知の再発障害かどうかを判定する。 - **再発**: 対応する緩和策を取得して返却(人手確認不要)。 - **新規**: 手動確認対象として送付し、知識ベースを更新。 ## 実験設定 評価に使用したシステム: - WordCount(Hadoop に同梱の MapReduce 例題) - PageRank(検索エンジン向けウェブページランキングプログラム) - Microsoft Service X: 世界数百万人を対象とする 3 層アーキテクチャの大規模サービス、3.3 百万件のログメッセージを取得 - Microsoft Service Y: 24 時間・SLA 99.99% のグローバルサービス、10 百万件のログメッセージを取得 比較手法: - 伝統的なキーワード検索(kill/fail/error/exception) - Shang+ ICSE 2013 手法 研究課題: - RQ1: 調査必要なログ系列数の削減効果 - RQ2: 問題特定の精度 - RQ3: 距離閾値 θ の影響 ## 実験結果 ### RQ1 — 調査必要系列数の削減 **Hadoop アプリケーション(連続した同種障害)** WordCount でのマシン障害 3 回連続挿入時の調査系列数: - 1 回目: キーワード検索 335件 / ICSE'13 29件 / LogCluster **8件** - 2 回目: キーワード検索 818件 / ICSE'13 40件 / LogCluster **5件**(再発知識が蓄積され削減) - 3 回目: キーワード検索 392件 / ICSE'13 25件 / LogCluster **3件** 再発障害が蓄積されるほど LogCluster の調査件数が減少するという効果が確認された。 **Microsoft 実サービス(表 3)** | サービス | 生ログ数 | キーワード | ICSE'13 | LogCluster | |---|---|---|---|---| | Service X | 3.3 百万 | 278,430件(0.01%) | 522件(0.77%) | **7件(42.86%)** | | Service Y | 10 百万 | 200,119件(0.08%) | 2,433件(2.84%) | **40件(55.00%)** | ### RQ2 — 問題特定の精度 平均適合率(Tables 1〜3 の全実験平均)でキーワード検索・ICSE'13・LogCluster を比較すると、LogCluster が最高値を達成。一部のシナリオ(Network Disconnection の WordCount など)では絶対的な適合率が 66.7% と ICSE'13 等より低い場合もあるが、調査件数が大幅に少ないため実際の調査コストは大きく削減される。 ### RQ3 — 距離閾値 θ の感度 θ が 0.2〜0.8 の範囲内では精度が安定しており、LogCluster は θ に対して頑強である。クラスタリング品質の指標 NMI(Normalized Mutual Information)は全 4 システムで 80% 以上(最高 WordCount 90.42%)。 ## 成功事例 2013 年以来、Microsoft の複数製品チームで本番投入されている。 - **Service A**: Active Monitoring の補完として LogCluster を組み込み、ミッドエイプリル〜ミッドメイの 1 か月間で検出した上位 10 クラスタが 100% 実際の障害に対応。2014 年 7 月にはトポロジーサーバへの異常高頻度呼び出しを検出・修正し、別環境での既知障害の緩和策取得にも成功した。 - **Product G**: 根本原因分析製品に組み込み、クラスタごとに異常スコアを付与することで「Mean Time to Mitigate」と「Mean Time to Fix」を改善。 - **Product L**: 分散ログ分析ツールとして 1 日あたり数テラバイトを処理。初期展開の 2014 年 7 月以来、多数の障害を特定し確認・修正された。 - **Service C**: 400 以上の異なるサービスをホストするハブに適用。初月に 50 サービスのログを分析し、インシデント識別と診断を支援。 ## 教訓 ### ログ重大度レベルの限界 Microsoft の実経験では、高重大度ログ(Exception/Error/Critical)でも 10% 未満しか実際の障害に関係せず、一方 30% 超の障害は INFO レベルのログに関係する。ログ重大度レベルは問題診断の手がかりとして不十分である。 ### ログ系列の順列問題 マルチスレッド処理とクロックドリフトにより、同じ実行でもログの順序が変わる(順列が異なる)。LogCluster は ICSE'13 と同様に順列を区別しない設計を採用している。 ### デプロイ障害のパターン 大規模サービスが初期展開の段階では機能的な障害が多く、安定化すると設定・ネットワーク・ハードウェアなどの環境系デプロイ障害が増える。LogCluster は新規ファームでの新しいログクラスタを検出することでデプロイ障害を識別し、知識ベースから既知の緩和策を取得できる。 ### 分散コンピューティング環境への適応 ログが TB〜PB 規模になるため、LogCluster は分散コンピューティング環境(数十〜数百台のサーバ)に展開される。クラスタリングアルゴリズムとして K-Means・K-Medoids・DBSCAN・階層クラスタリングを比較した結果、階層クラスタリングが分散環境に最も適していた。 ## 新規性・位置づけ - **ICSE'13 との差分**: Shang+ はテスト環境と本番環境の差分系列を比較するが、(a) 系列の繰り返し・並べ替えしか考慮せず類似性評価が粗い、(b) 過去の既知障害を活用しない。LogCluster は IDF×対比の重み付きコサイン類似度と凝集型階層クラスタリングで類似性をより精密に評価し、知識ベースで再発を識別する。 - **キーワード検索との差分**: キーワードに依存しないため、フェイルオーバーが生む "kill"/"fail" キーワードの偽陽性を回避できる。 ## 強み - 4 年間にわたる Microsoft 本番環境への適用実績があり、有効性が産業規模で確認されている。 - 2 段階フレームワーク(クラスタリング + 知識ベース)は再発障害に強く、運用が進むほど調査件数が減る学習効果がある。 - 距離閾値 θ に対して頑強で、実際のパラメータ調整コストが低い。 ## 弱点・課題 - ログ解析にかかる計算時間の大部分はログパースが占める。ログイベント ID を事前にソースコードに埋め込む設計が望ましいが、すべての製品チームで実施できるわけではない。 - 性能(パフォーマンス)関連の障害は、イベントの時間的順序を考慮しないため検知できない。性能診断には別研究(Lin+ の Log2 など)が必要。 - 知識ベースに誤りが混入した場合の影響評価や、知識ベースの更新・品質管理の仕組みは詳述されていない。 - 実験の障害注入数が少なく、一般化には追加の実証が必要。 ## 関連 - 参照 source: [[@2019__WWW__Outage Prediction and Diagnosis for Cloud Service Systems]](LogCluster を含む Microsoft AIOps 系譜の後期に位置する同グループの研究) - 関連概念: [[ログ解析]] / [[ログパース]] / [[ログクラスタリング]] / [[根本原因分析]] / [[AIOps]] - 関連エンティティ: [[Qingwei Lin]] / [[Hongyu Zhang]] / [[Jian-Guang Lou]] / [[Microsoft Research]] ## 出典 - 本ページの主な出典は原論文テキスト全文: `.raw/papers/Lin-et-al.-2016---Log-clustering-based-problem-identification-for-online-service-systems.txt`