Application Real-Time Monitoring Service:アラート管理の概要

仕組み

1. アラートソースがイベントをレポート：ARMS のサブサービス (アプリケーションモニタリング、ブラウザ監視、Managed Service for Prometheus、Synthetic Monitoring) およびサードパーティの監視ツールが、統合を通じてアラートイベントをアラート管理に送信します。

2. イベントの処理：アラート管理は、イベントの重複排除、圧縮、デノイズ、サイレンスを行い、アラートストームを削減します。イベント処理フローにより、特定のアラートソースに対してカスタムの処理ロジックを提供します。

3. 適切な担当者への通知：通知ポリシーに基づき、処理されたイベントが E メール、SMS、電話、またはメッセージングプラットフォーム (DingTalk、WeCom、Lark) を通じて連絡先にルーティングされます。

4. チームによる共同でのアラート解決：連絡先は、ARMS コンソールまたはグループチャットでアラートの担当表明、議論、解決を行います。未解決のアラートは自動的にエスカレーションされます。

5. 分析による解決パフォーマンスの追跡：リアルタイムの統計情報により、アラートの処理状況が可視化され、チームがボトルネックを特定し、応答時間を改善するのに役立ちます。

アーキテクチャ

アラート管理は、以下の 5 つのモジュールで構成されています：

統合管理

アラート管理は、ARMS サブサービス用のデフォルトのアラート統合と、外部アラートソース用のサードパーティサービス統合の 2 種類の統合をサポートしています。

デフォルトのアラート統合

デフォルトのアラート統合は、アラート管理と ARMS サブサービスを接続します。これらの統合は、モニタリングデータにエラーが含まれているかどうかを定期的にチェックし、一致するアラートイベントをイベント管理センターにレポートします。

サードパーティサービスの統合

サードパーティサービスの統合は、自己管理のデータセンターや仮想マシンからのアラートを ARMS に集約します。サードパーティソースがアラートをレポートすると、アラート管理はアラートイベントを生成します。

アラートイベントのデータ構造

ARMS のアラートイベントのデータ構造は、オープンソースの AlertManager の通知テンプレートフォーマットに似ており、以下のフィールドを含みます：

ラベルとアノテーションの違い

ラベルは ID を定義します。ラベルのセットは、アラートイベントを一意に識別します。いずれかのラベルを変更すると、新しいイベントが作成されます。

例えば、以下のラベルは特定のホストの CPU アラートを識別します：

{
  "hostname": "Host",
  "alertname": "CPU utilization is too high",
  "ip": "192.168.0.3"
}

ip が 192.168.0.4 に変更された場合、アラート管理はこれを別のホストに対する個別のアラートイベントとして扱います。

アノテーションはコンテキストを伝えます。アノテーションの変更は新しいイベントを作成しません。イベントが同じラベルを共有しているが、アノテーションが異なる場合、アラート管理はそれらを同じアラートの繰り返しレポートとして扱います。

例えば、アノテーション {"value": "85", "message": "CPU utilization of host 192.168.0.3 is 85%, exceeding the 80% threshold"} が後で {"value": "86", ...} をレポートしても、新しいイベントは作成されません。アラート管理はこれを同じアラートが 2 回レポートされたものとして記録します。

アラートイベント管理

アラートイベント管理モジュールは、受信イベントを 2 つの方法で処理します：

• イベント処理フローは、特定のアラートソースからのイベントを処理するためのカスタムプロシージャを編成し、イベントのルーティングと変換を詳細に制御します。

• 組み込みのノイズリダクションは、イベントを自動的に重複排除、圧縮、デノイズ、サイレンスし、関連するアラートを収束させてアラートストームを削減します。

イベントの圧縮

アラート管理は、ラベルベースの圧縮と時間ベースの圧縮の 2 つの方法を使用してイベントを圧縮します。

ラベルベースの圧縮

通知を送信する際、アラート管理は通知ポリシーのイベントグループ化設定に従ってイベントをグループ化します。同じラベル値を共有するイベントは、単一のイベントに圧縮されます。

時間ベースの圧縮

同一のラベルを持つイベントについて、それらの時間範囲 (StartsAt から EndsAt) が重複する場合、アラート管理はそれらを単一のイベントにマージします。マージされたイベントは、すべての元の時間範囲の和集合にわたります。

通知ポリシー管理

通知ポリシーは、サブスクリプションルールに似た条件を定義し、アラート通知がどのように配信されるかを決定します。アラートイベントがポリシー内の条件に一致すると、ARMS はそのポリシーで指定されたチャネルと連絡先を通じて通知を送信します。

以下の図は、イベント処理フロー、イベント、通知ポリシーがどのように相互作用するかを示しています。

協調的なアラート処理

アラート管理は、ARMS コンソール、DingTalk、WeCom、Lark を横断した協調的なワークフローをサポートしています。コラボレーションポリシーにより、以下が可能になります：

• グループメッセージの同期 -- アラートの更新は、チームのチャットグループに自動的に表示されます。

• スケジュール管理 -- オンコールローテーションを割り当てることで、いつでも適切な担当者が対応できるようにします。

• エスカレーションポリシー -- アラートが未解決のままである場合、追加の連絡先に自動的に通知します。

詳細な手順については、「指定されたグループチャットでアラートを処理する」をご参照ください。

メリット

Alibaba Cloud 上にデプロイされたサービスに対して、アラート管理は以下の領域で O&M (運用保守) 効率を向上させます：