Créer des règles d'alerte

Cette page explique comment créer des règles d'alerte basées sur des métriques pour les clusters Google Distributed Cloud. Pour en savoir plus sur les règles d'alerte basées sur des métriques, consultez la page Créer des règles d'alerte basées sur des seuils de métriques dans la documentation sur l'observabilité Google Cloud .

Avant de commencer

Vous devez disposer des autorisations suivantes pour créer des règles d'alerte :

• monitoring.alertPolicies.create
• monitoring.alertPolicies.delete
• monitoring.alertPolicies.update

Vous obtenez ces autorisations si vous disposez de l'un des rôles suivants :

• monitoring.alertPolicyEditor
• monitoring.editor
• Éditeur de projet
• Propriétaire du projet

Pour créer une règle d'alerte basée sur les journaux à l'aide de la Google Cloud CLI, vous devez également disposer du serviceusage.serviceUsageConsumer rôle. Pour savoir comment configurer des règles d'alerte basées sur les journaux, consultez la page Configurer des alertes basées sur les journaux dans la documentation Google Cloud Observability.

Pour vérifier vos rôles, accédez à la page IAM dans la Google Cloud console.

Créer un exemple de règle : serveur d'API indisponible

Dans cet exercice, vous allez créer une règle d'alerte pour les serveurs d'API Kubernetes. Une fois cette règle en place, vous pouvez faire en sorte d'être averti dès que le serveur d'API d'un cluster n'est plus disponible.

1. Téléchargez le fichier de configuration de la règle : apiserver-unavailable.json.
2. Créez la règle :

       gcloud monitoring policies create --policy-from-file=POLICY_CONFIG
       

   Remplacez POLICY_CONFIG par le chemin d'accès au fichier de configuration que vous venez de télécharger.

3. Affichez vos règles d'alerte :

   Console

   1. Dans la Google Cloud console, accédez à la page Monitoring.

      Accéder à Monitoring

   2. Sur la gauche, sélectionnez Alertes.
   3. Sous Règles, vous pouvez voir la liste de vos règles d'alerte.

      Dans la liste, sélectionnez Serveur d'API Anthos non disponible (critique) pour afficher les informations détaillées sur votre nouvelle règle. Under Conditions, vous pouvez consulter une description de la règle. Exemple :

      Policy violates when ANY condition is met
      Anthos cluster API server uptime is absent for 5m

   gcloud

   gcloud monitoring policies list

   La sortie affiche des informations détaillées sur la règle. Exemple :

   combiner: OR
   conditions:
   - conditionAbsent:
       aggregations:
       - alignmentPeriod: 60s
         crossSeriesReducer: REDUCE_MEAN
         groupByFields:
         - resource.label.project_id
         - resource.label.location
         - resource.label.cluster_name
         - resource.label.namespace_name
         - resource.label.container_name
         - resource.label.pod_name
         perSeriesAligner: ALIGN_MAX
       duration: 300s
       filter: resource.type = "k8s_container" AND metric.type = "kubernetes.io/anthos/container/uptime"
         AND resource.label."container_name"=monitoring.regex.full_match("kube-apiserver")
       trigger:
         count: 1
     displayName: Anthos cluster API server uptime is absent for 5m
     name: projects/…/alertPolicies/…/conditions/…
   displayName: Anthos cluster API server unavailable (critical)
   enabled: true
   mutationRecord:
     mutateTime: …
     mutatedBy: …
   name: projects/…/alertPolicies/…

Créer des règles d'alerte supplémentaires

Cette section fournit des descriptions et des fichiers de configuration pour un ensemble de règles d'alerte recommandées.

Pour créer une règle, suivez les étapes que vous avez utilisées dans l'exercice précédent :

1. Pour télécharger le fichier de configuration, cliquez sur le lien dans la colonne de droite.
2. Vous pouvez également ajuster les conditions pour mieux répondre à vos besoins spécifiques. Par exemple, vous pouvez ajouter des filtres supplémentaires pour un sous-ensemble de clusters ou ajuster les valeurs seuils pour trouver un équilibre entre le bruit et la criticité.
3. Exécutez gcloud monitoring policies create pour créer la règle.

Disponibilité des composants du plan de contrôle

