# Optimizing System Monitoring Configurations for Non-Actionable Alerts > [!abstract] 概要(原文 abstract 日本語訳) > 今日の競争的なビジネス環境と IT 環境の複雑さは、効率的かつコスト効果の高いサービス提供を要求する。システムモニタリングは問題検知の自動化された手段であり、インシデントチケットの自動生成と組み合わせて利用される。本論文は、アクションが不要な(non-actionable)チケットを最小化しながら、是正措置が必要なすべてのチケットを保持する新しい方法論とシステムを提案する。提案手法は、過去のアラートと対応するインシデントチケットのオフライン解析に基づき、モニタリング条件(状況)と最適な遅延時間を定義する。予測ルールはカバレッジ・確信度・ルール複雑度を基準とするルールベース学習アルゴリズムで自動生成され、それらの条件と遅延時間は実行時モニタリングシステムへの設定として配備される。 --- ## 論文情報 | 項目 | 内容 | |---|---| | 著者 | [[Liang Tang]], [[Tao Li]] ([[Florida International University]]); [[Florian Pinel]], [[Larisa Shwartz]] ([[IBM T.J. Watson Research Center]]); [[Genady Grabarnik]] ([[St. John's University]]) | | 掲載媒体 | IEEE NOMS 2012 (Network Operations and Management Symposium) | | 発表年 | 2012 | | URL | https://ltangt.github.io/papers/noms2012-situation.pdf | | 実装言語 | Java 1.6 | | データ | IBM Tivoli モニタリングシステムの本番サーバ(2011 年) | --- ## 概要 IT サービス提供者は ITIL が定める問題検知・判定・解決のワークフローに従い、モニタリングシステムが生成したアラートをインシデントチケットとして管理する。しかし、モニタリング条件(状況 situations)を保守的に設定する慣行により、非アクション可能チケット(non-actionable tickets)が大量発生する。SA(システム管理者)がチケットを開いてサーバに接続しても問題が見当たらないケースが頻発し、業務コストを圧迫している。本論文は、アラートを予測ルールで分類し、一定時間のチケット生成遅延(待機時間)を設けることで非アクション可能チケットを削減する手法を提案する。 --- ## 問題設定 ITIL の問題検知ワークフローにおいて、モニタリングシステムは定期的にサーバのメトリクスを計測し、事前定義された閾値や条件(「モニタリング状況 monitoring situations」)に違反するとアラートを発生させる。アラートが指定された遅延時間を超えて持続するとイベントとしてエンタープライズコンソールへ通知され、最終的にインシデントチケットとして起票される。 主要定義(Table I より): | 用語 | 定義 | |---|---| | Non-Actionable Alert | システム管理者が何も操作する必要のないアラート | | Real Alert | サーバ上で是正措置が必要なアラート | | Alert Duration | アラート発生からクリアまでの時間 | | Transient Alert | 担当者がチケットを開く前に自動消滅するアラート | | Non-Actionable Ticket | 非アクション可能アラートから生成されたチケット | | Real Ticket | リアルアラートから生成されたチケット | **重要な観察**: 非アクション可能アラートの大多数は一過性(transient)である。例として、あるソフトウェアサービス状態監視の状況では、非アクション可能アラートの 75% 超が 20 分以内に自動消滅する(Figure 2)。アンチウイルスプロセス(Rtvscan)が CPU スパイクを引き起こす、データベースがディスク容量を事前確保するなど、特定のシステム利用パターンが原因で特定カテゴリのアラートがほぼ全件非アクション可能となるケースがある。 --- ## 提案手法 ### システム全体構成(Figure 4) 5 つのコンポーネントからなるオフライン処理ループ: 1. **Component 1**: 過去のアラートイベントとインシデントチケットの収集 2. **Component 2**: 収集データの前処理(属性値ペアへの変換) 3. **Component 3**: 非アクション可能アラートの予測ルール生成(本手法の核心) 4. **Component 4**: 各ルールの待機時間(waiting time)算出 5. **Component 5**: SA によるレビュー後、本番サーバへの設定配備 処理は月次バッチ(once-a-month)として設計されており、本番システムの設定変更は SA の承認を経て行われる。 ### 予測ルールの定義 予測ルール(predictive rule)はルール条件とアラートラベルの対からなる。ルール条件はリテラルの連言で構成され、各リテラルはイベント属性・関係演算子・定数値の 3 項から成る。 Example 1: `if PROC_CPU_TIME > 50% and PROC_NAME = 'Rtvscan', then non-actionable` ### 予測ルールの生成(Algorithm 1) Srikant & Agrawal (SIGMOD 1996) の量的アソシエーションルールマイニング手法を使用。 1. **Step 1**: 訓練データから `duration > delay_max` の非アクション可能アラートを除外(一過性でないものを排除) 2. **Step 2**: `MineQuantativeRules()` でルール候補を列挙 3. **Step 3**: 各ルールの Laplace 精度を計算: $\text{LaplaceAccuracy}(c_i, \mathcal{D}) = \frac{N(c_i) + 1}{N_{non} + 2}$ where $N(c_i)$ はルール $c_i$ にカバーされるイベント数、$N_{non}$ はデータセット内の全非アクション可能イベント数。非アクション可能イベントである条件付き確率の推定値として機能する。 4. **Step 4**: Laplace 精度の降順でルールを選択し、冗長性(より具体的な低精度ルール)を除去。選択済みルールより具体的(more specific)なルールは破棄する。 **パラメータ**: - `ratio_delay`: リアルアラートのうち遅延が許容される最大割合(SLA・状況の深刻度に基づき SA が設定、0 ≤ ratio_delay ≤ 1) - `delay_max`: リアルアラートの最大許容遅延時間(SLA 準拠) ### 待機時間(Waiting Time)の算出 ルール $p$ の待機時間 $wait_p$ は、そのルールにカバーされる一過性アラートの最大持続時間として定義される: $wait_p = \max_{e \in \mathcal{F}_p} e.duration$ where $\mathcal{F}_p$ はルール $p$ にカバーされる一過性イベントの集合。これにより $wait_p \leq delay_{max}$ が保証され、SLA 違反が起こらない。 ### ルールベース手法を選ぶ理由 1. モニタリング状況自体が量的アソシエーションルールと等価であるため、既存システムへの直接組み込みが容易 2. SA や顧客がルールの正当性を人間の判断で検証できる(例: 「Rtvscan は Norton Anti-Virus なので CPU スパイクは無害」)。SVM やニューラルネットワークは精度が高くても、監視設定ルールとして実装・説明が困難 --- ## 新規性 - **チケット生成の遅延**というアプローチ: アラートを「本当のリアルアラートか否か」を分類する代わりに、チケット生成を一定時間遅らせ、一過性アラートは自然消滅を待つ。リアルアラートであっても SLA の許す範囲で遅延するため false negative(見逃し)は発生しない。 - モニタリング状況(situations)の自動最適化: 既存のルールベースモニタリングシステム(IBM Tivoli)のアーキテクチャに沿い、変換・学習結果をそのまま「状況設定」として配備できる。 - 比較対象の Revalidate([9]) は全チケットを遅延させる一律手法であるのに対し、本手法はリアルチケットへの遅延を最小化しながら非アクション可能チケットを選択的に排除する点で優位。 --- ## 実験設定 IBM Tivoli モニタリングシステムの本番サーバから収集した 2011 年の実データを使用(Table II): | データセット | 総イベント数 | 非アクション可能イベント数 | 属性数 | 状況数 | ノード数 | |---|---|---|---|---|---| | Account1 | 18,974 | 9,281 | 33 | 73 | 989 | | Account2 | 50,377 | 39,971 | 1,082 | 320 | 1,212 | 各データセットは 3 ヶ月間のデータ。設定値: `delay_max = 360 分`、`ratio_delay = 0.25`。 --- ## 実験結果 ### 全体性能(Table III・IV、Figure 5・6) - **Account1**: 非アクション可能チケットの 25% 超を削減、リアルチケットの遅延は 3% 未満 - **Account2**: 非アクション可能チケットの 75% 超を削減、リアルチケットの遅延は 3% 未満 Account2 の方が性能が高い理由: 非アクション可能アラートの比率が高く(39,971/50,377 ≈ 79%)、イベント属性数が多いため(1,082 属性)、予測ルールの抽出余地が大きい。 ### 代表的な発見ルール(Table III - Account1) | 状況 | ルール条件 | 待機時間 | 削減 FP | 遅延 FD | |---|---|---|---|---| | prccpu_3ntw_std5 | CPU Utilization Proc = conhost | 120 分 | 96 件 | 6 件 | | svc_3ntc_INTEL01 | Service Name = Symantec AntiVirus | 305 分 | 428 件 | 2 件 | ### 代表的な発見ルール(Table IV - Account2) | 状況 | ルール条件 | 待機時間 | 削減 FP | 遅延 FD | |---|---|---|---|---| | cpu_xuxw_std | N/A (条件なし) | 355 分 | 7,093 件 | 5 件 | | fss_xuxw_std | inodes used <= 1616 and mount point u = /logs | 285 分 | 12 件 | 2 件 | `cpu_xuxw_std` の「条件なし」ルールは、当該状況で発生する全アラートがほぼ非アクション可能であることを意味する。 ### Revalidate との比較(Figure 5d・6d) Revalidate は全件遅延させるため非アクション可能チケット削減率は高いが、リアルチケットへの遅延は本手法の 1,000〜10,000 倍に達する。 ### パラメータ感度(Figure 5e,f・6e,f) - `delay_max` を変化させても性能変化は小さい(非アクション可能アラートの大半が 60 分以内に消滅するため 60〜360 分の範囲で差が出にくい) - `ratio_delay` を増やすと FP(削減)も FD(遅延)も増加する(トレードオフ) --- ## 考察 - 重複ルールの問題: 同一内容だが属性名が異なる場合に同一ルールが複数生成される(例: `mount_point_u` と `sub_origin` が同一内容)。SA によるレビュー段階で識別可能と想定しているが、自動的な重複排除は未解決。 - 動的環境への適用: 本手法は「静的ネットワーク・システム」を対象とし、1〜3 ヶ月ごとに設定が変わる前提でモニタリングライフサイクルとして運用される。デイリー更新には不向き(日次では事例が少なく SA の確信度が得られない)。 - 一過性アラートが真の問題の兆候である可能性: 後続のリアルアラートが別途発生することを前提に、一過性アラートを意図的に非アクション可能と見なす設計上の選択。 --- ## 強み - **SLA 安全保証**: `wait_p ≤ delay_max` の数学的保証により、リアルチケットが SLA を超えて遅延することがない - **人間可読性**: ルールが自然言語に近い形で表現されるため、SA や顧客が内容を検証できる - **既存システム統合**: IBM Tivoli のアーキテクチャと整合し、学習結果をそのままモニタリング設定として配備できる - **低データ依存性**: SA が 10% 程度の訓練データで学習できる(Testing Data Ratio = 0.9 の実験で有効性を確認) --- ## 弱点・課題 - **静的環境限定**: 動的・頻繁に変化する IT 環境には月次バッチ処理の粒度が合わない可能性がある - **属性重複の未解決**: 同一内容の異なる属性名を持つ重複ルールへの自動対処がない - **Account1 での限定的性能**: 属性数が少なく(33)非アクション可能率も低い環境では削減率が 25% にとどまる - **トランジェントアラートのみが対象**: 長時間持続する非アクション可能アラートへの対処は範囲外 - **予測手法の相互比較の制限**: false negative を許さない制約から、予測精度が高い SVM 等の機械学習手法との公平な比較ができていない - **2012 年時点の知見**: クラウドネイティブ・マイクロサービス環境での適用性は未検証 --- ## 関連ソース(wiki 内) - 本ソース内の著者 [[Liang Tang]] は LogTree([23])・LogSig([24])の著者でもあり、ログ解析→イベント生成という系譜でアラート管理に継続的に関与する - [[IBM T.J. Watson Research Center]] は本論文当時から AIOps 領域の中心的研究機関として位置づけられる(後続の [[IBM Research]] ページと接続) --- ## 出典 - PDF: [[.raw/papers/noms2012-situation.pdf]] - URL: https://ltangt.github.io/papers/noms2012-situation.pdf