Managed Service for Prometheus:Politiques de notification

Prérequis

Créez un contact avant de l'ajouter à une politique de notification. Pour plus d'informations, consultez la rubrique Créer un contact.

Créer une politique de notification

1. Connectez-vous à la console Managed Service for Prometheus. Dans le volet de navigation de gauche, choisissez 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 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 des règles de correspondance. Utilisez des tags personnalisés ou sélectionnez des 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 prédéfinis par le système	_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
        	_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 de 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 aucune configuration manuelle. Ce tag diffère du ContactGroupId v1 renvoyé 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 libellés de métriques portés 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 concerné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 pas 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 concerne 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 afin de créer une nouvelle règle.

      • La taille totale de configuration de toutes les règles de 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 correspondance basées sur les dimensions du cluster ou de l'objet — par exemple, en utilisant le libellé _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 dans 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 correspondance basées sur les libellés dans la politique de notification pour associer automatiquement toutes les règles d'alerte pertinentes en une seule fois, sans avoir à 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 de la console ARMS. Ce tag est généré automatiquement par le système et n'a pas besoin d'ê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 : lorsque cette option 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 vers lequel 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/escalation/recovery policy, configurez les politiques pour les alertes non résolues. Vous pouvez définir des notifications répétitives, appliquer une politique d'escalade ou exiger une résolution manuelle. Ensuite, cliquez sur Next.

   • Si vous ne configurez pas de politique d'escalade, le système envoie une seule notification pour une alerte non résolue.

   • Repeat notifications : définissez une fréquence. Si une alerte n'est pas résolue, les notifications sont renvoyées à l'intervalle spécifié jusqu'à la résolution de l'alerte.

   • Escalation policy : sélectionnez une politique. Si une alerte n'est pas résolue, le système envoie des notifications à des destinataires supplémentaires conformément à la politique d'escalade sélectionnée.

   • Manual recovery : si vous activez cette option, une alerte ne se résout pas automatiquement, même si aucun nouvel événement d'alerte n'est déclenché pendant la période de résolution automatique définie dans l'intégration d'alerte. Vous devez modifier manuellement le statut de l'alerte.

8. Dans la section Action Integration, configurez une intégration d'action à exécuter automatiquement.

   Si vous activez cette option, vous devez sélectionner les intégrations d'action à exécuter lorsqu'une alerte est déclenchée et lorsqu'elle est résolue. Le système les exécutera alors automatiquement.

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

Gérer les politiques de notification

Une fois une politique de notification créée, 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, activez ou désactivez le commutateur. Supprimer une politique de notification : cliquez sur Status dans la colonne Delete, puis cliquez sur Actions. Copier une politique de notification : cliquez sur Confirm dans la colonne Copy pour dupliquer la politique.