Cette page explique comment créer des règles d'alerte basées sur les métriques pour les clusters Google Distributed Cloud. Nous avons fourni plusieurs exemples téléchargeables pour vous aider à configurer des règles d'alerte pour des scénarios courants. Pour en savoir plus sur les règles d'alerte basées sur les métriques, consultez la page Créer des règles d'alerte basées sur les métriques dans la documentation Google Cloud Observability.
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
Si vous souhaitez créer des règles d'alerte basées sur les journaux à l'aide de Google Cloud CLI, vous devez également disposer du rôle serviceusage.serviceUsageConsumer
. Pour savoir comment configurer des règles d'alerte basées sur les journaux, consultez la section 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 Google Cloud Console.
Création d'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 des clusters. 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.
Téléchargez le fichier de configuration de la règle : apiserver-unavailable.json.
Créez la règle :
gcloud alpha monitoring policies create --policy-from-file=POLICY_CONFIG
Remplacez POLICY_CONFIG par le chemin d'accès du fichier de configuration que vous venez de télécharger.
Affichez vos règles d'alerte :
Console
Dans Google Cloud Console, accédez à la page Monitoring.
Sur la gauche, sélectionnez Alertes.
Sous Règles, vous pouvez voir la liste de vos règles d'alerte.
Dans la liste, sélectionnez Serveur d'API du cluster Anthos indisponible (critique) pour afficher les détails de votre nouvelle règle. Sous 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 alpha 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 :
Pour télécharger le fichier de configuration, cliquez sur le lien dans la colonne de droite.
Vous pouvez éventuellement ajuster les conditions pour qu'elles correspondent mieux à vos besoins spécifiques. Par exemple, vous pouvez ajouter des filtres supplémentaires pour un sous-ensemble de clusters ou ajuster les valeurs de seuil pour équilibrer le bruit et la criticité.
Pour créer la règle, exécutez
gcloud alpha monitoring policies create
.
Vous pouvez télécharger et installer tous les exemples de règles d'alerte décrits dans ce document en exécutant le script suivant :
# 1. Create a directory named alert_samples:
mkdir alert_samples && cd alert_samples
declare -a alerts=("apiserver-unavailable.json" "controller-manager-unavailable.json" "scheduler-unavailable.json" \
"pod-crash-looping.json" "pod-not-ready-1h.json" "container-cpu-usage-high-reaching-limit.json" \
"container-memory-usage-high-reaching-limit.json" "persistent-volume-usage-high.json" "node-cpu-usage-high.json" \
"node-disk-usage-high.json" "node-memory-usage-high.json" "node-not-ready-1h.json" "apiserver-error-ratio-high.json" \
"etcd-leader-changes-or-proposal-failures-frequent.json" "etcd-server-not-in-quorum.yaml" "etcd-storage-usage-high.json")
# 2. Download all alert samples into the alert_samples/ directory:
for x in "${alerts[@]}"
do
wget https://cloud.google.com/anthos/clusters/docs/bare-metal/latest/samples/${x}
done
# 3. (optional) Uncomment and provide your project ID to set the default project
# for gcloud commands:
# gcloud config set project <PROJECT_ID>
# 4. Create alert policies for each of the downloaded samples:
for x in "${alerts[@]}"
do
gcloud alpha monitoring policies create --policy-from-file=${x}
done
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 temps d'activité du serveur d'API n'est pas disponible | apiserver-unavailable.json |
Programmeur indisponible (critique) | La métrique de temps d'activité du programmeur n'est pas disponible | scheduler-unavailable.json |
Gestionnaire de contrôleurs indisponible (critique) | La métrique de temps d'activité 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 du pod (avertissement) | Le pod redémarre sans cesse et peut être dans une boucle de plantage | pod-crash-looping.json |
Le pod n'est pas prêt depuis 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 |
Volume persistant à forte utilisation (critique) | Le volume persistant demandé 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 des nœuds représente plus de 80% de la quantité totale pouvant être allouée pendant 5 min | node-cpu-usage-high.json |
L'utilisation du disque du nœud dépasse 85 % (avertissement) | Moins de 15 % sont gratuits par point de montage 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 représente plus de 80% de la quantité totale pouvant être allouée pendant 5 min | node-memory-usage-high.json |
Le nœud n'est pas prêt depuis 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% des requêtes par verbe pendant 15 min. | apiserver-error-ratio-high.json |
Changement de responsable ETCD ou échec de la proposition trop fréquent (avertissement) | Les changements de responsable etcd ou les échecs de la proposition se produisent trop fréquemment |
etcd-leader-changes-or-proposal-failures-frequent.json |
Le serveur ETCD n'est pas dans le quorum (critique) | Aucune proposition de serveur etcd validée pendant 5 minutes. Il se peut donc qu'elle ait perdu le quorum |
etcd-server-not-in-quorum.yaml |
Le 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 des règles d'alerte peuvent également être exprimées dans PromQL plutôt que dans 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 en savoir plus, 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.