Créer des règles d'alerte

Cette page explique comment créer des règles d'alerte pour la GDCV pour les clusters Bare Metal.

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 vérifier vos rôles, accédez à la page IAM dans 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 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.

Accéder à 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 non disponible (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 répondent 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/1.16/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 disponibilité 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 ne cesse de redémarrer 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 d'utilisation élevée (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 est supérieure à 80% de la capacité totale pouvant être allouée sur 5 min	node-cpu-usage-high.json
L'utilisation du disque du nœud dépasse 85 % (avertissement)	Moins de 15 % de stockage 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 des nœuds est supérieure à 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 génère des erreurs 5xx ou 429 sur plus de 20% de toutes les requêtes par verbe pendant 15 min.	apiserver-error-ratio-high.json
Changement de responsable ETCD ou échecs de proposition trop fréquents (avertissement)	Les changements de responsable `etcd` ou les échecs de 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 est donc possible qu'elles aient 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 des règles d'alerte peuvent également être exprimées dans PromQL au lieu de MQL. Par exemple, la version PromQL de la stratégie API server error ratio exceeds 20 percent (critical) peut être téléchargée: apiserver-error-ratio-high-promql.json.

Pour en savoir plus, reportez-vous à la page Utiliser Managed Service pour Prometheus dans le cadre de GDCV pour une solution Bare Metal et à la documentation sur les 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.