Le type de vérification par seuil statique propose des métriques prédéfinies. En sélectionnant une métrique existante, vous pouvez créer rapidement une règle d'alerte.
Dans le volet de navigation de gauche, sélectionnez .
Sur la page Prometheus Alert Rules, cliquez sur Create Prometheus Alert Rule.
-
Sur la page Create Prometheus Alert Rule, configurez les paramètres d'alerte et cliquez sur Save.
Parameter
Description
Example
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 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 CPU 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 n'importe quelle ressource répondant aux conditions de filtre satisfait la règle d'alerte.
Les conditions de filtre suivantes sont disponibles :
Node Monitoring : La règle d'alerte s'applique à toutes les ressources de l'instance Prometheus actuelle. Traverse est la condition de filtre par défaut.
Application Monitoring : 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.
GPU Monitoring : 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 apparaît.
La condition de filtre ne peut pas dépasser 300 caractères.
Traverse
Data Preview
La zone Data Preview affiche l'instruction PromQL (Prometheus Query Language) correspondant à la condition d'alerte. Elle présente également les valeurs de la métrique de surveillance sous forme de courbe 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 rouge droite sur la courbe chronologique. La partie de la courbe atteignant le seuil d'alerte est affichée en rouge foncé, tandis que la partie ne l'atteignant pas est affichée en bleu.
Survolez la courbe chronologique pour afficher les détails de la ressource à un moment précis.
Sélectionnez une plage horaire sur la courbe chronologique pour afficher la courbe correspondante.
None
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.
Vous ne pouvez pas configurer la durée en secondes. Il s'agit d'une limitation du produit et ce comportement est attendu.
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ètres 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 : Vous pouvez définir le Notification Receiver, la Notification Period et l'option Whether to Resend Notifications.
Standard Mode :
Ne spécifiez pas 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 Notification policies.
Spécifiez 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.
ImportantSpécifier rapidement 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 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 le minimum est de 1 minute. Même si vous saisissez une valeur inférieure à 1 minute, telle que 15 secondes, le système effectue toujours la vérification toutes les 1 minute. Il s'agit d'une limitation du produit et ce comportement est attendu.
1
Check after data is complete
Yes
No
Yes
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.
None
Annotations
Définissez des annotations pour l'alerte.
None
Créer une règle d'alerte avec PromQL personnalisé
Pour surveiller des métriques non disponibles dans la liste des seuils statiques, utilisez le type de vérification PromQL personnalisé pour créer une règle d'alerte.
Sur la page Traverse, configurez les paramètres d'alerte suivants et cliquez sur Equal To.
Parameter | Description | Example |
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. | None |
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 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. Modifiez ensuite 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 Not Equal To affiche l'instruction PromQL (Prometheus Query Language) correspondant à la condition d'alerte. Elle présente également les valeurs de la métrique de surveillance sous forme de courbe 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. Remarque
| None |
Duration |
La configuration de la durée en secondes n'est pas prise en charge. Il s'agit d'une limitation du produit et ce comportement est attendu. | 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ètres 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 |
| Do not specify a notification rule |
Advanced Settings | ||
Alert Check Period | Intervalle, en minutes, pour la vérification de la règle d'alerte. La valeur minimale est de 1 minute. Si vous saisissez une valeur inférieure à 1 minute, telle que 15 secondes, le système effectue toujours la vérification toutes les 1 minute. Il s'agit d'une limitation du produit et ce comportement est attendu. | 1 |
Check After Data Is Complete |
| Yes |
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. | None |
Annotations | Définissez des annotations pour l'alerte. | None |
Vous pouvez utiliser Managed Service for Prometheus pour afficher des tableaux de bord prédéfinis et des métriques de performance pour les ACK Edge cluster s. Cette rubrique explique comment connecter un ACK Edge cluster à Managed Service for Prometheus.
Prérequis
Un ACK Edge cluster, version 1.18.8-aliyunedge.1 ou ultérieure.
Assurez-vous que le composant ack-arms-prometheus dans le ACK Edge cluster est en version 1.1.4 ou ultérieure. Sinon, mettez à niveau le composant ack-arms-prometheus.
-
Si votre cluster exécute une version antérieure à 1,26, assurez-vous que le transfert de port est activé pour le port 9100 de Node Exporter et le port 9445 de GPU Exporter dans le ConfigMap
kube-system/edge-tunnel-server-cfg. La configuration suivante est requise :http-proxy-ports: 9445 https-proxy-ports: 9100
Présentation de la surveillance avec Managed Service for Prometheus
Managed Service for Prometheus est entièrement intégré à l'écosystème Prometheus open source. Il prend en charge la surveillance d'un large éventail de composants, fournit divers tableaux de bord prédéfinis et offre un service Prometheus entièrement géré. Avec Managed Service for Prometheus, vous n'avez pas besoin de construire votre propre système de surveillance ni de gérer les problèmes sous-jacents tels que le stockage des données, la visualisation des données et les opérations et la maintenance.
Les ACK Edge cluster s prennent en charge l'édition de base de la surveillance des conteneurs.
Afficher les tableaux de bord Grafana dans Managed Service for Prometheus
Connectez-vous à la console ACK. Dans le volet de navigation de gauche, cliquez sur Clusters.
-
Sur la page Clusters, cliquez sur le nom du cluster cible. Dans le volet de navigation de gauche, sélectionnez .
RemarqueSi c'est la première fois que vous vous connectez, suivez les instructions à l'écran et cliquez sur Install sous le composant. La console installe automatiquement le module complémentaire et vérifie les tableaux de bord. Une fois l'installation terminée, la console vous redirige vers la page des détails de Prometheus Monitoring.
Sur la page Prometheus Monitoring, vous pouvez utiliser les tableaux de bord intégrés, tels que Save, Data Preview et GPU Monitoring, pour afficher les données de surveillance des nœuds, des applications et des GPU dans le cluster.
Configurer les règles d'alerte Prometheus
Créez des règles d'alerte pour recevoir des notifications en temps réel pour des événements spécifiques. Vous pouvez envoyer des notifications via divers canaux, tels que les appels téléphoniques, les e-mails, les messages texte, DingTalk, WeCom et les webhooks, ce qui vous aide à identifier proactivement les anomalies. Les alertes sont acheminées via des politiques de notification vers les contacts ou groupes de contacts appropriés.
Pour plus d'informations sur la création d'un robot DingTalk, consultez DingTalk Robot.
Pour plus d'informations sur la création d'un robot WeCom, consultez WeCom Robot.
Étape 1 : Créer un contact
Connectez-vous à la . Dans le volet de navigation de gauche, sélectionnez .
Sur l'onglet Contacts, cliquez sur Create Contact.
-
Dans la boîte de dialogue Create Contact, configurez les paramètres et cliquez sur Confirm.
Parameter
Description
Name
Nom du contact.
Phone Number
Permet au contact de recevoir des notifications d'alerte par appel téléphonique et message texte.
RemarqueSeuls les numéros de téléphone vérifiés peuvent être utilisés pour les notifications par appel téléphonique dans une politique de notification. Pour savoir comment vérifier un numéro de téléphone, consultez Verify a phone number.
Email
Permet au contact de recevoir des notifications d'alerte par e-mail.
ImportantVous pouvez créer jusqu'à 100 contacts.
FAQ
Comment vérifier la version du module complémentaire ack-arms-prometheus ?
Connectez-vous à la console ACK. Dans le volet de navigation de gauche, cliquez sur Clusters.
Sur la page Clusters, cliquez sur le nom de votre cluster. Dans le volet de navigation de gauche, cliquez sur Components and Add-ons .
-
Sur la page Add-ons, cliquez sur l'onglet Logs and Monitoring et recherchez le module complémentaire ack-arms-prometheus.
La version actuelle est affichée sur la carte du composant. Si une nouvelle version est disponible, cliquez sur Upgrade pour mettre à jour le composant.
RemarqueLe bouton Upgrade n'est affiché que si le composant installé n'est pas la dernière version.
ACK Edge cluster : Comment obtient-il les données de surveillance ?
Dans les scénarios d'informatique en périphérie, les nœuds périphériques sont généralement situés dans des environnements de centres de données sur site relativement isolés. Cela signifie que le VPC basé sur le cloud et les nœuds périphériques fonctionnent dans des réseaux distincts. L'agent Prometheus déployé dans le cloud ne peut pas accéder directement aux endpoints des composants côté périphérie comme Node Exporter et GPU Exporter pour collecter les métriques. À partir de la version 1.1.4 d'ack-arms-prometheus, le composant de communication O&M cloud-native Tunnel intégré aux ACK Edge cluster s permet à ack-arms-prometheus d'établir automatiquement un canal de collecte de données entre le cloud et la périphérie.
Pourquoi le déploiement de la surveillance GPU échoue-t-il ?
Le déploiement de la surveillance GPU peut échouer si le nœud GPU possède des taints. Pour résoudre ce problème, vérifiez d'abord les taints du nœud.
-
Exécutez la commande suivante pour vérifier les taints du nœud GPU cible.
Si le nœud GPU possède des taints personnalisés, vous pouvez trouver les entrées correspondantes. Cet exemple utilise un taint avec une
keydetest-key, unevaluedetest-valueet uneffectdeNoSchedule:kubectl describe node cn-beijing.47.100.***.***Sortie attendue :
Taints:test-key=test-value:NoSchedule -
Gérez les taints du nœud GPU de l'une des deux manières suivantes :
-
Exécutez la commande suivante pour supprimer le taint du nœud GPU.
kubectl taint node cn-beijing.47.100.***.*** test-key=test-value:NoSchedule- -
Déclarez une tolérance pour le taint afin d'autoriser la planification des pods sur le nœud.
# 1. Run the following command to edit the ack-prometheus-gpu-exporter DaemonSet. kubectl edit daemonset -n arms-prom ack-prometheus-gpu-exporter # 2. Add the following fields to the YAML file to declare the toleration for the taint. # Other fields are omitted. # The `tolerations` field is added above the `containers` field and at the same level. tolerations: - key: "test-key" operator: "Equal" value: "test-value" effect: "NoSchedule" containers: # Other fields are omitted.
-
Comment supprimer complètement les ressources ARMS-Prometheus
La suppression du seul namespace de Managed Service for Prometheus laisse des configurations résiduelles après la suppression des ressources. Cela affecte la réinstallation. Vous pouvez effectuer les opérations suivantes pour supprimer manuellement et complètement les configurations résiduelles d'ARMS-Prometheus.
-
Supprimez le namespace arms-prom.
kubectl delete namespace arms-prom -
Supprimez les ClusterRoles.
kubectl delete ClusterRole arms-kube-state-metrics kubectl delete ClusterRole arms-node-exporter kubectl delete ClusterRole arms-prom-ack-arms-prometheus-role kubectl delete ClusterRole arms-prometheus-oper3 kubectl delete ClusterRole arms-prometheus-ack-arms-prometheus-role kubectl delete ClusterRole arms-pilot-prom-k8s kubectl delete ClusterRole gpu-prometheus-exporter kubectl delete ClusterRole o11y:addon-controller:role kubectl delete ClusterRole arms-aliyunserviceroleforarms-clusterrole -
Supprimez les ClusterRoleBindings.
kubectl delete ClusterRoleBinding arms-node-exporter kubectl delete ClusterRoleBinding arms-prom-ack-arms-prometheus-role-binding kubectl delete ClusterRoleBinding arms-prometheus-oper-bind2 kubectl delete ClusterRoleBinding arms-kube-state-metrics kubectl delete ClusterRoleBinding arms-pilot-prom-k8s kubectl delete ClusterRoleBinding arms-prometheus-ack-arms-prometheus-role-binding kubectl delete ClusterRoleBinding gpu-prometheus-exporter kubectl delete ClusterRoleBinding o11y:addon-controller:rolebinding kubectl delete ClusterRoleBinding arms-kube-state-metrics-agent kubectl delete ClusterRoleBinding arms-node-exporter-agent kubectl delete ClusterRoleBinding arms-aliyunserviceroleforarms-clusterrolebinding -
Supprimez les Roles et RoleBindings.
kubectl delete Role arms-pilot-prom-spec-ns-k8s kubectl delete Role arms-pilot-prom-spec-ns-k8s -n kube-system kubectl delete RoleBinding arms-pilot-prom-spec-ns-k8s kubectl delete RoleBinding arms-pilot-prom-spec-ns-k8s -n kube-system
Après avoir supprimé les ressources, retournez à la console ACK, sélectionnez Operations > Add-ons et réinstallez le module complémentaire ack-arms-prometheus.