すべてのプロダクト
Search

このプロダクト

    Application Real-Time Monitoring Service:通知ポリシー

    ドキュメントセンター

    Application Real-Time Monitoring Service:通知ポリシー

    最終更新日:Jul 10, 2026

    通知ポリシーを使用すると、アラートイベントの一致ルールを定義できます。イベントが一致ルールをトリガーすると、システムは指定された通知受信者にアラート通知を送信し、問題の解決を促します。

    前提条件

    通知受信者を作成済みであること。詳細については、「通知受信者の管理」をご参照ください。

    通知ポリシーの作成

    1. ARMS コンソール にログオンします。左側のナビゲーションウィンドウで、[アラート管理] > [通知ポリシー] を選択します。

    2. 通知ポリシー ページで、通知ポリシーの作成 をクリックします。

    3. 通知ポリシーの作成 ページの上部で、ポリシーの名前を入力します。

    4. Match Rule セクションで、アラートイベントの一致ルールを定義します。

      重要

      サイレンスポリシーは通知ポリシーよりも優先されます。サイレンスポリシーに一致したアラートイベントはサイレンスされ、通知ポリシーでは評価されません。サイレンスポリシーの作成については、「サイレンスポリシー」をご参照ください。

      1. データソースを選択します。

        • 特定のソース：指定されたインテグレーションからのアラートイベントをフィルタリングします。

        • 事前設定されたソースなし：すべてのインテグレーションからのアラートイベントをフィルタリングします。

      2. 一致ルールの式を設定します。カスタムタグを使用するか、既存のタグから選択できます。

        既存のタグには以下が含まれます。

        • アラートルール式に含まれるメトリクスのタグ。Managed Service for Prometheus アラートルールのタグの作成方法については、「Prometheus アラートルールの作成」をご参照ください。

        • ARMS システムが提供する以下のデフォルトタグ。

          カテゴリ

          タグ

          説明

          共通フィールド

          alertname

          アラート名。

          clustername

          クラスター名。

          severity

          重要度レベル：

          • P1

          • P2

          • P3

          • P4

          • Default

          namespace

          名前空間。

          pod_name

          Pod 名。

          システムプリセットフィールド

          _aliyun_arms_integration_name

          インテグレーション名。ARMS によって報告されるアラートのデフォルトのインテグレーション名は ARMS-DEFAULT です。

          _aliyun_arms_involvedObject_id

          アラートオブジェクト ID。

          _aliyun_arms_involvedObject_name

          アラートオブジェクト名。

          _aliyun_arms_region_id

          リージョン ID。

          _aliyun_arms_alert_rule_id

          アラートルール ID。

          _aliyun_arms_alert_type

          アラートルールタイプ：

          • 101：Prometheus アラート

          • 5：Application Monitoring アラート

          • 4：Browser Monitoring アラート
        説明

        • アラートがルール内のすべての条件に一致するようにする (AND ロジック) には、条件の追加 をクリックします。

        • アラートがいずれかのルール (OR ロジック) に一致するようにするには、ルールの追加 をクリックして新しいルールを作成します。

        • 通知ポリシー内のすべての一致ルールの合計設定サイズは 64 KB を超えることはできません。この制限では、複雑さに応じて約 100 個のルールを設定できます。この制限を超えると、設定が失敗します。これを回避するには、追加のルール用に新しい通知ポリシーを作成してください。

        説明

        通知ポリシーにクラスターまたはオブジェクトディメンションに基づく一致ルールが含まれている場合 (例：ラベル _aliyun_arms_involvedObject_id を使用して Kubernetes クラスター ID に一致させる場合)、一致したクラスターまたはオブジェクトに関連付けられたアラートルールが自動的に通知ポリシーにリンクされます。個々のアラートルールごとに通知ポリシーを設定する必要はありません。

        これは、Container Service for Kubernetes (ACK) によって自動的に作成されるアラートルールなど、一括で設定する場合に特に便利です。通知ポリシーでラベルベースの一致ルールを設定するだけで、関連するすべてのアラートルールを一度に自動的に関連付けることができ、1 つずつ編集する必要はありません。

      3. 次へ をクリックします。

    5. イベントのグループ化 セクションで、アラートイベントをグループ化する方法を設定し、次へ をクリックします。

      • グループ化しない：各アラートイベントが個別の通知として送信されます。

      • グループ化フィールドを設定：指定されたフィールドの値が同一のアラートイベントを 1 つの通知にグループ化します。

    6. 通知対象 セクションで、次のパラメーターを設定します。

      1. [+通知受信者の追加] をクリックして、通知受信者を選択します。

        通知受信者のタイプ：

        • 連絡先：選択した連絡先の通知方法 (電話、テキストメッセージ、またはメール) も選択する必要があります。

        • 連絡先グループ：選択した連絡先グループの通知方法 (電話、テキストメッセージ、またはメール) も選択する必要があります。

        • オンコールスケジュール：選択したオンコールスケジュールの通知方法 (電話、テキストメッセージ、またはメール) も選択する必要があります。

        • DingTalk/Lark/WeCom：DingTalk、Lark、または WeCom チャネルに通知を送信します。

        • 汎用 Webhook：指定された Webhook URL に通知を送信します。

      2. アラートが解決された後に復旧通知を送信するかどうかを選択します。

        復旧通知を送信：有効にすると、アラート内のすべてのイベントが解決された後に復旧通知が送信され、アラートは自動的に「解決済み」ステータスになります。

      3. 通知テンプレートを設定します。詳細については、「通知テンプレートと Webhook テンプレートの設定」をご参照ください。

      4. 指定された時間枠内でのみアラートを送信するように通知期間を定義します。

      5. オプション： アラートをプッシュするチケットシステムを選択します。チケットシステムの統合方法の詳細については、「インテグレーション」をご参照ください。

      6. 次へ をクリックします。

    7. [繰り返し/エスカレーション/リカバリーポリシー] セクションで、アラート通知を繰り返すか、エスカレーションポリシーを使用するかを設定し、[次へ] をクリックします。

      • アラートの通知を繰り返す：有効にすると、未解決のアラートの通知がアラートが解決されるまで指定された頻度で再送信されます。

      • エスカレーションポリシー：

        エスカレーションポリシーなし を選択した場合、未解決のアラートに対して通知は 1 回のみ送信されます。

        エスカレーションポリシーを使用 を選択した場合、エスカレーションポリシーに従って他の受信者に通知が送信されます。

      • 手動復旧：有効にすると、インテグレーションの自動復旧期間中に新しいイベントがトリガーされなくても、アラートは自動的に解決されません。これらのアラートは手動で解決する必要があります。

    8. アクション統合 セクションで、アラートがトリガーまたは解決されたときに実行される自動化アクションを設定します。 詳細については、「ARMS のアクション連携を使用してアラートプランを実行する」をご参照ください。

    9. 保存をクリックしてポリシーを作成します。

    通知ポリシーの管理

    通知ポリシーを作成すると、通知ポリシー ページに表示されます。通知ポリシー ページでは、次の操作を実行できます。

    • 通知ポリシーの編集: ポリシー名をクリックするか、操作 列の 編集 をクリックします。変更後、保存 をクリックします。

    • 通知ポリシーの有効化または無効化: ステータス 列で、スイッチを切り替えます。

    • 通知ポリシーの削除: 操作 列の 削除 をクリックし、確認 をクリックします。

    • 通知ポリシーのコピー: 操作列のコピーをクリックしてポリシーを複製します。

    よくある質問

    Q：1 つの通知ポリシー内で、異なるアラート重要度に対して異なる通知方法を設定するにはどうすればよいですか?

    A: 同じ通知ポリシー内で複数の 操作 を追加して、通知を差別化できます。各アクションについて、その一致条件 (たとえば、P1 の重要度や P2 の重要度など) を設定し、対応する通知チャネル (たとえば、電話や DingTalk グループなど) を選択します。この方法により、重要度レベルごとに個別の通知ポリシーを作成する必要がなくなります。

    Q：実際の通知間隔が設定された繰り返し通知間隔と異なるのはなぜですか?

    A：実際の通知間隔は、以下の複数の重複する要因の影響を受けます。

    • Prometheus アラートチェックサイクル：デフォルトでは、Prometheus は 1 分ごとにアラートをチェックします。

    • 「データ完了後にチェック」メカニズム：このメカニズムはデフォルトで有効になっています。システムが新しいイベントを評価する前にアラートデータが完全に利用可能であることを保証するため、追加の処理時間が必要になります。

    • イベント集約とシステム処理遅延：イベント集約とダウンストリーム処理中に追加の遅延が発生します。

    これらの累積効果により、実際の間隔は設定値よりも長くなる場合があります。たとえば、設定された間隔が 1 分の場合、実効間隔は 3 分になる可能性があります。

    さらに、復旧通知は最後のアラートイベントのタイムスタンプに基づいて再計算されます。アラートが継続的にトリガーされる場合、復旧通知はそれに応じて遅延します。

    Q：ARMS アラート SMS メッセージの最後に表示される Alibaba Cloud ユーザー ID を削除できますか?

    A：いいえ。「This message was configured in ARMS by Alibaba Cloud user: xxxxxx」というテキストは固定のシステム形式であり、設定によって削除することはできません。