Application Real-Time Monitoring Service (ARMS) のアラート管理は、アラートの収束、通知、自動エスカレーションを提供し、ビジネスアラートを迅速に検出し、解決するのに役立ちます。
背景情報
Serverless App Engine (SAE) は ARMS のアラート管理を統合しています。新しいバージョンの ARMS アラート管理は、2021年4月30日 00:00 以降に SAE をアクティベートした Alibaba Cloud アカウントのみが利用できます。
アーキテクチャ
アラート管理は、統合管理、アラートイベント管理、通知ポリシー管理、協調的なアラート処理、アラート処理分析の5つのコアモジュールで構成されています。
統合管理
アラート管理は、デフォルトのアラート統合とサードパーティサービス統合の2種類の統合をサポートしています。
デフォルトのアラート統合
デフォルトの統合は、アプリケーションモニタリング、ブラウザ監視、Managed Service for Prometheus、合成監視など、さまざまな ARMS サービスからのアラートで利用できます。これらの統合は、定期的なタスクを使用してモニタリングデータにアノマリーがないかチェックします。アノマリーが検出されると、これらの統合はデフォルトのチャネルを通じてイベント管理センターにアラートイベントを送信します。
サードパーティ製品の統合
任意のサードパーティソースからアラートを受信するように統合を設定できます。これにより、ARMS でアラート管理を一元化でき、オンプレミスかクラウドかを問わず、すべてのシステムからのアラートを処理する中心的な場所を提供します。アラート管理は、送信されたすべてのアラートをアラートイベントとして処理します。アラートイベントには、次の構造と制約があります：
アラートイベントのデータ構造
ARMS アラートイベントのデータ構造は、オープンソースの AlertManager フォーマットに基づいており、次のフィールドが含まれます：
Labels：アラートのメタデータを表すキーと値のペアのセットです。一意のラベルセットが単一のアラートイベントを識別します。同じラベルセットを持つイベントはマージされます。例：
"alertname: High CPU Utilization"。Annotations：アラートに関する追加の、非識別情報を提供するキーと値のペアのセットです。例：
"message: Alert content"。StartsAt：アラートイベントが開始した時刻。
EndsAt：アラートイベントが終了した時刻。
GeneratorUrl：アラートイベントのソースへのリンクバック URL。
ラベルとアノテーションの違い
ラベルのセットは、アラートイベントを一意に定義します。いずれかのラベルの値が変更されると、新しいアラートイベントが生成されます。
例：
ラベルセット
{"hostname":"prod-host-01", "alertname":"High CPU Utilization", "ip":"192.168.0.3"}は、特定のアラート (ホスト 192.168.0.3 の高い CPU 使用率) を表します。ip ラベルが{"hostname":"prod-host-01", "alertname":"High CPU Utilization", "ip":"192.168.0.4"}のように変更されると、新しい別個のアラート (ホスト 192.168.0.4 の高い CPU 使用率) が作成されます。アノテーションの変更は、新しいアラートイベントを作成しません。同じラベルで異なるアノテーションを持つ複数のイベントは、同じアラートの更新と見なされます。
例：
アノテーション
{"value":"85", "message":"Host 192.168.0.3 CPU utilization is 85%, which exceeds the 80% threshold."}を持つアラートが、{"value":"86", "message":"Host 192.168.0.3 CPU utilization is 86%, which exceeds the 80% threshold."}のような新しいアノテーションで再度送信されても、新しいアラートは生成されません。両方のイベントは、同じ進行中のアラートの更新として扱われます。
統合に対して deduplication fields を設定できます。これを指定すると、その統合からのアラートイベントを一意に識別するために、これらのフィールドのみがラベルとして使用されます。重複排除フィールドを設定しない場合、すべてのアラートのラベルが一意のアラートイベントを識別するために使用されます。
アラートイベント管理
アラートイベント管理モジュールは、アラートソースからのイベントを処理する2つの方法を提供します：
イベント処理フローを使用して、単純な処理パイプラインを構築します。これにより、さまざまなデータ処理要件を満たすために、任意のソースからのアラートイベントを再処理できます。
イベント管理機能を使用して、アラートイベントの重複排除、圧縮、ノイズ除去、サイレンシングを実行します。これにより、アラートを統合し、アラートストームを削減できます。
イベントの圧縮
デフォルトでは、アラートイベント管理モジュールは、ラベルと時間の2つの方法でイベントを圧縮します。以下のセクションでは、各方法の仕組みについて説明します。
ラベルベースの圧縮
アラートイベントが通知をトリガーすると、システムは通知ポリシーで定義されたグルーピングポリシーに基づいてそれを圧縮します。ポリシーに一致する複数のイベントが、指定されたグルーピングラベルに対して同じ値を共有している場合、システムはそれらを自動的に単一の通知に圧縮します。次の図は、3つの異なるイベントが2つの異なるグルーピングラベルを使用してどのように圧縮されるかを示しています：
時間ベースの圧縮
各アラートイベントには開始時刻と終了時刻があります。同じラベルを持つアラートイベントの時間範囲が重複している場合、システムはそれらを単一のイベントにマージします。マージされたイベントの開始時刻と終了時刻は、元のイベントの時間範囲の和集合になります。
通知ポリシー管理
通知ポリシーは、本質的にサブスクリプションルールです。一致ルールを設定し、アラートイベントが条件を満たすと、ARMS はポリシーに従って通知を送信します。
次の図は、イベント処理フロー、イベント管理、および通知ポリシーの関係を示しています。
協調的なアラート処理
Alibaba Cloud 管理コンソール、または DingTalk、WeCom、Lark を通じてアラートを処理できます。アラート管理は、グループメッセージの同期、オンコールスケジューリング、および協調的なアラート処理のためのエスカレーションポリシーもサポートしています。次の図は、アラート処理のプロセスを示しています。詳細については、「アラート通知グループでのアラート処理」をご参照ください。
メリット
Alibaba Cloud 上にサービスをデプロイし、ARMS を使用してモニタリングする場合、アラート管理は次の点で運用効率の向上に役立ちます。
グローバルな運用
グローバルテンプレートを使用すると、すべてのリージョンのアラートルールを単一の場所から管理できます。
連絡先と通知ポリシーを一度設定するだけで、グローバルに有効になります。
効率的な集中管理
アラート管理は、一般的な Alibaba Cloud モニタリングツール用のワンクリック統合を提供し、他のツールの手動統合もサポートしているため、メンテナンスを容易に一元化できます。
イベント取り込みモジュールは安定しており、24時間365日、中断のないイベント処理を提供します。
システムは、大量のイベントデータを処理する際の低レイテンシーを保証します。
タイムリーで正確な通知
通知ルールを設定して、通知を送信する前にイベントをマージすることで、運用スタッフのアラート疲れを軽減できます。
アラートの緊急度に応じて、メール、SMS、電話、DingTalk などの異なる通知方法を選択して、適切な連絡先に通知できます。
エスカレーションポリシーを使用して、指定された期間が経過しても未処理のままのアラートに対して繰り返しリマインダーを送信し、タイムリーな解決を保証します。
迅速で便利なアラート管理
連絡先は DingTalk を通じていつでもアラートを処理できます。
共通のアラートフォーマットにより、連絡先はアラートをより効果的に分析できます。
複数の連絡先が DingTalk を通じて協力してアラートを解決できます。
リアルタイムの統計とステータス分析により、アラート解決効率を継続的に向上させることができます。