Application Real-Time Monitoring Service:Politiques de notification

Prérequis

Vous avez créé des destinataires de notification. Pour plus d'informations, consultez la rubrique Gérer les destinataires de notification.

Créer une politique de notification

1. Connectez-vous à la console ARMS. Dans le volet de navigation de gauche, sélectionnez Alert Management > Notification Policies.

2. Sur la page Notification Policies, cliquez sur Create Notification Policy.

3. En haut de la page Create Notification Policy, saisissez un nom pour la politique.

4. Dans la section Matching Rule, définissez les règles de mise en correspondance pour les événements d'alerte.

   Important

   Une politique de silence est prioritaire sur une politique de notification. Un événement d'alerte correspondant à une politique de silence est mis en sourdine et n'est pas évalué par rapport aux politiques de notification. Pour créer une politique de silence, consultez la rubrique Politiques de silence.

   1. Sélectionnez une source de données.

      • Specific source : filtre les événements d'alerte provenant d'une intégration spécifique.

      • No preset source : filtre les événements d'alerte provenant de toutes les intégrations.

   2. Définissez les expressions de la règle de mise en correspondance. Vous pouvez utiliser des tags personnalisés ou sélectionner parmi les tags existants.

      Les tags existants incluent :

      • Les tags issus des métriques dans l'expression d'une règle d'alerte. Pour savoir comment créer des tags pour une règle d'alerte Managed Service for Prometheus, consultez la rubrique Créer une règle d'alerte Prometheus.

      • Le système ARMS fournit les tags par défaut suivants.

        Catégorie	Tag	Description
        Champs communs	alertname	Nom de l'alerte.
        	clustername	Nom du cluster.
        	severity	Niveau de gravité : P1 P2 P3 P4 Default
        	namespace	namespace.
        	pod_name	Nom du Pod.
        Champs système prédéfinis	_aliyun_arms_integration_name	Nom de l'intégration. Le nom d'intégration par défaut pour les alertes signalées par ARMS est ARMS-DEFAULT.
        	_aliyun_arms_involvedObject_id	ID de l'objet d'alerte.
        	_aliyun_arms_involvedObject_name	Nom de l'objet d'alerte.
        	_aliyun_arms_region_id	ID de la région.
        	_aliyun_arms_alert_rule_id	ID de la règle d'alerte.
        	_aliyun_arms_alert_type	Type de règle d'alerte : 101 : alerte Prometheus 5 : alerte Application Monitoring 4 : alerte Browser Monitoring
        Autres champs	_arms_contact_group_v2_id	ID du groupe de contacts (v2) pour les notifications d'alerte. Ce tag est automatiquement ajouté par ARMS aux tags de l'événement d'alerte. Sa valeur correspond à l'identifiant du groupe de contacts v2 affiché sur la page Alarm Management > Notification Objects > Contact Group dans la console. Lorsqu'une politique de notification est créée automatiquement via l'intégration ACK, ce tag est utilisé pour faire correspondre la politique sans configuration manuelle. Ce tag diffère de la version v1 ContactGroupId renvoyée par l'API. Il est visible dans le champ commonLabels de la charge utile de notification webhook.

      Comportement d'affichage des tags

      Les tags affichés sur la page d'analyse des événements d'alerte proviennent des étiquettes de métriques portées par la règle d'alerte déclenchée et des champs prédéfinis par le système. Différents événements d'alerte peuvent porter différents champs de tags, car les règles d'alerte impliquées sont associées à différentes métriques et types de ressources. Un événement qui ne porte pas un champ donné n'affiche pas ce tag. Par conséquent, certains tags peuvent apparaître pour un événement et non pour un autre ; il s'agit d'un comportement attendu et non d'une erreur système.

      Par exemple, un événement porte le tag pod_name uniquement lorsque l'alerte implique une ressource Pod. Les alertes qui n'impliquent pas de Pod n'affichent pas ce tag.

      Remarque

      • Pour exiger qu'une alerte corresponde à toutes les conditions d'une règle (logique ET), cliquez sur Add Condition.

      • Pour exiger qu'une alerte corresponde à n'importe quelle règle (logique OU), cliquez sur Add Rule pour créer une nouvelle règle.

      • La taille totale de configuration de toutes les règles de mise en correspondance dans une politique de notification ne peut pas dépasser 64 Ko. Cette limite permet d'accueillir environ 100 règles, selon leur complexité. Le dépassement de cette limite entraîne l'échec de la configuration. Pour éviter cela, créez une nouvelle politique de notification pour les règles supplémentaires.

      Remarque

      Lorsqu'une politique de notification contient des règles de mise en correspondance basées sur les dimensions du cluster ou de l'objet — par exemple, en utilisant le label _aliyun_arms_involvedObject_id pour faire correspondre un ID de cluster Kubernetes — les règles d'alerte associées au cluster ou à l'objet correspondant sont automatiquement liées à la politique de notification. Vous n'avez pas besoin de configurer une politique de notification sur chaque règle d'alerte individuelle.

      Cela est particulièrement utile pour les scénarios en masse, tels que les règles d'alerte créées automatiquement par Container Service for Kubernetes (ACK). Il vous suffit de configurer des règles de mise en correspondance basées sur les labels dans la politique de notification pour associer automatiquement toutes les règles d'alerte pertinentes en une seule fois, sans les modifier une par une.

      Les règles d'alerte créées automatiquement par un cluster ACK portent le tag généré par le système _arms_contact_group_v2_id, dont la valeur est un ID de groupe de contacts. Les politiques de notification utilisent ce tag pour faire correspondre les règles et acheminer les notifications d'alerte vers le groupe de contacts spécifié. La valeur du tag correspond à l'ID du groupe de contacts affiché sur la page Alarm Management > Notification Objects > Contact Group dans la console ARMS. Ce tag est généré automatiquement par le système et ne doit pas être ajouté manuellement.

   3. Cliquez sur Next.

