Évaluation des règles et alertes auto-déployées

Le service géré Google Cloud pour Prometheus est compatible avec l'évaluation des règles compatibles avec Prometheus ainsi qu'avec les alertes. Ce document explique comment configurer l'évaluation des règles auto-déployées, y compris le composant d'évaluateur de règle autonome.

Vous ne devez suivre ces instructions que si vous souhaitez exécuter des règles et des alertes sur le datastore global.

Évaluation des règles pour une collection auto-déployée

Après avoir déployé Managed Service pour Prometheus, vous pouvez continuer à évaluer les règles localement dans chaque instance déployée à l'aide du champ rule_files de votre fichier de configuration Prometheus. Toutefois, la fenêtre de requête maximale pour les règles est limitée par la durée de conservation des données locales par le serveur.

La plupart des règles ne s'exécutent que sur les dernières minutes de données. L'exécution de règles sur chaque serveur local est donc souvent une stratégie valide. Dans ce cas, aucune configuration supplémentaire n'est nécessaire.

Toutefois, il est parfois utile de pouvoir évaluer les règles par rapport au backend de métrique globale, par exemple lorsque toutes les données d'une règle ne sont pas colocalisées sur une instance Prometheus donnée. Dans ces cas, Managed Service pour Prometheus fournit également un composant évaluateur de règle.

Avant de commencer

Cette section décrit la configuration nécessaire pour les tâches décrites dans ce document.

Configurer votre environnement

Pour éviter de saisir à plusieurs reprises l'ID de votre projet ou le nom de votre cluster, effectuez la configuration suivante :

Configurez les outils de ligne de commande comme suit :
- Configurez la CLI gcloud pour faire référence à l'ID de votre projet Google Cloud :
```
gcloud config set project PROJECT_ID
```
- Configurez la CLI kubectl pour utiliser votre cluster :
```
kubectl config set-cluster CLUSTER_NAME
```
Pour en savoir plus sur ces outils, consultez les articles suivants :
- Présentation de la CLI gcloud
- Commandes kubectl

Configurer un espace de noms

Créez l'espace de noms Kubernetes NAMESPACE_NAME pour les ressources que vous créez dans le cadre de l'exemple d'application :

kubectl create ns NAMESPACE_NAME

Vérifier les identifiants du compte de service

Vous pouvez ignorer cette section si Workload Identity est activé pour votre cluster Kubernetes.

Lors de l'exécution sur GKE, Managed Service pour Prometheus récupère automatiquement les identifiants de l'environnement en fonction du compte de service Compute Engine par défaut. Le compte de service par défaut dispose des autorisations nécessaires, monitoring.metricWriter et monitoring.viewer, par défaut. Si vous n'utilisez pas Workload Identity et que vous avez précédemment supprimé l'un de ces rôles du compte de service de nœud par défaut, vous devrez rajouter ces autorisations manquantes avant de continuer.

Si vous n'exécutez pas sur GKE, consultez la section Fournir les identifiants explicitement.

Configurer un compte de service pour Workload Identity

Vous pouvez ignorer cette section si Workload Identity n'est pas activé pour votre cluster Kubernetes.

Managed Service pour Prometheus capture les données de métriques à l'aide de l'API Cloud Monitoring. Si votre cluster utilise Workload Identity, vous devez autoriser votre compte de service Kubernetes à accéder à l'API Monitoring. Cette section décrit les opérations suivantes :

Créer un compte de service Google Cloud dédié, gmp-test-sa.
Associer le compte de service Google Cloud au compte de service Kubernetes par défaut dans un espace de noms de test, NAMESPACE_NAME.
Accorder l'autorisation nécessaire au compte de service Google Cloud.

Créer et associer le compte de service

Cette étape apparaît à plusieurs endroits de la documentation de Managed Service pour Prometheus. Si vous avez déjà effectué cette étape dans le cadre d'une tâche précédente, vous n'avez pas besoin de la répéter. Passez directement à la section Autoriser le compte de service.

La séquence de commandes suivante crée le compte de service gmp-test-sa et l'associe au compte de service Kubernetes par défaut dans l'espace de noms NAMESPACE_NAME :

gcloud config set project PROJECT_ID \
&&
gcloud iam service-accounts create gmp-test-sa \
&&
gcloud iam service-accounts add-iam-policy-binding \
  --role roles/iam.workloadIdentityUser \
  --member "serviceAccount:PROJECT_ID.svc.id.goog[NAMESPACE_NAME/default]" \
  gmp-test-sa@PROJECT_ID.iam.gserviceaccount.com \
&&
kubectl annotate serviceaccount \
  --namespace NAMESPACE_NAME \
  default \
  iam.gke.io/gcp-service-account=gmp-test-sa@PROJECT_ID.iam.gserviceaccount.com

