すべてのプロダクト
Search

このプロダクト

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

    ドキュメントセンター

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

    最終更新日:Sep 21, 2026

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

    前提条件

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

    通知ポリシーの作成

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

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

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

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

      重要

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

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

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

        • [No preset source]：すべてのインテグレーションからのアラートイベントをフィルタリングします。

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

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

        • アラートルール式のメトリクスからのタグです。Prometheus 用マネージドサービスのアラートルールのタグを作成する方法については、「Prometheus アラートルールを作成する」をご参照ください。

        • ARMS システムは、以下のデフォルトタグを提供します。

          カテゴリ

          タグ

          説明

          共通フィールド

          alertname

          アラート名。

          clustername

          クラスター名。

          severity

          重要度レベル：

          • P1

          • P2

          • P3

          • P4

          • Default

          namespace

          名前空間。

          pod_name

          ポッド名。

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

          _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：アプリケーションモニタリングアラート

          • 4：ブラウザモニタリングアラート

          その他のフィールド

          _arms_contact_group_v2_id

          アラート通知用の連絡先グループ ID (v2) は、ARMS によってアラートイベントタグに自動的に追加されるタグです。その値は、コンソールの[アラーム管理] > 通知対象 > [連絡先グループ] ページに表示される v2 連絡先グループ識別子に対応します。ACK 連携によって通知ポリシーが自動的に作成されると、このタグは手動設定なしでポリシーを照合するために使用されます。このタグは、API によって返される v1 の ContactGroupId とは異なります。このタグは、Webhook 通知ペイロードの commonLabels フィールドに表示されます。

        タグの表示動作

        アラートイベント分析ページに表示されるタグは、トリガーされたアラートルールに含まれるメトリクスラベルと、システムのプリセットフィールドに由来します。関連するアラートルールが異なるメトリクスやリソースタイプに関連付けられているため、アラートイベントごとに異なるタグフィールドを持つ場合があります。特定のフィールドを持たないイベントは、そのタグを表示しません。その結果、あるイベントでは表示され、別のイベントでは表示されないタグがある場合がありますが、これはシステムエラーではなく、想定される動作です。

        たとえば、アラートが Pod リソースに関連する場合にのみ、イベントに pod_name タグが含まれます。Pod に関連しないアラートでは、このタグは表示されません。

        説明

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

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

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

        説明

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

        これは、Container Service for Kubernetes (ACK) によって自動的に作成されるアラートルールなど、一括処理のシナリオで特に役立ちます。個別に編集することなく、通知ポリシーでラベルベースのマッチングルールを設定するだけで、関連するすべてのアラートルールを一度に自動的に関連付けることができます。

        ACK クラスターによって自動的に作成されたアラートルールには、システムが生成したタグ _arms_contact_group_v2_id が付与されます。このタグの値は連絡先グループ ID です。通知ポリシーは、このタグを使用してルールを照合し、指定された連絡先グループにアラート通知をルーティングします。タグ値は、ARMS コンソールの[アラーム管理] > 通知対象 > [連絡先グループ] ページに表示される連絡先グループ ID に対応します。このタグはシステムによって自動的に生成されるため、手動で追加する必要はありません。

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

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

      • [Do not group]：各アラートイベントが個別の通知として送信されます。

      • [Set grouping fields]：指定されたフィールドで同じ値を持つアラートイベントを 1 つの通知にグループ化します。

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

      1. [+Add Notification Recipient] をクリックして、通知受信者を選択します。

        通知受信者のタイプ：

        • [Contact]：選択した連絡先について、通知方法 (電話、SMS、またはメール) も選択する必要があります。

        • [Contact Group]：選択したコンタクトグループについて、通知方法 (電話、SMS、またはメール) も選択する必要があります。

        • [On-call Schedule]：選択したオンコールスケジュールについて、通知方法 (電話、SMS、またはメール) も選択する必要があります。

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

        • [General Webhook]：指定された Webhook URL に通知を送信します。

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

        [Send recovery notification]：有効にすると、アラート内のすべてのイベントが解決された後に回復通知が送信され、アラートは自動的に解決済みとしてマークされます。

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

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

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

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

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

      • [Repeat notifications for an alert]：有効にすると、未解決のアラートに対する通知は、アラートが解決されるまで指定された頻度で再送信されます。

      • [Escalation policy]：

        [No escalation policy] を選択した場合、未解決のアラートに対して通知は一度しか送信されません。

        [Use escalation policy] を選択した場合、通知はエスカレーションポリシーに従って他の受信者に送信されます。

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

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

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

    Microsoft Teams Webhook インテグレーション

    ARMS のアラート通知を Microsoft Teams チャネルに送信するには、Teams で受信 Webhook を作成し、その Webhook を ARMS の通知受信者として登録し、通知ポリシーでその受信者を選択します。

    1. Microsoft Teams で受信 Webhook を作成する：Teams チャネルで、[Settings] > [Connectors] を選択し、受信 Webhook を設定し、名前を入力して Webhook を作成し、生成された Webhook URL をコピーします。

    2. ARMS コンソールで Webhook 通知受信者を作成する：[Alarm Management] > 通知対象 を選択し、[Webhook Integration] タブをクリックしてから [Create Webhook] をクリックします。Webhook 名を入力し、Teams の受信 Webhook URL を [URL] フィールドに貼り付けてから、[Auto-fill Template] をクリックして Teams 互換のメッセージテンプレートを生成します。

    3. 通知ポリシーで Webhook 通知受信者を選択する：通知ポリシーを作成または編集する際に、[Notification Recipients] ステップで [+Add Notification Recipient] をクリックし、通知受信者のタイプを [General Webhook] に設定し、作成した Webhook を選択します。

    4. アラート通知を検証する：[Create Webhook] ダイアログボックスで [Send Test] をクリックし、テストメッセージが Teams チャネルで受信されることを確認します。

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

    通知ポリシーの管理

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

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

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

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

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

    よくある質問

    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」というテキストは、システムの固定のフォーマットであり、設定によって削除することはできません。