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

通知ポリシーの作成

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

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

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

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

   重要

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

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

      • [特定のソース]：指定された統合からのアラートイベントをフィルタリングします。

      • [プリセットソースなし]：すべての統合からのアラートイベントをフィルタリングします。

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

      既存のタグには次のものが含まれます。

      • アラートルール式内のメトリクスのタグです。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：アプリケーションモニタリングアラート 4：ブラウザ監視アラート
        	_arms_contact_group_v2_id	アラート通知用のコンタクトグループ ID (v2) で、ARMS によってアラートイベントタグに自動的に追加されます。その値は、コンソールの [アラーム管理] > 通知対象 > [コンタクトグループ] ページに表示される v2 コンタクトグループ識別子に対応します。ACK 連携によって通知ポリシーが自動的に作成されると、このタグは手動設定なしでポリシーを照合するために使用されます。このタグは、API によって返される v1 の ContactGroupId とは異なります。これは、Webhook 通知ペイロードの commonLabels フィールドに表示されます。

      タグ表示の動作

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

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

      説明

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

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

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

      説明

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

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

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

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