Si vous utilisez un autre espace de noms ou compte de service GKE, ajustez les commandes en conséquence.

Autoriser le compte de service

Les groupes d'autorisations associées sont collectés dans des rôles que vous attribuez à un compte principal, dans cet exemple, le compte de service Google Cloud. Pour en savoir plus sur ces rôles, consultez la page Contrôle des accès.

La commande suivante accorde au compte de service Google Cloud gmp-test-sa les rôles de l'API Monitoring dont il a besoin pour lire et écrire les données de métriques.

Si vous avez déjà attribué un rôle spécifique au compte de service Google Cloud dans le cadre de la tâche précédente, vous n'avez pas besoin de le faire à nouveau.

gcloud projects add-iam-policy-binding PROJECT_ID \
  --member=serviceAccount:gmp-test-sa@PROJECT_ID.iam.gserviceaccount.com \
  --role=roles/monitoring.viewer \
&& \
gcloud projects add-iam-policy-binding PROJECT_ID\
  --member=serviceAccount:gmp-test-sa@PROJECT_ID.iam.gserviceaccount.com \
  --role=roles/monitoring.metricWriter

Déboguer votre configuration Workload Identity

Si vous rencontrez des difficultés pour utiliser Workload Identity, consultez la documentation sur la vérification de la configuration de Workload Identity et le guide de dépannage de Workload Identity.

Les fautes de frappe et les copier-coller partiels sont les sources d'erreurs les plus courantes lors de la configuration de Workload Identity. Nous vous recommandons vivement d'utiliser les variables modifiables et les icônes de copier-coller cliquables intégrées dans les exemples de code figurant dans ces instructions.

Workload Identity dans les environnements de production

L'exemple décrit dans ce document associe le compte de service Google Cloud au compte de service Kubernetes par défaut et accorde au compte de service Google Cloud toutes les autorisations nécessaires pour utiliser l'API Monitoring.

Dans un environnement de production, vous pouvez utiliser une approche plus précise, avec un compte de service pour chaque composant, chacun disposant d'autorisations minimales. Pour en savoir plus sur la configuration des comptes de service pour la gestion des identités de charge de travail, consultez la page Utiliser Workload Identity.

Déployer l'évaluateur de règle autonome

L'évaluateur de règle de Managed Service pour Prometheus évalue les règles d'alerte et d'enregistrement Prometheus par rapport à l'API HTTP de Managed Service pour Prometheus et réécrit les résultats dans Monarch. Il accepte le même format de fichier de configuration et le même format de fichier de règle que Prometheus. Les options sont également presque identiques.

Créez un exemple de déploiement de l'évaluateur de règle préconfiguré pour évaluer une alerte et une règle d'enregistrement :

kubectl apply -n NAMESPACE_NAME -f https://raw.githubusercontent.com/GoogleCloudPlatform/prometheus-engine/v0.10.0/manifests/rule-evaluator.yaml

Vérifiez que les pods de l'évaluateur de règle ont bien été déployés :

kubectl -n NAMESPACE_NAME get pod

Si le déploiement aboutit, un résultat semblable au suivant s'affiche :

NAME                              READY   STATUS    RESTARTS   AGE
...
rule-evaluator-64475b696c-95z29   2/2     Running   0          1m

Après avoir vérifié que l'évaluateur de règle a bien été déployé, vous pouvez ajuster les fichiers manifestes installés pour effectuer les opérations suivantes :

Ajoutez les fichiers de règles personnalisées.
Configurez l'évaluateur de règle pour envoyer des alertes à un Alertmanager Prometheus auto-déployé à l'aide du champ alertmanager_config du fichier de configuration.

Si votre Alertmanager se trouve dans un cluster différent de celui de votre évaluateur de règle, vous devrez peut-être configurer une ressource Endpoints. Par exemple, si la ressource OperatorConfig indique que les points de terminaison Alertmanager peuvent se trouver dans l'objet Endpoints ns=alertmanager/name=alertmanager, vous pouvez créer manuellement ou automatiquement cet objet et le renseigner avec des adresses IP accessibles depuis l'autre cluster.

Fournir des identifiants de manière explicite

Lors de l'exécution sur GKE, l'évaluateur de règle récupère automatiquement les identifiants de l'environnement en fonction du compte de service du nœud ou de la configuration de Workload Identity. Dans les clusters Kubernetes non GKE, les identifiants doivent être explicitement fournis à l'évaluateur de règle à l'aide d'options ou de la variable d'environnement GOOGLE_APPLICATION_CREDENTIALS.

