# アラート相関 ## 定義 アラート相関（alert correlation）は、分散システムの障害発生時に同時多発するアラート群から、サービス間の依存関係やメトリクスの時間的パターンを用いて根本原因のサービスを推定する取り組みである。マイクロサービスアーキテクチャでは 1 つの障害が連鎖的にアラートを引き起こすため、「干し草の中の針」問題を解決して MTTR の短縮と誤エスカレーションの削減を目指す。 LinkedIn の実装（AC Engine）では、Callgraph（サービス依存グラフ）からエンドポイント間の関係を取得し、Autoalerts からのアラートと相関を取って根本原因候補を推定する。推定結果は Confidence・Severity スコア付きで Slack・Iris・Web UI に配信される。([[@2021__SREcon21__Spike Detection in Alert Correlation at LinkedIn]] p.10–12) ## スパイク分離の課題 アラート相関は依存関係ベースで根本原因を推定するが、推定結果に一時的なスパイク（統計的外れ値だが実際の障害ではないレイテンシ急増）が含まれうる。「相関は因果を意味しない」（p.16）という原則のとおり、相関結果をそのまま信頼すると誤エスカレーションにつながる。LinkedIn では修正 Z スコア（MAD ベース）による外れ値検知を後段フィルタとして組み込み、スパイクと真のアラートを分離した。 ## 横断的知見 - **アラート相関の出力フィルタリングは denoise の一形態だが、技術的アプローチが異なる**: LinkedIn のスパイク検知は時系列メトリクスの統計的外れ値判定（修正 Z スコア）で相関結果をフィルタリングするのに対し、[[AlertGuardian]]（[[@2025__ASE__AlertGuardian - Intelligent Alert Life-Cycle Management for Large-scale Cloud Systems]]）はグラフモデル（GraphGuardian）+ 仮想ノイズノード + 属性匿名化でアラートそのものを denoise する。前者は相関結果の信頼度を後段で検証し、後者は相関の入力段でノイズを除去する——介入点が異なるが、いずれも「誤エスカレーション削減」という同じ目標に向かう。(Source: [[@2021__SREcon21__Spike Detection in Alert Correlation at LinkedIn]], [[@2025__ASE__AlertGuardian - Intelligent Alert Life-Cycle Management for Large-scale Cloud Systems]]) - **「ML なしの単純な統計手法で十分」という知見は、検知/denoise 段で軽量手法が産業で選択される傾向の一例である**: LinkedIn が ML を使わず修正 Z スコアで 30–40% のトイル削減を達成した事実は、[[AlertGuardian]] が denoise 段に LLM でなく軽量グラフモデルを選ぶ判断、[[Minder]] がメトリクス類似度で故障を検知する判断と同じ「検知/denoise の段は軽量手法が有利」という産業の収束した選択に属する。(Source: [[@2021__SREcon21__Spike Detection in Alert Correlation at LinkedIn]], [[@2025__ASE__AlertGuardian - Intelligent Alert Life-Cycle Management for Large-scale Cloud Systems]]) - **アラート間の依存規則(有向・ラグ付き・確率付き)からアラートグラフを構築し、その上で『修正すべき k 個の重要アラート』を選ぶ下流最適化(重要アラートマイニング、CAM)は劣モジュラ貪欲近似で解ける**。相関(依存規則)の学習自体は既存手法(Granger 因果性等)に委ね、相関グラフを前提にした優先順位付けとして定式化される点が新しい (Source: [[@2014__KDD__Towards Scalable Critical Alert Mining]])。 - [定義] Wardenのインシデント指示アラート識別(Group Shapely Value, GSV)は、アラート信号のグループ単位でモデル出力への寄与度を評価する点で、Callgraphベースの根本原因サービス推定とはアプローチの系譜が異なる。前者はモデル解釈由来、後者はサービス依存グラフ由来である (Source: [[@2021__ATC__Fighting the Fog of War - Automated Incident Detection for Cloud Systems]]) - [スパイク分離の課題] 従属イベントの相関を分散して並行化すると、ドメイン境界をまたぐ障害で根本原因が判定不能になりうる。ルートクロージャ(ドメイン内の任意 2 機器間の経路が同ドメインに閉じる条件)を満たす分割なら判定不能を排除でき、境界機器のイベントだけを上位の super-RCA で相関すればよい。分割数 p の分散相関は集中型に対しスループットが約 p の 2 乗、遅延が約 p 改善し、抑制したシンプトム数は集中型と一致した(Source: [[@2009__SRDS__A Framework for Distributed Monitoring and Root Cause Analysis for Large IP Networks]])。 ## 未解決の問い - LinkedIn のスパイク判定ルール（「5 連続スパイク + 70% 同傾向 = REAL ALERT」）の閾値はどう決められたか。閾値の感度分析やサービス種別ごとの最適値は公開情報からは不明。 - 評価期間が約 5 日間・193 件と短い。長期運用でのスパイク/REAL ALERT 比率の安定性、季節変動やデプロイ起因の偽陰性率は未検証。 - アラート相関の出力に対する後段フィルタ（本発表）と入力段 denoise（[[AlertGuardian]]）は組み合わせ可能か。両段を併用したときの効果は加算的か、重複するか。 - アラート相関グラフの動的な再構築(オンライン更新)と、重要アラートの再計算はどのように統合できるか。 - Wardenのアラート信号グルーピング(履歴上の頻出リンク・同一クラスタからの短時間発火)は、LinkedInのCallgraphベース相関と組み合わせ可能か。両者は異なる情報源(履歴共起 vs サービス依存関係)を使うため、併用でrecallまたは精度が向上する余地があるか。 - ルートクロージャの成立を前提にしない現代のマイクロサービスの依存グラフ(動的で冗長な呼び出し経路)で、ドメイン間の判定不能を避ける分割条件を定義できるか。 ## 関連 - ソース: [[@2021__SREcon21__Spike Detection in Alert Correlation at LinkedIn]] / [[@2014__KDD__Towards Scalable Critical Alert Mining]] / [[@2021__ATC__Fighting the Fog of War - Automated Incident Detection for Cloud Systems]] / [[@2009__SRDS__A Framework for Distributed Monitoring and Root Cause Analysis for Large IP Networks]] - 概念: [[異常検知]] / [[アラート管理]] / [[根本原因分析]] / [[アクショナブルアラート]] / [[重要アラートマイニング]] / [[ネットワーク監視]] / [[アラート抑制]] - エンティティ: [[LinkedIn]] / [[Nishant Singh]] / [[AlertGuardian]] ## 出典 - [[@2021__SREcon21__Spike Detection in Alert Correlation at LinkedIn]]（p.10–12 AC Engine アーキテクチャ、p.19 修正 Z スコア、p.24 判定ルール、p.28 評価結果） - [[@2014__KDD__Towards Scalable Critical Alert Mining]](依存規則からのアラートグラフ構築と重要アラート選定) - [[@2021__ATC__Fighting the Fog of War - Automated Incident Detection for Cloud Systems]](GSVによるアラート信号グループ単位のモデル解釈で、インシデント指示アラートを識別する事例として参照。) - [[@2009__SRDS__A Framework for Distributed Monitoring and Root Cause Analysis for Large IP Networks]](ルートクロージャを満たす分割と super-RCA によるドメイン間イベント相関)