Application Real-Time Monitoring Service（ARMS）アラート管理は、アラートの集約、アラート通知、自動エスカレーションなどの機能を提供し、アラートの効率的な特定と処理を支援します。このトピックでは、アラート管理のアーキテクチャと利点について説明します。
アーキテクチャ
アラート管理は、統合管理、アラートイベント管理、通知ポリシー管理、コラボレーティブアラート処理、アラート処理分析の各モジュールを提供します。
統合管理
アラート管理は、デフォルトアラート統合とサードパーティサービス統合の2種類の統合を提供します。
デフォルトアラート統合
アラート管理は、アプリケーション監視、ブラウザ監視、Managed Service for Prometheus、合成監視などのARMSサブサービスのアラートと統合できます。デフォルトアラート統合を使用して、定期タスクに基づいて監視データにエラーが含まれているかどうかを確認できます。監視データにエラーが含まれている場合、対応するアラートイベントがイベント管理センターに報告されます。
ARMSの各サブサービスのアラートルールを作成する方法については、以下のトピックを参照してください。
サードパーティサービス統合
簡単な設定を行うことで、アラート管理をサードパーティのアラートソースと統合できます。これは、ARMSで自己管理データセンターまたは仮想マシンによって生成されたアラートを処理するための一元的なソリューションです。サードパーティのアラートソースからアラート管理にアラートが報告されると、アラートイベントが生成されます。アラートイベントには次の制限があります。
アラートイベントのデータ構造
ARMSアラートイベントのデータ構造は、オープンソースAlertManagerの通知テンプレートのデータ構造と似ています。データ構造には、次のフィールドが含まれます。
ラベル：アラートのメタデータ。ラベルのセットは、アラートイベントを一意に識別します。同じラベルを持つアラートイベントは1つのイベントに圧縮されます。例：
"alertname: alert name"。アノテーション：アラートの追加情報。アノテーションはメタデータではありません。例：
"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":"The CPU utilization of the host (IP address: 192.168.0.3) is 85%, which is higher than the threshold value 80%."}アノテーションが{"value":"86","message":"The CPU utilization of the host (IP address: 192.168.0.3) is 86%, which is higher than the threshold value 80%."}に変更されても、新しいアラートは生成されません。アラートイベントは、2回報告されたアラートと見なされます。
統合のラベルとして重複排除フィールドを設定できます。統合がアラートを報告する場合、アラート管理は重複排除フィールドのみに基づいて一意のアラートイベントを識別します。重複排除フィールドを設定しない場合、アラート管理はすべてのラベルを使用して一意のアラートイベントを識別します。
アラートイベント管理
アラートイベント管理モジュールは、アラートイベントを処理するための次の方法を提供します。
イベント処理フローを使用して、簡単な手順を調整し、アラートソースによって報告されたアラートイベントを処理します。これは、さまざまなシナリオでのイベント処理に関する特定の要件を満たします。
アラートソースによって報告されたアラートの重複排除、圧縮、ノイズ除去、およびサイレンシングを行います。これにより、アラートが収束し、アラートストームが軽減されます。
イベント圧縮
デフォルトでは、アラートイベント管理モジュールは、ラベルまたは時間に基づいてイベントを圧縮します。
ラベルベースのイベント圧縮
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を通じて協力してアラートを処理できます。
アラートの統計がリアルタイムで収集され、アラートの処理方法が分析されます。これにより、より効率的にアラートを処理できます。