Nom de l'alerte	Description	Définition de la règle d'alerte dans Cloud Monitoring
Serveur d'API indisponible (critique)	La métrique de disponibilité du serveur d'API n'est pas disponible.	apiserver-unavailable.json
Planificateur indisponible (critique)	La métrique de disponibilité du planificateur n'est pas disponible.	scheduler-unavailable.json
Gestionnaire de contrôleurs indisponible (critique)	La métrique de disponibilité du gestionnaire de contrôleurs n'est pas disponible.	controller-manager-unavailable.json

Système Kubernetes

Nom de l'alerte	Description	Définition de la règle d'alerte dans Cloud Monitoring
Boucle de plantage de pod (avertissement)	Le pod redémarre sans cesse et se trouve peut-être dans une boucle de plantage.	pod-crash-looping.json
Pod indisponible pendant plus d'une heure (critique)	Le pod est dans un état non prêt pendant plus d'une heure.	pod-not-ready-1h.json
L'utilisation du processeur du conteneur dépasse 80 % (avertissement)	L'utilisation du processeur du conteneur dépasse 80 % de la limite.	container-cpu-usage-high-reaching-limit.json
L'utilisation de la mémoire du conteneur dépasse 85 % (avertissement)	L'utilisation de la mémoire du conteneur dépasse 85 % de la limite.	container-memory-usage-high-reaching-limit.json
Utilisation intensive du volume persistant (critique)	Le volume persistant revendiqué dispose de moins de 3 % d'espace libre.	persistent-volume-usage-high.json
L'utilisation du processeur du nœud dépasse 80 % (avertissement)	L'utilisation du processeur du nœud dépasse 80% du total allouable pendant 5 minutes.	node-cpu-usage-high.json
L'utilisation du disque du nœud dépasse 85 % (avertissement)	Moins de 15 % d'espace libre par point d'installation de disque pendant 10 minutes.	node-disk-usage-high.json
L'utilisation de la mémoire du nœud dépasse 80 % (avertissement)	L'utilisation de la mémoire du nœud dépasse 80% du total allouable pendant 5 minutes.	node-memory-usage-high.json
Nœud indisponible pendant plus d'une heure (critique)	Le nœud est dans un état non prêt pendant plus d'une heure.	node-not-ready-1h.json

Performances de Kubernetes

Nom de l'alerte	Description	Définition de la règle d'alerte dans Cloud Monitoring
Le taux d'erreur du serveur d'API dépasse 20 % (critique)	Le serveur d'API renvoie des erreurs 5xx ou 429 sur plus de 20% de toutes les requêtes par verbe pendant 15 minutes.	apiserver-error-ratio-high.json
Modification de la variante optimale ETCD ou échec de la proposition trop fréquent (avertissement)	Les modifications de la variante optimale etcd ou les échecs de propositions sont trop fréquents	etcd-leader-changes-or-proposal-failures-frequent.json
Serveur ETCD hors quorum (critique)	Aucune proposition de serveur etcd n'a été validée pendant 5 minutes. Il est donc possible qu'il ait perdu le quorum.	etcd-server-not-in-quorum.yaml
L'espace de stockage ETCD dépasse la limite de 90 % (avertissement)	L'utilisation de l'espace de stockage etcd dépasse 90 % de la limite.	etcd-storage-usage-high.json

Règles d'alerte avec PromQL

Les requêtes dans les règles d'alerte peuvent également être exprimées en PromQL au lieu de MQL. Par exemple, la version PromQL de la règle API server error ratio exceeds 20 percent (critical) peut être téléchargée : apiserver-error-ratio-high-promql.json.

Pour plus d'informations, consultez la documentation Utiliser Managed Service pour Prometheus pour Google Distributed Cloud et la documentation Règles d'alerte avec PromQL pour Cloud Monitoring.

Recevoir des notifications

Une fois que vous avez créé une règle d'alerte, vous pouvez définir un ou plusieurs canaux de notification pour cette règle. Il existe plusieurs types de canaux de notification. Par exemple, vous pouvez être averti par e-mail, ou via un canal Slack ou une application mobile. Vous pouvez choisir les canaux qui répondent à vos besoins.

Pour obtenir des instructions sur la configuration des canaux de notification, consultez la page Gérer les canaux de notification.