Application Real-Time Monitoring Service (ARMS) のアラート管理は、アラート収束、アラート通知、自動エスカレーションなどの機能を提供し、アラートを効率的に特定して処理するのに役立ちます。このトピックでは、アラート管理のアーキテクチャと利点について説明します。
背景情報
Serverless App Engine (SAE) は、ARMS のアラート管理サブサービスと統合されています。ARMS の新しいアラート管理サブサービスは、2021 年 4 月 30 日 00:00 以降に SAE をアクティブ化した Alibaba Cloud アカウントのみが利用できます。
アーキテクチャ
アラート管理は、統合管理、アラートイベント管理、通知ポリシー管理、共同アラート処理、アラート処理分析などのモジュールを提供します。
統合管理
アラート管理は、デフォルトのアラート統合とサードパーティサービス統合の 2 種類の統合タイプを提供します。
デフォルトのアラート統合
アラート管理を、アプリケーション監視、ブラウザ監視、Managed Service for Prometheus、Synthetic Monitoring などの ARMS サブサービスのアラートと統合できます。デフォルトのアラート統合を使用して、定期的なタスクに基づいてモニタリングデータにエラーが含まれているかどうかを確認できます。モニタリングデータにエラーが含まれている場合、対応するアラートイベントがイベント管理センターに報告されます。
サードパーティサービス統合
簡単な設定を行うことで、アラート管理をサードパーティのアラートソースと統合できます。これは、ARMS で自己管理型のデータセンターまたは仮想マシンによって生成されたアラートを処理するためのワンストップソリューションです。サードパーティのアラートソースからアラート管理にアラートが報告されると、アラートイベントが生成されます。アラートイベントには次の制限があります。
アラートイベントのデータ構造
ARMS アラートイベントのデータ構造は、オープンソースの AlertManager の通知テンプレートのデータ構造に似ています。データ構造には次のフィールドが含まれます。
Labels: アラートのメタデータです。ラベルのセットは、アラートイベントを一意に識別します。同じラベルを持つアラートイベントは、1 つのイベントに圧縮されます。例:
"alertname: alert name"。Annotations: アラートの追加情報です。Annotations はメタデータではありません。例:
"message: alert content"。StartsAt: アラートの開始時刻。
EndsAt: アラートの終了時刻。
GeneratorUrl: アラートイベントの URL。
ラベルとアノテーションの違い
ラベルのセットはアラートイベントを指定します。ラベルが変更されると、新しいアラートイベントが生成されます。
例:
{ "hostname":"Host", "alertname":"CPU utilization is too high","ip":"192.168.0.3"}。このラベルのセットは、ホスト (IP アドレス: 192.168.0.3) の CPU 使用率が高すぎるというアラートを指定します。ip ラベルが{"ip":"192.168.0.4"}に変更されると、新しいアラートが生成されます。新しいアラートは、ホスト (IP アドレス: 192.168.0.4) の CPU 使用率が高すぎることを示します。アノテーションの変更はアラートイベントに影響しません。同じラベルを持つアラートイベントに異なるアノテーションがある場合、それはアラートが複数回報告されたことを意味します。アノテーションの変更はアラートイベントに影響しません。同じラベルを持つアラートイベントに異なるアノテーションがある場合、それはアラートが複数回報告されたことを意味します。
例:
{"value":"85","message":"ホスト (IP アドレス: 192.168.0.3) の CPU 使用率は 85% で、しきい値 80% を超えています。"}アノテーションが{"value":"86","message":"ホスト (IP アドレス: 192.168.0.3) の CPU 使用率は 86% で、しきい値 80% を超えています。"}に変更されても、新しいアラートは生成されません。これらのアラートイベントは、2 回報告された 1 つのアラートと見なされます。
統合のラベルとして重複排除フィールドを設定できます。統合がアラートを報告すると、アラート管理は重複排除フィールドにのみ基づいて一意のアラートイベントを識別します。重複排除フィールドを設定しない場合、アラート管理はすべてのラベルを使用して一意のアラートイベントを識別します。
アラートイベント管理
アラートイベント管理モジュールは、アラートイベントを処理するために次のメソッドを提供します。
イベント処理フローを使用して簡単なプロシージャを編成し、アラートソースによって報告されたアラートイベントを処理します。これにより、さまざまなシナリオでのイベント処理に関する特定の要件を満たすことができます。
アラートソースによって報告されたアラートを重複排除、圧縮、ノイズ除去、およびサイレンシングします。これにより、アラートが収束し、アラートストームが軽減されます。
イベントの圧縮
デフォルトでは、アラートイベント管理モジュールは、ラベルまたは時間に基づいてイベントを圧縮します。
ラベルベースのイベント圧縮
ARMS が連絡先にアラート通知を送信すると、通知ポリシーで指定されたイベントグループ化設定に基づいてアラートイベントが圧縮されます。複数のアラートイベントに同じラベルが含まれている場合、イベントは自動的に 1 つのアラートイベントに圧縮されます。次の図では、アラートイベントは 2 つのラベルに基づいて圧縮されています。
時間ベースのイベント圧縮
各アラートイベントには、アラートの開始時刻と終了時刻が含まれています。同じラベルを持つアラートイベントの場合、アラートイベントの開始時刻と終了時刻が重複すると、アラートイベントは 1 つのアラートイベントに圧縮されます。結果として得られるアラートイベントの開始時刻と終了時刻は、アラートイベントの開始時刻と終了時刻の和集合です。
通知ポリシー管理
サブスクリプションルールを設定するのと同じ方法で、通知ポリシーに条件を設定できます。アラートイベントが指定された条件を満たす場合、ARMS は通知ポリシーに基づいてアラート通知を送信します。
次の図は、イベント処理フロー、イベント、および通知ポリシー間の関係を示しています。
共同アラート処理
複数のコラボレーションポリシーを設定できます。その後、ARMS コンソール、DingTalk、WeCom、および Lark でアラートを処理できます。また、グループメッセージの同期、スケジューリング管理、およびエスカレーションポリシーを設定することもできます。これにより、チーム内の連絡先が共同でアラートを処理できます。次の図は、アラートを共同で処理する方法を示しています。
利点
Alibaba Cloud にサービスをデプロイし、ARMS を使用してサービスを監視する場合、アラート管理を使用してアラートを処理できます。アラート管理は、次の方法で O&M 効率を向上させます。
アラートをグローバル化できます。
アラートルールテンプレートをグローバル化して、グローバルイベントのアラートを設定できます。
簡単な設定を行うことで、連絡先と通知ポリシーをグローバル化できます。
説明国際サイトでは、電話でアラート通知を送信することはできません。
さまざまなモニタリングサービスからイベントを収集して、管理効率を高めます。
アラート管理を Alibaba Cloud の一般的なモニタリングサービスと統合できます。また、アラート管理をサードパーティのモニタリングサービスと統合して、一元管理することもできます。
アラート管理は、安定したアラートイベント処理機能を提供します。アラートイベントは 24 時間 365 日処理できます。
アラート管理は、多数のアラートイベントを処理するための低待機時間を保証します。
タイムリーに連絡先にアラート通知を送信できます。
通知ポリシーを設定し、アラートイベントを圧縮できます。これにより、O&M のワークロードが削減されます。
アラートの緊急度に基づいて、1 つ以上の通知方法を選択できます。たとえば、メール、SMS、電話、または DingTalk で連絡先にアラート通知を送信して、アラートを処理するように連絡先に通知できます。
アラートが長期間未処理のままである場合に、連絡先に複数回通知を送信するエスカレーションポリシーを設定できます。
アラートを効率的に管理できます。
連絡先は DingTalk を使用していつでもアラートを処理できます。
アラートは共通のフォーマットを使用しているため、連絡先はアラートをより適切に分析できます。
複数の連絡先が DingTalk を通じて協力してアラートを処理できます。
アラートに関する統計はリアルタイムで収集され、アラートの処理方法を分析します。これにより、アラートをより効率的に処理できます。