ARMS アラート管理は、アラートの集約、通知、自動エスカレーションに関する強力な機能を提供します。これにより、アプリケーションやサービスで発生する問題を迅速に検出し、解決できます。本トピックでは、アラート管理のアーキテクチャ、基本概念、メリットについて概要を説明します。
アーキテクチャ
アラート管理は、統合管理、アラートイベント管理、通知ポリシー管理、共同アラート対応、アラート対応分析という 5 つのコアモジュールで構成されています。
統合管理
アラート管理は、デフォルトのアラート統合とサードパーティサービス統合という 2 種類の統合をサポートしています。
デフォルトのアラート統合
デフォルト統合は、アプリケーションモニタリング、ブラウザ監視、Managed Service for Prometheus、合成監視など、さまざまな ARMS サービスからのアラートに対して利用できます。これらの統合は定期タスクを使用してモニタリングデータをチェックし、アノマリーを検出すると、デフォルトチャンネルを通じてイベント管理センターにアラートイベントを送信します。
各 ARMS サービスのアラートルールの作成方法については、以下のトピックをご参照ください。
サードパーティサービス統合
サードパーティの任意のソースからアラートを受信するように統合を設定できます。これにより、オンプレミスまたはクラウド上のすべてのシステムからのアラートを ARMS で一元的に管理でき、アラート対応の中央拠点を提供します。アラート管理は、送信されたすべてのアラートをアラートイベントとして処理します。アラートイベントには、以下の構造と制約があります。
アラートイベントのデータ構造
ARMS アラートイベントのデータ構造は、オープンソースの AlertManager 形式に基づいており、以下のフィールドを含みます。
ラベル：アラートのメタデータを表すキーと値のペアのセット。一意のラベルセットが単一のアラートイベントを識別します。同じラベルセットを持つイベントはマージされます。例：
"alertname: High CPU Utilization"。アノテーション：アラートに関する識別情報以外の追加情報を提供するキーと値のペアのセット。例：
"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."}という新しいアノテーションが付与された場合でも、新しいアラートは生成されません。両方のイベントは、同じ進行中のアラートに対する更新として扱われます。
統合ごとに 重複排除フィールド を設定できます。指定された場合、その統合からのアラートイベントを一意に識別するために、これらのフィールドのみがラベルとして使用されます。重複排除フィールドを設定しない場合は、すべてのラベルが一意のアラートイベントの識別に使用されます。
アラートイベント管理
アラートイベント管理モジュールでは、アラートソースからのイベントを処理する方法が 2 つ提供されています。
イベント処理フローを使用して、シンプルな処理パイプラインを構築します。これにより、任意のソースからのアラートイベントを再処理し、さまざまなデータ処理要件に対応できます。
イベント管理機能を使用して、アラートイベントに対して重複排除、圧縮、ノイズ除去、サイレンスを実行します。これにより、アラートを統合し、アラートストームを軽減できます。
イベント圧縮
デフォルトで、アラートイベント管理モジュールはラベルベースと時間ベースの 2 つの方法でイベントを圧縮します。以下では、それぞれの方法の動作について説明します。
ラベルベースの圧縮
アラートイベントが通知をトリガーすると、システムは通知ポリシーで定義されたグループ化ポリシーに基づいて圧縮を行います。ポリシーに一致する複数のイベントが、指定されたグループ化ラベルに対して同じ値を持つ場合、システムはそれらを自動的に単一の通知に圧縮します。以下の図は、3 つの異なるイベントが 2 つの異なるグループ化ラベルを使用して圧縮される様子を示しています。
時間ベースの圧縮
各アラートイベントには開始時刻と終了時刻があります。同じラベルを持つアラートイベントの時間範囲が重複している場合、システムはそれらを単一のイベントにマージします。マージ後のイベントの開始時刻および終了時刻は、元のイベントの時間範囲の和集合になります。
通知ポリシー管理
通知ポリシーは、基本的にサブスクリプションルールです。マッチングルールを設定すると、アラートイベントが条件を満たした際に ARMS がポリシーに従って通知を送信します。
以下の図は、イベント処理フロー、イベント管理、通知ポリシーの関係を示しています。
共同アラート対応
共同アラート対応モジュールでは、複数の共同作業ポリシーを設定できます。Alibaba Cloud コンソールや DingTalk、WeCom、Lark などのツールで直接アラートを処理できます。また、グループメッセージ同期、オンコールスケジューリング、共同チーム環境向けのエスカレーションポリシーなどの機能もサポートしています。以下の図は、アラート対応プロセスを示しています。詳細については、「グループチャットでのアラート対応」をご参照ください。
メリット
Alibaba Cloud 上でサービスを展開し、ARMS を使用してモニタリングを行う場合、アラート管理は以下の点で運用効率を向上させます。
グローバル運用
グローバルテンプレートにより、すべてのリージョンのアラートルールを一か所から管理できます。
連絡先と通知ポリシーを一度設定すれば、グローバルに適用されます。
効率的かつ集中した管理
アラート管理は、一般的な Alibaba Cloud モニタリングツール向けにワンクリック統合を提供し、他のツール向けには手動統合をサポートしているため、一元的なメンテナンスが容易です。
イベント取り込みモジュールは安定しており、24 時間 365 日途切れることなくイベントを処理します。
大量のイベントデータを処理する際も、低遅延を保証します。
タイムリーかつ正確な通知
通知ルールを設定して、通知送信前にイベントをマージすることで、運用担当者のアラート疲労を軽減できます。
アラートの緊急性に応じて、メール、SMS、電話、DingTalk など、さまざまな通知方法を選択し、適切な連絡先に通知できます。
エスカレーションポリシーを使用して、指定された期間後に未対応のまま残っているアラートに対して繰り返しリマインダーを送信し、タイムリーな解決を確実にします。
迅速かつ便利なアラート管理
連絡先は DingTalk を通じていつでもアラートを処理できます。
共通のアラートフォーマットにより、連絡先がアラートをより効果的に分析できます。
複数の連絡先が DingTalk を通じて協力してアラートを解決できます。
リアルタイムの統計とステータス分析により、アラート解決効率を継続的に改善できます。