Lorsque les métriques Prometheus dépassent les seuils attendus ou présentent des anomalies, une notification rapide permet d'éviter l'escalade des incidents. Les règles d'alerte ARMS Prometheus vous permettent de définir des conditions sur n'importe quelle métrique, soit en sélectionnant une métrique prédéfinie, soit en rédigeant une instruction PromQL personnalisée, et d'acheminer les notifications vers votre équipe par SMS, e-mail, appel téléphonique, robot de discussion DingTalk, robot de discussion WeCom ou webhook.
Prérequis
Vous êtes connecté à Prometheus. Pour plus d'informations, consultez :
Point d'entrée
Connectez-vous à la console ARMS.
Dans le volet de navigation de gauche, sélectionnez .
Connectez-vous à la console Managed Service for Prometheus.
Dans le volet de navigation de gauche, cliquez sur View Alert Rules.
Sur la page Prometheus Alert Rules, cliquez sur Create Prometheus Alert Rule.
Créer une règle d'alerte Prometheus basée sur un seuil statique
Le type de vérification par seuil statique propose des métriques d'alerte prédéfinies. Sélectionnez ces métriques pour créer rapidement des règles d'alerte.
-
Sur la page Create Prometheus Alert Rule, configurez les paramètres d'alerte suivants.
Paramètre
Description
Exemple
Alert Name
Nom de l'alerte.
prod-cluster-container-cpu-alert
Check Type
Sélectionnez Static threshold.
Static threshold
Prometheus Instance
Sélectionnez l'instance Prometheus pour laquelle vous souhaitez créer l'alerte.
Production Cluster
Alert Group
Sélectionnez un groupe d'alertes.
Les différents types d'instances Prometheus prennent en charge différents groupes d'alertes. Les options de groupe d'alertes disponibles varient selon le type d'instance Prometheus sélectionné.
Kubernetes Workloads
Alert Metric
Sélectionnez la métrique pour laquelle vous souhaitez configurer l'alerte. Chaque groupe d'alertes correspond à des métriques différentes.
Container CPU utilization
Alert Condition
Définissez les conditions qui déclenchent un événement d'alerte en fonction du contenu prédéfini de la métrique d'alerte.
La condition d'alerte est remplie lorsque l'utilisation du processeur du conteneur est
greater than80%.Filter Condition
Définissez la portée de la règle d'alerte en fonction de la métrique d'alerte. Un événement d'alerte est déclenché lorsque toute ressource répondant aux conditions de filtre satisfait la règle d'alerte.
Les conditions de filtre suivantes sont disponibles :
Traverse : La règle d'alerte s'applique à toutes les ressources de l'instance Prometheus actuelle. Traverse est la condition de filtre par défaut.
Equal To : Après avoir sélectionné cette condition, saisissez un nom de ressource spécifique. La règle d'alerte s'applique uniquement à cette ressource. Vous ne pouvez pas saisir plusieurs noms de ressources.
Not Equal To : Après avoir sélectionné cette condition, saisissez un nom de ressource spécifique. La règle d'alerte s'applique à toutes les ressources, à l'exception de celle spécifiée. Vous ne pouvez pas saisir plusieurs noms de ressources.
Match Regular Expression : Après avoir sélectionné cette condition, saisissez une expression régulière pour faire correspondre les noms de ressources selon vos besoins. La règle d'alerte s'applique à toutes les ressources correspondant à l'expression régulière.
Do Not Match Regular Expression : Après avoir sélectionné cette condition, saisissez une expression régulière pour faire correspondre les noms de ressources selon vos besoins. La règle d'alerte exclut toutes les ressources correspondant à l'expression régulière.
RemarqueAprès avoir défini les conditions de filtre, la zone Data Preview s'affiche.
La condition de filtre ne peut pas dépasser 300 caractères.
Traverse
Data Preview
La zone Data Preview affiche l'instruction Prometheus Query Language (PromQL) correspondant à la condition d'alerte. Elle présente également les valeurs de la métrique de surveillance sous forme de courbe de série chronologique.
Par défaut, seule la valeur en temps réel d'une ressource est affichée. Vous pouvez sélectionner une ressource cible et une plage horaire dans la zone de filtre de cette section pour afficher les valeurs pour différentes ressources et plages horaires.
RemarqueLe seuil d'alerte apparaît sous forme d'une ligne droite rouge sur la courbe de série chronologique. La partie de la courbe qui atteint le seuil d'alerte est affichée en rouge foncé, tandis que la partie qui ne l'atteint pas est affichée en bleu.
Survolez la courbe de série chronologique pour afficher les détails de la ressource à un moment précis.
Sélectionnez une plage horaire sur la courbe de série chronologique pour afficher la courbe pour cette période.
Aucun
Duration
Si une condition d'alerte est remplie, un événement d'alerte est déclenché immédiatement : un événement d'alerte est déclenché si n'importe quel point de données atteint le seuil.
Un événement d'alerte est déclenché uniquement après qu'une condition d'alerte persiste pendant N minutes : un événement d'alerte est déclenché uniquement si la durée pendant laquelle le seuil est atteint est supérieure ou égale à N minutes.
1
Alert Level
Personnalisez le niveau d'alerte. Le niveau d'alerte par défaut est Default. La gravité augmente de Default, P4, P3, P2 à P1.
Default
Alert Content
Informations d'alerte reçues par les utilisateurs. Vous pouvez utiliser la syntaxe de modèle Go pour personnaliser les variables de paramètre d'alerte dans le contenu de l'alerte.
Namespace: {{$labels.namespace}} / Pod: {{$labels.pod_name}} / Container: {{$labels.container}} CPU utilization {{$labels.metrics_params_opt_label_value}} {{$labels.metrics_params_value}}%, Current value: {{ printf "%.2f" $value }}%
Alert Notification
Simple Mode : Définissez le Notification Receiver, la Notification Period et l'option Whether to Resend Notifications.
Standard Mode :
Ne pas spécifier de politique de notification : si vous sélectionnez cette option, après avoir créé la règle d'alerte, vous pouvez créer une nouvelle politique de notification sur la page Notification Policy et spécifier des règles de correspondance et des conditions de correspondance, telles que le nom de la règle d'alerte, pour faire correspondre la règle d'alerte. Lorsque la règle d'alerte est déclenchée et génère un événement d'alerte, les informations d'alerte sont envoyées aux contacts ou aux groupes de contacts spécifiés dans la politique de notification. Pour plus d'informations, consultez Politiques de notification.
Spécifier une politique de notification : si vous sélectionnez cette option, ARMS ajoute automatiquement une règle de correspondance à la politique de notification correspondante. Le contenu de la règle de correspondance est l'ID de la règle d'alerte, présenté sous forme de nom de règle d'alerte. Cela garantit que les événements d'alerte générés par la règle d'alerte actuelle sont mis en correspondance par la politique de notification sélectionnée.
ImportantLa spécification rapide d'une politique de notification garantit uniquement que les événements d'alerte de la règle d'alerte actuelle sont mis en correspondance par la politique de notification sélectionnée et que les alertes correspondantes sont générées. Toutefois, les événements de la règle d'alerte actuelle peuvent également être mis en correspondance par d'autres politiques de notification configurées avec une correspondance floue, ce qui génère également des alertes. La relation entre les événements d'alerte et les politiques de notification est une mise en correspondance plusieurs-à-plusieurs.
Do not specify a notification rule
Advanced Settings
Alert Check Interval
Intervalle auquel le système vérifie la règle d'alerte pour déterminer si les données répondent aux conditions d'alerte. La valeur par défaut est de 1 minute et la valeur minimale est de 1 minute.
1
Check after data is complete
Oui
Non
Oui
Tags
Définissez des tags pour l'alerte. Les tags peuvent être utilisés comme options pour les règles de correspondance des politiques de notification.
Aucun
Annotations
Définissez des annotations pour l'alerte.
Aucun
-
Une fois la configuration terminée, cliquez sur Save. Sur la page de liste des règles d'alerte Prometheus, vous pouvez consulter l'état de la règle d'alerte actuelle.
Si l'Status de la règle d'alerte est Automatic Interruption, modifiez la règle d'alerte pour résoudre la cause de l'interruption. Ensuite, cliquez sur Start et, dans la boîte de dialogue qui s'affiche, cliquez sur Confirm. Si vous ne parvenez pas à résoudre le problème, contactez l'équipe de la fonctionnalité d'alerte ARMS sur DingTalk (ID : d9j_rg9e4062f) pour obtenir de l'aide.
Une règle d'alerte peut être automatiquement interrompue pour les raisons suivantes :
La requête de la règle renvoie plus de 1 500 résultats.
Aucun destinataire de notification n'est configuré dans le système de gestion des alertes.
L'instance Prometheus est désinstallée ou indisponible.
Créer une règle d'alerte Prometheus à l'aide d'une requête PromQL personnalisée
Pour surveiller des métriques non couvertes par les seuils statiques préconfigurés, créez une règle d'alerte avec une requête Prometheus Query Language (PromQL) personnalisée.
-
Sur la page Create Prometheus Alert Rule, définissez les paramètres d'alerte suivants.
Paramètre
Description
Exemple
Alert Name
Nom de l'alerte.
Pod CPU usage is greater than 8 %
Check Type
Définissez sur Custom PromQL query.
Custom PromQL query
Prometheus Instance
Sélectionnez l'instance Prometheus pour laquelle vous souhaitez créer l'alerte.
Aucun
Reference Alert Group
Sélectionnez un groupe d'alertes.
Les différents types d'instances Prometheus prennent en charge différents groupes d'alertes. Les options de groupe d'alertes disponibles varient selon le type d'instance Prometheus sélectionné.
Kubernetes Workload
Reference Alert Metric
Facultatif. Les métriques de référence fournissent des configurations PromQL personnalisées pour les métriques courantes. Sélectionnez une métrique similaire pour préremplir les champs. Ensuite, modifiez la configuration selon vos besoins.
Le paramètre Reference Metric filtre automatiquement les métriques d'alerte prises en charge en fonction du type d'instance Prometheus sélectionné.
Pod disk usage alert
Custom PromQL Statement
Utilisez une instruction PromQL pour définir l'expression de la règle d'alerte.
Namespace: {{$labels.namespace}}/Pod: {{$labels.pod_name}}/Disk device: {{$labels.device}} usage exceeds 90 %, current value {{ printf "%.2f" $value }}%max(container_fs_usage_bytes{pod!="", namespace!="arms-prom",namespace!="monitoring"}) by (pod_name, namespace, device)/max(container_fs_limit_bytes{pod!=""}) by (pod_name,namespace, device) * 100 > 90
Data Preview
La zone Data Preview affiche l'instruction Prometheus Query Language (PromQL) correspondant à la condition d'alerte. Elle présente également les valeurs de la métrique de surveillance sous forme de courbe de série chronologique.
Par défaut, seule la valeur en temps réel d'une ressource est affichée. Vous pouvez sélectionner une ressource cible et une plage horaire dans la zone de filtre de cette section pour afficher les valeurs pour différentes ressources et plages horaires.
RemarqueSurvolez la courbe de série chronologique avec la souris pour afficher les détails de la ressource pour un point de données spécifique.
Sélectionnez une plage horaire sur la courbe pour afficher la série chronologique pour cette période.
Aucun
Duration
Une alerte est déclenchée immédiatement si n'importe quel point de données atteint le seuil.
Une alerte est déclenchée uniquement si la condition persiste pendant N minutes consécutives.
1
Alert Level
Personnalisez le niveau d'alerte. Le niveau d'alerte par défaut est Default. La gravité augmente de Default, P4, P3, P2 à P1.
Default
Alert Content
Informations d'alerte reçues par les utilisateurs. Utilisez la syntaxe de modèle Go pour personnaliser les variables de paramètre dans le contenu de l'alerte.
L'exemple suivant montre un modèle pour une alerte de redémarrage de pod. Cela vous aide à configurer un contenu de notification lisible :
Namespace: {{$labels.namespace}}/Pod: {{$labels.pod_name}} restarted more than {{ $labels.metrics_params_value}} times in {{$labels.metrics_params_time}} minutes. Current restarts: {{ $value }}
Namespace: {{$labels.namespace}}/Pod: {{$labels.pod_name}}/Disk device: {{$labels.device}} usage exceeds 90 %, current value {{ printf "%.2f" $value }}%
Alert Notification
Simple Mode : Définissez le Notification Receiver, la Notification Period et l'option Whether to Resend Notifications.
Standard Mode :
Ne pas spécifier de politique de notification : si vous sélectionnez cette option, après avoir créé la règle d'alerte, vous pouvez créer une nouvelle politique de notification sur la page Notification Policy et spécifier des règles de correspondance et des conditions de correspondance, telles que le nom de la règle d'alerte, pour faire correspondre la règle d'alerte. Lorsque la règle d'alerte est déclenchée et génère un événement d'alerte, les informations d'alerte sont envoyées aux contacts ou aux groupes de contacts spécifiés dans la politique de notification. Pour plus d'informations, consultez Politiques de notification.
Spécifier une politique de notification : si vous sélectionnez cette option, ARMS ajoute automatiquement une règle de correspondance à la politique de notification correspondante. Le contenu de la règle de correspondance est l'ID de la règle d'alerte, présenté sous forme de nom de règle d'alerte. Cela garantit que les événements d'alerte générés par la règle d'alerte actuelle sont mis en correspondance par la politique de notification sélectionnée.
ImportantLa spécification rapide d'une politique de notification garantit uniquement que les événements d'alerte de la règle d'alerte actuelle sont mis en correspondance par la politique de notification sélectionnée et que les alertes correspondantes sont générées. Toutefois, les événements de la règle d'alerte actuelle peuvent également être mis en correspondance par d'autres politiques de notification configurées avec une correspondance floue, ce qui génère également des alertes. La relation entre les événements d'alerte et les politiques de notification est une mise en correspondance plusieurs-à-plusieurs.
Do not specify a notification rule
Advanced Settings
Alert Check Period
Intervalle, en minutes, pour vérifier la règle d'alerte. La valeur minimale est de 1 minute.
1
Check After Data Is Complete
Oui
Non
Oui
Tags
Définissez des tags pour l'alerte. Les tags peuvent être utilisés comme options pour les règles de correspondance des politiques de notification.
Aucun
Annotations
Définissez des annotations pour l'alerte.
Aucun
-
Une fois les paramètres configurés, cliquez sur Save. Sur la page de liste des règles d'alerte Prometheus, vous pouvez consulter l'état de la règle d'alerte.
Si l'Status de la règle d'alerte est Automatic Interruption, modifiez à nouveau la règle en fonction de la raison fournie. Ensuite, cliquez sur Start et cliquez sur Confirm dans la boîte de dialogue qui s'affiche. Si vous ne parvenez pas à résoudre l'interruption, contactez le compte de service de la fonctionnalité d'alerte ARMS (d9j_rg9e4062f) pour obtenir de l'aide.
Une règle d'alerte peut être automatiquement interrompue pour les raisons suivantes :
La requête de la règle renvoie plus de 1 500 résultats.
Aucun destinataire de notification n'est configuré dans le système de gestion des alertes.
L'instance Prometheus est désinstallée ou indisponible.
Gérer les règles d'alerte
Pour les alertes créées sur la page Alerting Rules de la console Managed Service for Prometheus, telles que les alertes à seuil statique et les alertes Prometheus Query Language (PromQL) personnalisées, vous pouvez modifier, activer (pour les alertes à l'état Stopped), désactiver (pour les alertes à l'état Running), supprimer et copier les alertes, ainsi que consulter leur historique d'événements.
Pour les alertes générées dans les consoles d'autres produits Alibaba Cloud, vous pouvez consulter l'historique des événements d'alerte ou revenir à la liste des alertes du produit correspondant.
Après avoir modifié une règle d'alerte, tous les événements d'alerte existants non résolus continuent de se déclencher en fonction de la règle précédente. La nouvelle règle prend effet pour les déclenchements d'alerte ultérieurs uniquement après que vous avez revendiqué et résolu les événements non résolus correspondants sur la page Alert Sending History.
FAQ
Pourquoi les notifications de récupération d'alerte sont-elles retardées ?
Le système intègre un délai pour éviter les faux négatifs causés par les retards de rapport des agents. Lors de chaque vérification, le moteur d'alerte examine les données des 10 dernières minutes. Une alerte est confirmée comme récupérée uniquement après le passage de cette fenêtre temporelle, même si la métrique ne répond plus à la condition d'alerte.
Heure de récupération : La notification de récupération est envoyée environ 10 minutes après que la métrique cesse de déclencher l'alerte.
Détails du mécanisme : Prometheus ne dispose pas de fonctionnalité native de récupération automatique. Il s'appuie sur le mécanisme de détection ARMS pour cette fonctionnalité.
Que faire si la politique de notification est perdue après l'application d'un modèle de règle d'alerte ?
Cause : Les modèles de règles d'alerte ne contiennent pas de paramètres de politique de notification. Lorsque vous réappliquez un modèle, l'ID de la règle peut changer. Cela entraîne l'échec de la politique de notification d'origine, car elle ne peut plus faire correspondre le label _aliyun_arms_alert_rule_id.
Solution : Accédez à et recherchez la politique concernée. Dans la section Dispatch Conditions, utilisez un label plus stable tel que alertname ou le nom du cluster cluster pour réassocier la règle, au lieu d'utiliser l'ID de la règle.
Que faire si je continue à recevoir des alertes en double après avoir modifié l'expression d'alerte pour l'augmenter ?
Cause : Si votre politique de notification est configurée pour renvoyer des notifications toutes les N minutes et est définie sur une récupération manuelle, le système continuera à générer de nouveaux événements d'alerte tant que la métrique répond aux conditions de la nouvelle expression.
Solution : Modifiez la politique de notification. Changez le paramètre de notification répétitive sur « Notify only on the first trigger » ou passez en mode « Automatic recovery ». Vérifiez également que la nouvelle expression est enregistrée et active.
Comment résoudre les problèmes liés à une règle d'alerte Prometheus sans données ou non déclenchée après configuration ?
Suivez ces étapes pour investiguer :
Vérifiez les composants : Assurez-vous que le composant kube-state-metrics est installé sur votre cluster ACK. S'il n'est pas installé, installez-le. Vérifiez l'état du composant Prometheus. Si nécessaire, réinstallez le composant ack-arms-prometheus.
Vérifiez l'historique des déclenchements : Cliquez sur Alert History à côté de la règle pour vérifier les enregistrements de déclenchement. L'absence d'enregistrements indique que les conditions de la règle n'ont pas été remplies. Les causes possibles incluent un nom de métrique incorrect, des données vides ou une plage de temps de requête invalide. Si des enregistrements existent mais qu'aucune notification n'a été envoyée, vérifiez les règles de dispatch dans votre politique de notification. Assurez-vous que les labels, le nom du cluster et les autres conditions correspondent aux critères des règles de dispatch.
Recommandation : Utilisez les derniers modèles d'alerte vérifiés par Alibaba Cloud. Cela permet d'éviter les faux positifs ou les alertes qui ne se déclenchent pas, lesquels peuvent survenir avec des modèles plus anciens.
Vérifiez la syntaxe : Si vous voyez une erreur de page, vérifiez l'expression régulière dans votre requête PromQL. Une expression vide, telle que
{pvc=~}, est invalide et provoquera une erreur. Corrigez-la en{pvc=~".*"}ou en une valeur spécifique.
Y a-t-il des frais pour les alertes de mémoire de pod issues de la surveillance Prometheus sur les clusters ACS ?
Oui. Les clusters ACS prennent en charge la surveillance et l'alerte pour les métriques de mémoire des pods. Vous êtes facturé pour les alertes envoyées par SMS et appel vocal. Les alertes envoyées via le robot DingTalk et Webhook sont gratuites.