Définissez le contexte de votre projet cible :
```
gcloud config set project PROJECT_ID
```
Créez un compte de service :
```
gcloud iam service-accounts create gmp-test-sa
```
Cette étape crée le compte de service que vous avez peut-être déjà créé dans les instructions de Workload Identity.

Accordez les autorisations requises au compte de service :

gcloud projects add-iam-policy-binding PROJECT_ID \
  --member=serviceAccount:gmp-test-sa@PROJECT_ID.iam.gserviceaccount.com \
  --role=roles/monitoring.viewer \
&& \
gcloud projects add-iam-policy-binding PROJECT_ID\
  --member=serviceAccount:gmp-test-sa@PROJECT_ID.iam.gserviceaccount.com \
  --role=roles/monitoring.metricWriter

Créez et téléchargez une clé pour le compte de service :

gcloud iam service-accounts keys create gmp-test-sa-key.json \
  --iam-account=gmp-test-sa@PROJECT_ID.iam.gserviceaccount.com

Ajoutez le fichier de clé en tant que secret à votre cluster non-GKE :

kubectl -n NAMESPACE_NAME create secret generic gmp-test-sa \
  --from-file=key.json=gmp-test-sa-key.json

Ouvrez la ressource "Déploiement" de l'évaluateur de règle pour la modifier :
```
kubectl -n NAMESPACE_NAME edit deploy rule-evaluator
```
1. Ajoutez le texte affiché en gras à la ressource :
```
apiVersion: apps/v1
kind: Deployment
metadata:
  namespace: NAMESPACE_NAME
  name: rule-evaluator
spec:
  template
    containers:
    - name: evaluator
      args:
      - --query.credentials-file=/gmp/key.json
      - --export.credentials-file=/gmp/key.json
...
      volumeMounts:
      - name: gmp-sa
        mountPath: /gmp
        readOnly: true
...
    volumes:
    - name: gmp-sa
      secret:
        secretName: gmp-test-sa
...
```
2. Enregistrez le fichier et fermez l'éditeur. Une fois la modification appliquée, les pods sont recréés et commencent à s'authentifier auprès du backend de métrique avec le compte de service donné.
Plutôt que d'utiliser les options définies dans cet exemple, vous pouvez définir le chemin d'accès du fichier de clé à l'aide de la variable d'environnement GOOGLE_APPLICATION_CREDENTIALS.
Évaluation des règles multiprojets et globales

Nous vous recommandons d'exécuter une instance de l'évaluateur de règle dans chaque projet et région Google Cloud, plutôt que d'en exécuter une qui évalue par rapport à de nombreux projets et régions. Toutefois, l'évaluation des règles multiprojets est acceptée dans les scénarios qui en ont besoin.

Lorsqu'il est déployé sur Google Kubernetes Engine, l'évaluateur de règle utilise le projet Google Cloud associé au cluster, qu'il détecte automatiquement. Pour évaluer les règles qui s'appliquent à plusieurs projets, vous pouvez remplacer le projet interrogé à l'aide de l'option --query.project-id et en spécifiant un projet avec un champ d'application de métriques multiprojets. Si le champ d'application des métriques contient tous vos projets, vos règles sont évaluées globalement. Pour plus d'informations, consultez la section Champs d'application des métriques.

Vous devez également mettre à jour les autorisations du compte de service utilisé par l'évaluateur de règle pour que le compte de service puisse lire le projet de champ d'application et écrire dans tous les projets surveillés du champ d'application des métriques.

Conserver les libellés lors de l'écriture des règles

Pour les données écrites dans Managed Service pour Prometheus, l'évaluateur accepte les mêmes options --export.* et la même configuration basée sur external_labels que le binaire du serveur Managed Service pour Prometheus. Nous vous recommandons vivement d'écrire des règles de sorte que les libellés project_id, location, cluster et namespace soient conservés de manière appropriée par rapport à leur niveau d'agrégation. Sinon, les requêtes peuvent être moins performantes et vous pouvez rencontrer des limites de cardinalité.

Les libellés project_id ou location sont obligatoires. Si ces libellés sont manquants, les valeurs des résultats de l'évaluation des règles sont définies en fonction de la configuration de l'évaluateur de règle. Les libellés cluster ou namespace manquants ne sont pas associés à des valeurs.

Déploiements à haute disponibilité

L'évaluateur de règle peut être exécuté dans une configuration à haute disponibilité en suivant la même approche que celle documentée pour le serveur Prometheus.

Créer des alertes à l'aide des métriques Cloud Monitoring

Vous pouvez configurer l'évaluateur de règle pour qu'il vous alerte sur les métriques système Google Cloud à l'aide de PromQL. Pour obtenir des instructions sur la création d'une requête valide, consultez la page PromQL pour les métriques Cloud Monitoring.