# Dynamic Alert Suppression Policy for Noise Reduction in AIOps > [!abstract] 概要(ABSTRACT の日本語訳) > IT 環境が規模・複雑性の両面で進化するにつれ、健全性を監視するためのオブザーバビリティツールが求められるようになった。異常なイベントが検知されるとアラートが生成され、サイト信頼性エンジニア(SRE)へのアラート通知につながる。しかしこれらの通知の多くは誤報(false alarm)であり、アラート疲労や非効率性をもたらす。アラートノイズを削減するための既存アプローチは、動的な IT 環境の変化に素早く陳腐化する静的ポリシーに依存しており、保守が困難である。本研究では、よく知られた移動平均エンベロープ統計手法に着想を得た、新しい教師なしアプローチ Dynamic-X-Y を提案する。このアプローチは、過去のアラートとイベントデータから各メトリクスまたはサービスに対して個別のアラート抑制ポリシーを学習する。実行時には、これらの学習済みポリシーが入力イベント/アラートに適用され、誤ったアラート通知を削減する。ログ異常とメトリクス異常の 2 種のデータセットで手法を検証し、最先端手法に対して正解率でそれぞれ 7.39% および 35.7% の向上を示す。 ## 論文情報 - **タイトル**: Dynamic Alert Suppression Policy for Noise Reduction in AIOps - **著者**: Karan Bhukar(IBM India Research Laboratory), Harshit Kumar(IBM India Research Laboratory), Seema Nagar(IBM India Research Laboratory), Pooja Aggarwal(IBM India Research Laboratory), Rohan Arora(IBM T.J. Watson Research Center), Ruchi Mahindru(IBM T.J. Watson Research Center), Amit Paradkar(IBM T.J. Watson Research Center) - **媒体**: ICSE-SEIP 2024 (IEEE/ACM 46th International Conference on Software Engineering: Software Engineering in Practice) - **発表年月**: 2024年4月、Lisbon, Portugal - **DOI**: https://doi.org/10.1145/3639477.3639752 - **IEEE Xplore**: https://ieeexplore.ieee.org/document/10554731 ## 概要 本論文は、クラウド AIOps 環境における SRE のアラート疲労問題に対し、教師なし統計学習による **動的アラート抑制ポリシー(Alert Suppression Policy: ASP)** の自動生成手法 **Dynamic-X-Y** を提案する。ASP は「X イベントが Y 時間内に観測されたらアラートを解除する」という閾値ポリシーで、従来は専門家が手動で設定していた。Dynamic-X-Y は各メトリクス・マイクロサービスの過去イベント時系列から **持続領域(Persistent Region)** を統計的に検出し、各項目に個別の X・Y 値を自動学習する。メトリクスとログの 2 データセットで既存の静的手法を有意に上回る性能を示し、IBM の産業ツールへの統合も実証した。 ## 問題設定 ### 背景と動機 クラウド上のマイクロサービスアプリケーションでは、異常検知アルゴリズムが大量のイベントを生成し、それがアラートとして SRE に通知される。多くのアラートは短命(short-lived)であり、イベントが自動解消するにもかかわらず SRE に通知されてしまう「ノイズ」となる。この状況はアラート疲労を引き起こし、SRE が真に重要なアラートを見過ごすリスクを生む。(Source: §1) ### 静的ポリシーの限界 「X イベントが Y 時間内」という形式のポリシー(ASP)は既存製品(Splunk・Datadog・Instana)でも採用されているが、手動定義の静的ポリシーは以下の課題を持つ。(Source: §1) 1. **ドメイン知識依存**: 専門家の経験に基づくため、全指標・全サービスを網羅するポリシー設計が困難 2. **動的環境への不適応**: 同一アプリケーションスタックでもワークロードパターンの変化でポリシーが陳腐化 3. **非スケーラブル**: 大量のメトリクス名・サービス名への個別設定は非現実的 ## 提案手法 ### アーキテクチャ概要 Dynamic-X-Y は 3 つのモジュールから構成される。(Source: §2) 1. **Persistent Regions Detection(PRD)**: 過去イベント時系列 Ω から統計的に持続領域を検出 2. **X-Y Computation**: 検出した持続領域から X(イベント数)・Y(時間幅)の最適値を算出 3. **Inference(推論)**: 実行時に到着するイベント/アラートに学習済み ASP を適用 ### Persistent Regions Detection(PRD) の詳細 PRD は 3 段階で動作する。(Source: §2.2) **1. ピーク検出(Peak Detection)** スライディングウィンドウ SW₁(ウィンドウ幅 W₁=20分、ストライド S₁=5分)でイベント時系列 Ω を走査し、時変イベント頻度ベクトル H を算出する(式 1)。H の中から **Bollinger Bands**(金融分野で広く使われる移動平均エンベロープ手法)の上限帯(UBB)を超えるインデックスをピークとして検出する(式 2・3)。ピーク検出のパラメータは N=40、τ=3.5 で経験的に決定された。出力はバイナリベクトル F。 **2. 密ピーク検出(Dense Peak Detection)** SW₂(W₂=3、S₂=1、密度閾値 D=2)で F を走査し、連続するピーク信号が密に集まる候補持続領域ベクトル K を生成する(式 4・5)。孤立した一時的イベントをフィルタリングする。 **3. 統合と選択(Merging and Selection)** - **統合**: 隣接する(ω=15分以内の)候補持続領域を 1 つの持続領域にマージ - **選択**: マージ後の持続領域の持続時間が β(width-cutoff=15分)を超えるものを最終持続領域として採択 各最終持続領域は (Start, End, EventFrequency, Duration) の 4 値で表現される。 ### X-Y 値の計算 各項目 mᵢ の複数リソースにわたる持続領域リスト Pᵢ から X・Y を算出する(式 6〜8)。 - **量子持続領域 Q**: Pᵢ 内で最小 Duration を持つ持続領域を基準として採択 - **X**: Q の Duration でスケーリングした各持続領域のイベント頻度の中央値(Median(X)) - **Y**: Q.Duration この設計により、持続領域の持続時間が異なっても比較可能なイベント頻度の代表値を得られる。 ### 推論(Inference) 実行時に、到着するイベントが既存アラートに紐付けられてイベントカウントが更新される。アラートのイベントカウントが ASP で定めた X イベントを Y 時間内で超えれば、アラートが「解除(unsuppress)」されて SRE に通知される。条件を満たさない場合はアラートは「抑制(suppress)」のまま維持される。(Source: §2.4) ## 新規性 - **先行研究との違い**: Shin & Jeong 2006、Zhao+ 2020 らが手動定義の静的 ASP を提案したのに対し、Dynamic-X-Y は過去データから **各項目に個別の ASP を教師なしで自動学習** する初の手法。Splunk の suppression groups・Datadog の downtime API・Instana の Smart Alerts はいずれも動的なポリシー自動生成機能を持たない。(Source: §6) - **ピーク検出の新規性**: 移動平均エンベロープベースのピーク検出モジュールと密ピーク検出モジュールを組み合わせて長時間の持続ピークを効率的に捕捉する構成は、本論文が初出と著者らは主張する。Bollinger Bands 自体は金融分野で広く使われているが、AIOps のアラート抑制ポリシー学習への適用は新規。(Source: §6) ## 実験設定 ### データセット | 項目 | メトリクスデータセット | ログデータセット | |---|---|---| | データ種別 | クラウド上の VM のメトリクス | 会話アプリケーションのログ | | 期間 | 14 日間 | 2 年間 | | メトリクス/サービス数 | 52 メトリクス | 15 マイクロサービス | | リソース数 | 1,836 | — | | 有効 metric-resource ペア | 3,576 | — | | 検出イベント数 | 56,442 | 137,269 | | 連続異常イベントの平均持続時間 | 約 53分 (11イベント) | 約 87時間 (2,691イベント) | アノテーション: ドメイン専門家が各時系列を目視し持続領域かどうかをラベル付け。ラベル付き時系列は 38 本(メトリクス)・12 本(ログ)。(Source: §3.1, §3.2, Table 2) ### ベースライン 1. **No-Suppression**: 異常イベントが 1 件以上あれば持続領域とみなすデフォルト動作(X=1 相当) 2. **Static-X-Y**: 専門家が設定する静的 ASP。本実験では X=6、Y=30分 ### 評価指標 持続領域検出の精度を TP・FP・TN・FN で測定し、F1 スコアと正解率(Accuracy)を算出。(Source: §3.4) ## 実験結果 ### 主要性能比較(Table 3) | 手法 | ログ F1 | ログ Acc. | メトリクス F1 | メトリクス Acc. | |---|---|---|---|---| | No-Suppression | 64.89 | 50.23 | 43.20 | 64.41 | | Static-X-Y | 64.70 | 50.90 | 83.90 | 87.46 | | Dynamic-X-Y (提案) | **66.00** | **69.09** | **92.61** | **93.93** | - メトリクスデータセット: No-Suppression 比 +45.8%、Static-X-Y 比 +7.4% の正解率改善 - ログデータセット: No-Suppression 比 +37.5%、Static-X-Y 比 +35.7% の正解率改善 ログデータセットで Static-X-Y が No-Suppression と同等に劣化する原因: ログ持続領域の平均イベント数(2,691)が Static-X-Y の X=6 を大幅に上回るため、Static-X-Y が事実上 No-Suppression と同じ判定をしてしまう。(Source: §4.1) ### 教師なし vs 教師あり設定(§4.2) メトリクスデータで 66 通りの (X, Y) ペアをブルートフォース探索した最適値は X=9、Y=50 (正解率 94.42%)。Dynamic-X-Y が教師なしで学習した X・Y の全メトリクス平均は X=9.06、Y=54.06 で、最適値にほぼ一致する。これは教師なし手法がラベル付きデータなしで上界近傍の性能を達成できることを示す。(Source: §4.2) ### アブレーション研究(§4.3) **Width-Cutoff (β) の影響(Table 5)** β=15 が最適 (F1=92.61、Acc=93.93)。β が低いと過剰なポリシーが生成され小さい X 値でノイズが増加、β が高いとポリシー数が少なすぎて No-Suppression 扱いが増え精度が低下。 **Window-Size (W₁) の影響(Table 6)** W₁=10 が最適 (F1=92.61)。W₁ が大きくなるとイベント頻度が窓内で干渉し合い、小さい X のポリシーが過剰生成されて偽陽性が増加する。 **持続領域数 (α) の影響(Table 7)** α=1 が最適 (F1=92.61、Acc=93.93)。α が増えると多くのメトリクスでポリシーが生成されなくなり、No-Suppression 扱いが増えて精度が低下する。 ### 産業事例(§5: TcpRetrans メトリクス) 14 日分・206 異常イベント・13 アラートに対して: - No-Suppression: 13 アラート通知 (全アラート) - Static-X-Y: 9 アラート通知 - Dynamic-X-Y (X=10, Y=50): **5 アラート通知** アラートノイズ削減率: - vs No-Suppression: **61.53% 削減** (13→5) - vs Static-X-Y: **44.44% 削減** (9→5) イベントノイズ削減(SRE が確認すべきイベント数): - 206(No-Suppression)→ 192(Static-X-Y)→ **167(Dynamic-X-Y)** IBM 内部の UI ツール(図 7: 訓練ツール、図 8: Automations Dashboard)に統合済みで、ポリシーのリアルタイム有効化・無効化が可能。(Source: §5.1, §5.2) ## 考察 - **手法の有効性の根拠**: 静的ポリシーが「ドメイン非依存の単一パラメータ」に依存するのに対し、Dynamic-X-Y は各メトリクス/サービスの速度・ピーク・密度という「固有の特性」に合わせた個別 ASP を学習する。ログデータ(平均 X=2376)とメトリクスデータ(平均 X≈9)の値が大きく異なることが、ドメイン横断的な個別化の必要性を裏付ける。(Source: §4.1) - **教師なし設定の実用的意義**: ラベル付きデータの取得は困難であるが、Dynamic-X-Y は教師なしで教師あり最適値に近い X・Y を学習できる。これはラベルコストを要さずに高精度の ASP 自動設定を実現できることを意味する。(Source: §4.2) ## 強み / 弱点・課題 **強み** - 教師なしで動作するためラベル付きデータが不要 - 各メトリクス・サービスに個別最適化された ASP を自動生成できる - IBM 本番ツールへの統合実績があり、産業規模での実用性を示す - アブレーション研究により主要ハイパーパラメータの感度が定量的に明らかになっている **弱点・課題** - ハイパーパラメータ(W₁、β、α、N、τ、ω 等)は経験的に決定されており、データセットが変わった場合の汎化性は不明 - 持続領域がまったく観測されないメトリクス/サービスにはポリシーが学習されず、No-Suppression がデフォルトとして適用される(§3.2) - ラベル付きテストデータは比較的小規模(メトリクス 38 時系列・ログ 12 時系列)であり、より大規模な評価が望ましい - 学習に使う過去データの期間が短い(メトリクス 14 日)場合のポリシー品質の安定性は検証されていない - 本手法は ASP の自動学習に特化しており、アラートの根本原因分析(RCA)や集約は別途必要 ## 関連 - 上位概念: [[アラート管理]](alert determination / noise reduction の文脈) - 隣接概念: [[アラートアンチパターン]](Transient Alerts は本論文の「短命アラート」と同質)、[[アラート集約]](集約とは別問題だが相補的)、[[AIOps]] - 著者所属: [[IBM Research]]、[[Pooja Aggarwal]]、[[Rohan Arora]] - 関連インダストリーツール: Splunk・Datadog・Instana(§6 で比較)