# DEAR: Distributed Evaluation of Alerting Rules > Mathias Mormul, Pascal Hirmer, Christoph Stach, Bernhard Mitschang (University of Stuttgart, IPVS) > IEEE CLOUD 2020 — pp. 158–165, doi: 10.1109/CLOUD49709.2020.00034 ## 概要 大規模クラウド環境の監視では、精度(サンプリング頻度)とネットワーク帯域消費の間に根本的なトレードオフが存在する。集中型エージェントベース監視はデータを集約してから中央サーバへ送るため精度が落ち、完全分散型は管理複雑性が増大する。DEAR はこのトレードオフを解消するモニタリングシステム向けプラグインである。アラートルールを BET(バイナリ式木)に変換して各 VM 上の軽量評価エンジンに自動配布し、アラート判定のみをローカルで行う。ルール管理は中央のアラートフレームワーク上に残すため管理複雑性は増えない。 ## 問題設定 ### クラウド監視の 5 つの課題 論文は C1-C5 として課題を定義する。 - **C1 精度**: 細粒度監視データが信頼性の高い監視には不可欠。CPU 負荷スパイク(図 1 中央)のような一時的な問題を、集約後のデータでは検知できない。 - **C2 ビッグデータ**: 細粒度サンプリングを多数の VM に適用するとデータ量が急増し、ネットワーク帯域とディスクを圧迫する。 - **C3 洞察までの時間(TTI)**: 問題発生から対処までの遅延を最小化しなければならない。集約インターバルが長いほど TTI が悪化する。 - **C4 履歴データ**: 予測分析や根本原因分析のために過去データを保持する必要がある。 - **C5 管理**: IT 部門は人手不足が常態化しており、Single Point of Administration を維持しながら自動化・スケーラビリティを実現しなければならない。 ### 集中型と分散型のトレードオフ | アーキテクチャ | 精度 | ネットワーク量 | 管理複雑性 | |---|---|---|---| | 集中型(エージェント集約) | 低(集約による情報損失) | 低 | 低 | | N 層型 | 中 | 中 | 中 | | 完全分散型 | 高 | 高 | 高 | | **DEAR(提案)** | **高** | **低** | **低** | ## DEAR の設計 ### 全体アーキテクチャ DEAR は既存の集中型監視アーキテクチャにプラグインとして組み込まれる。主要コンポーネントは (a) Alert Transformer & Distributor、(b) Evaluation Engine、(c) Monitoring Data Buffer の 3 つ。 処理フローを以下に示す。 1. 各 VM 上のモニタリングエージェントがメトリクスをサンプリングする。 2. 管理者が中央のアラートフレームワークでアラートルールを定義する。 3. Alert Transformer & Distributor がルール条件を BET に変換し VM の評価エンジンに配布する(3a, 3b)。同時にエージェントの設定を変更し、監視データを評価エンジンへ送るよう再経路設定する(3c)。 4. 評価エンジンがローカルでアラートルールを評価する。判定結果(boolean)のみが中央サーバに送信される。同時に、粗粒度の集約データは引き続き中央データベースへ送信し履歴を維持する。 5. Monitoring Data Buffer がアラート発生時に直近の細粒度データを中央データベースへフラッシュし、根本原因分析に活用できるようにする。 ### Alert Transformer & Distributor DEAR の中心コンポーネント。モジュラーアダプタ設計を採用し、4 種のアダプタで構成される。 **Alerting Framework Adapter** 各アラートフレームワーク(Grafana 等)のルール定義構文をパースして BET に変換する。BET を中間表現とすることで、n アラートフレームワーク × m 評価エンジン = n×m 個必要だった変換を n+m 個に削減する。 **Core(分散処理戦略)** BET の中順走査で最長サブツリーを検出し、各 VM に対応するサブツリーを分配する。複数 VM にまたがるルールは 4 種の分散処理戦略(A-D)で対応する。 - 戦略 A: 各 VM が自身のサブツリーを評価して結果を監視サーバへ送信(基本形)。 - 戦略 B: 一部の VM がローカル評価できない場合に生データを監視サーバへ送信。 - 戦略 C: AND 演算子が最上位ノードの場合、VM 間通信コストが安ければ先発 VM の結果をもう一方に転送し、両サブツリーが true の場合のみ監視サーバへ送信。不要なネットワーク通信を削減。 - 戦略 D: VM 間通信が安く一方が評価不能な場合、生データを VM 間でやり取りして完全な BET を評価。 **Evaluation Engine Adapter** BET を評価エンジン(実装では Esper CEP エンジン)のクエリ言語に変換する。 **Monitoring Agent Adapter** エージェントの設定を変更して監視データの送信先を再経路設定する。Mormul+ が別論文[20]で提案するジェネリックエージェントモデル(入力→処理→集約→出力のパイプライン)を前提とする。変換後は RP1-RP4 の 4 つのルーティングパスで動作する。 | パス | 必須 | 用途 | |---|---|---| | RP1 | 必須 | アラート結果を中央サーバへ送信 | | RP2 | 任意 | 粗粒度集約データを中央 DB へ送信(履歴維持) | | RP3 | 必須 | 細粒度生データをローカル評価エンジンへ送信 | | RP4 | 任意 | 細粒度データをローカルバッファへ送信(根本原因分析用) | ### Evaluation Engine ローカルの軽量アラートフレームワーク。要件は低レイテンシ・高スループット・軽量(CPU/メモリ/IO)・表現力(時間的関係を含むアラートルール対応)。実装では Esper(CEP エンジン)を採用。 ### Monitoring Data Buffer 短期間の監視データを保持するローカルストレージ。アラート発生時のみ細粒度データを中央 DB へフラッシュする。中央サーバの一時障害中のデータロスト防止にもなる。保持期間はディスク容量との兼ね合いで設定する。 ## 評価 ### 実験環境 OpenStack 上の 2 VM(各 2 vCPU, 4GB RAM, Ubuntu 16.04)を使用。TIG スタック(Telegraf + InfluxDB + Grafana)を監視システムとして採用し、評価エンジンに Esper、Monitoring Data Buffer に InfluxDB を利用。 3 設定のアラートルール条件で評価する。 ``` A1: IF CPU.load > 90% A2: IF CPU.load > 90% FOR 10s A3: IF CPU.load > 90% FOR 60s ``` | 設定 | サンプリング頻度 | 集約インターバル Ia | バッファ集約インターバル | |---|---|---|---| | Conf. 1 | 1/s | なし | なし | | Conf. 2 | 1/s | 10s | 10s | | Conf. 3 | 100/s | 60s | なし | ### 評価結果 | 指標 | Conf. 1 | Conf. 2 | Conf. 3 | |---|---|---|---| | ネットワーク通信量(KB) | 2042.52 | 203.01 | 34.12 | | Telegraf CPU 負荷(%) | 0.0 | 0.0 | 2.5 | | Telegraf RAM 負荷(%) | 1.1 | 1.1 | 1.3 | | Esper CPU 負荷(%) | 0.11 | 0.10 | 0.52 | | Esper RAM 負荷(%) | 0.61 | 0.67 | 1.07 | | ディスク使用量(KB) | 300 | 72 | 27965 | | 従来手法の TTI(ms) | 28.8 | 6710.8 | 27211.1 | | DEAR の TTI(ms) | 379.4 | 360.9 | 377.6 | ### 考察 - **C1 精度**: ローカル評価により集約インターバル Ia がアラート精度に影響しなくなる。細粒度データが常に評価に使われる。 - **C2 ネットワーク**: Ia を大きくすれば通信量を削減でき、精度も犠牲にならない(DEAR ではアラート評価と集約データ送信が分離されているため)。 - **C3 TTI**: 集約あり(Conf. 2, 3)の場合、従来手法で TTI が最大 27 秒以上に増大するのに対し、DEAR は約 360-380ms で一定。ただし集約なし(Conf. 1)では DEAR の TTI(379ms)が従来手法(28.8ms)より若干高い(ローカル評価エンジンとの通信パス延長のため)。 - **C4 履歴データ**: RP2(粗粒度集約)と RP4(アラート時細粒度フラッシュ)で履歴を維持。長期トレンド分析には集約データで十分、根本原因分析時は細粒度データを活用できる。 - **C5 管理**: ルール管理は中央のアラートフレームワーク上で変わらず行う。配布と設定変更は DEAR が自動化するため管理者の追加負担なし。 ## 関連研究との位置づけ - **Monalytics(Wang+ 2010, 2011)**: データソース近傍で分析を行うが、軽量分析しか対応せず、履歴データ考慮なし。 - **Hauser+ 2018**: データソースで統計モデルを生成してリソース消費モデルを送信するが、集約により精度が低下する。著者が精度低下を許容すると主張するも根拠がないと批判される。 - **Shao+ 2010**: ランタイムモデルベースで監視データをルールと照合してから送信。同様の思想だが、DEAR の方が自動化・アダプタ設計・履歴データ管理で拡張性が高い。 - **Moogsoft Observe**: データソース近傍での分析だがルールをエージェント上で直接管理するため、大規模環境では管理複雑性が高い。 - **分散 CEP(Schultz-Møller+ 2009, Sun+ 2015)**: CEP クエリの分散処理でネットワーク削減・低レイテンシを実現。DEAR はこのアプローチを取り込みつつ、アラートルール管理・履歴データ記録・既存監視ランドスケープへの埋め込みで拡張する。 ## 将来課題 - 分散 CEP ドメインの分散処理戦略を DEAR に適用する評価。 - より多様なクラウド環境メタデータ(ハイパーバイザ・VM トポロジ等)を活用した処理戦略の自動決定。 - Mormul+ [21] が提案するメタデータ管理フレームワークとの統合。 ## 関連 - 著者: [[Mathias Mormul]] / [[Pascal Hirmer]] / [[Christoph Stach]] / [[Bernhard Mitschang]] - 所属: [[University of Stuttgart]] - 関連概念: クラウド監視 / アラートルール分散評価 / 複合イベント処理(CEP) - 同一著者の別論文: Mormul+ BIS 2020(汎用エージェントテンプレート) / Mormul & Stach PerCom 2020(ITコンテキストモデル) - 関連 wiki 参照: [[structures/LLM4SRE - MOC]] ## 出典 - doi: [10.1109/CLOUD49709.2020.00034](https://doi.org/10.1109/CLOUD49709.2020.00034) - PDF: `.raw/papers/cloud_20_dear.pdf` (MD5: `9dc8218a2b0420b16ac5dde8dbe98f8f`, 8 ページ) - 著者バージョン: https://opencms.uni-stuttgart.de/fak5/ipvs/departments/as/publications/stachch/cloud_20_dear.pdf - 資金: BMWi プロジェクト IC4F (01MA17008G)