5. Dans la section Event Group, configurez le regroupement des événements d'alerte, puis cliquez sur Next.

   • Do not group : chaque événement d'alerte est envoyé sous forme de notification distincte.

   • Set grouping fields : regroupe les événements d'alerte ayant des valeurs identiques pour les champs spécifiés en une seule notification.

6. Dans la section Notification Objects, configurez les paramètres suivants.

   1. Cliquez sur +Add Notification Recipient pour sélectionner un destinataire de notification.

      Types de destinataires de notification :

      • Contact : vous devez également sélectionner une méthode de notification (appel téléphonique, SMS ou e-mail) pour le contact sélectionné.

      • Contact Group : vous devez également sélectionner une méthode de notification (appel téléphonique, SMS ou e-mail) pour le groupe de contacts sélectionné.

      • On-call Schedule : vous devez également sélectionner une méthode de notification (appel téléphonique, SMS ou e-mail) pour le planning d'astreinte sélectionné.

      • DingTalk/Lark/WeCom : envoie des notifications à un canal DingTalk, Lark ou WeCom.

      • General Webhook : envoie des notifications à une URL webhook spécifiée.

   2. Indiquez si vous souhaitez envoyer une notification de résolution après la résolution d'une alerte.

      Send recovery notification : lorsqu'elle est activée, une notification de résolution est envoyée après la résolution de tous les événements d'une alerte, et l'alerte est alors automatiquement marquée comme résolue.

   3. Définissez un modèle de notification. Pour plus d'informations, consultez la rubrique Configurer les modèles de notification et de webhook.

   4. Définissez une période de notification pour envoyer des alertes uniquement dans la fenêtre temporelle spécifiée.

   5. Facultatif : Sélectionnez un système de tickets pour y pousser les alertes. Pour plus de détails sur l'intégration d'un système de tickets, consultez la rubrique Intégrations.

   6. Cliquez sur Next.

7. Dans la section Repeat/Escalate/Recover Policy, configurez la répétition des notifications ou l'utilisation d'une politique d'escalade pour une alerte, puis cliquez sur Next.

   • Répéter les notifications pour une alerte : lorsqu'elle est activée, les notifications pour les alertes non résolues sont renvoyées à la fréquence spécifiée jusqu'à ce que l'alerte soit résolue.

   • Politique d'escalade :

     Si vous sélectionnez No escalation policy, la notification est envoyée une seule fois pour une alerte non résolue.

     Si vous sélectionnez Use escalation policy, la notification est envoyée à d'autres destinataires conformément à la politique d'escalade.

   • Résolution manuelle : lorsqu'elle est activée, les alertes ne seront pas résolues automatiquement, même si aucun nouvel événement n'est déclenché pendant la période de récupération automatique de l'intégration. Vous devez résoudre ces alertes manuellement.

8. Dans la section Action Integration, configurez les actions automatisées qui s'exécutent lorsqu'une alerte est déclenchée ou résolue. Pour plus d'informations, consultez la rubrique Exécuter un plan d'alerte à l'aide d'une intégration d'action ARMS.

9. Cliquez sur Save pour créer la politique.

Gérer les politiques de notification

Après la création d'une politique de notification, elle s'affiche sur la page Notification Policies. Sur la page Notification Policies dans la colonne Edit. Après avoir effectué vos modifications, cliquez sur Actions. Activer ou désactiver une politique de notification : dans la colonne Save dans la colonne Status. Copier une politique de notification : cliquez sur Delete dans la colonne Actions pour dupliquer la politique. ## FAQ Q : Comment configurer différentes méthodes de notification pour différentes gravités d'alerte au sein d'une seule politique de notification ?

R : Vous pouvez ajouter plusieurs Confirm au sein de la même politique de notification pour mettre en œuvre des notifications différenciées. Pour chaque action, configurez ses conditions de mise en correspondance (par exemple, gravité P1 ou P2) et sélectionnez le canal de notification correspondant (par exemple, appel téléphonique ou groupe DingTalk). Cette approche élimine le besoin de créer une politique de notification distincte pour chaque niveau de gravité.

Q : Pourquoi l'intervalle de notification réel diffère-t-il de l'intervalle de notification répétitive configuré ?

R : L'intervalle de notification réel est affecté par plusieurs facteurs qui se chevauchent :

• Cycle de vérification des alertes Prometheus : par défaut, Prometheus vérifie les alertes toutes les minutes.

• Mécanisme « Vérifier après complétion des données » : ce mécanisme est activé par défaut. Il ajoute un temps de traitement supplémentaire pour garantir que les données d'alerte sont entièrement disponibles avant que le système n'évalue les nouveaux événements.

• Agrégation des événements et délai de traitement du système : un délai supplémentaire survient lors de l'agrégation des événements et du traitement en aval.

En raison de ces effets cumulatifs, l'intervalle réel peut être plus long que la valeur configurée. Par exemple, un intervalle configuré de 1 minute peut entraîner un intervalle effectif de 3 minutes.

De plus, les notifications de résolution sont recalculées en fonction de l'horodatage du dernier événement d'alerte. Si les alertes continuent de se déclencher, les notifications de résolution seront retardées en conséquence.

Q : L'ID utilisateur Alibaba Cloud affiché à la fin des messages SMS d'alerte ARMS peut-il être supprimé ?

R : Non. Le texte « This message was configured in ARMS by Alibaba Cloud user: xxxxxx » est un format système fixe et ne peut pas être supprimé via la configuration.