Évaluation des règles gérées

Google Cloud Managed Service pour Prometheus accepte l'évaluation des règles compatibles avec Prometheus. Ce document explique comment configurer l'évaluation des règles gérées.

Évaluation des règles

Managed Service pour Prometheus fournit un composant évaluateur de règle qui vous permet d'écrire des règles en toute sécurité dans le contexte d'un backend global Prometheus, ce qui vous évite d'interférer avec les données d'autres utilisateurs dans les grandes organisations. Le composant est automatiquement déployé dans le cadre d'une collection gérée lors de l'exécution sur des clusters Kubernetes.

Règles

L'évaluateur de règle gérée utilise la ressource Règles pour configurer l'enregistrement et les règles d'alerte. Voici un exemple de ressource Règles :

apiVersion: monitoring.googleapis.com/v1
kind: Rules
metadata:
  namespace: gmp-test
  name: example-rules
spec:
  groups:
  - name: example
    interval: 30s
    rules:
    - record: job:up:sum
      expr: sum without(instance) (up)
    - alert: AlwaysFiring
      expr: vector(1)

Le format de l'élément .spec.groups est identique au tableau Prometheus rule_group en amont. Les règles d'alerte et d'enregistrement définies dans Rules sont limitées à project_id, cluster et namespace de la ressource. Par exemple, la règle job:up:sum de la ressource ci-dessus interroge efficacement sum without(instance) (up{project_id="test-project", cluster="test-cluster", namespace="gmp-test"}). Cette garantie empêche les règles d'alerte ou d'enregistrement d'évaluer accidentellement les métriques d'applications que vous ne connaissez peut-être même pas.

Pour appliquer les exemples de règles à votre cluster, exécutez la commande suivante :

kubectl apply -n gmp-test -f https://raw.githubusercontent.com/GoogleCloudPlatform/prometheus-engine/v0.4.0/examples/rules.yaml

Après quelques minutes, la métrique job:up:sum devient disponible. L'alerte AlwaysFiring commence également à se déclencher. Pour en savoir plus sur l'envoi d'alertes à Alertmanager, consultez la page Configuration d'Alertmanager.

Les ressources ClusterRules et GlobalRules fournissent la même interface que la ressource Rules, mais elles appliquent les règles à des champs d'application plus larges. Les objets ClusterRules sélectionnent les données à l'aide des libellés project_id et cluster, et les règles globales sélectionnent toutes les données dans le champ d'application des métriques interrogées sans restreindre les libellés.

Pour obtenir une documentation de référence sur toutes les ressources personnalisées Managed Service pour Prometheus, consultez la documentation prometheus-engine/doc/api reference.

Convertir des règles Prometheus en ressource Règles

La ressource Règles fournit une interface compatible avec les règles Prometheus afin de fournir un chemin de migration fluide pour intégrer les règles existantes dans l'évaluation des règles gérées. Vous pouvez inclure vos règles existantes dans une ressource Règles. Par exemple, voici une règle Prometheus :

groups:
- name: example
  interval: 30s
  rules:
  - record: job:up:sum
    expr: sum without(instance) (up)
  - alert: AlwaysFiring
    expr: vector(1)

La ressource Règles correspondante, avec la règle Prometheus d'origine en gras est la suivante :

apiVersion: monitoring.googleapis.com/v1
kind: Rules
metadata:
  namespace: gmp-test
  name: example-rules
spec:
  groups:
  - name: example
    interval: 30s
    rules:
    - record: job:up:sum
      expr: sum without(instance) (up)
    - alert: AlwaysFiring
      expr: vector(1)

ClusterRules

Vous pouvez utiliser la ressource ClusterRules pour configurer les règles d'enregistrement et d'alerte pouvant évaluer toutes les séries temporelles envoyées à Managed Service pour Prometheus à partir de tous les espaces de noms d'un cluster particulier. La spécification est identique à celle de Rules. L'exemple de règle Prometheus précédent devient la ressource ClusterRules suivante :

apiVersion: monitoring.googleapis.com/v1
kind: ClusterRules
metadata:
  name: example-clusterrules
spec:
  groups:
  - name: example
    interval: 30s
    rules:
    - record: job:up:sum
      expr: sum without(instance) (up)
    - alert: AlwaysFiring
      expr: vector(1)

Nous vous recommandons de n'utiliser les ressources ClusterRules que sur les métriques horizontales, telles que celles produites par un maillage de services. Pour les métriques de déploiements individuels, utilisez les ressources Règles pour vous assurer que l'évaluation n'inclut pas de données indésirables.

GlobalRules

Vous pouvez utiliser la ressource GlobalRules pour configurer les règles d'enregistrement et d'alerte pouvant évaluer toutes les séries temporelles envoyées à Managed Service pour Prometheus dans tous les projets d'un champ d'application de métriques. La spécification est identique à celle de Rules. L'exemple de règle Prometheus précédent devient la ressource GlobalRules suivante :

apiVersion: monitoring.googleapis.com/v1
kind: GlobalRules
metadata:
  name: example-globalrules
spec:
  groups:
  - name: example
    interval: 30s
    rules:
    - record: job:up:sum
      expr: sum without(instance) (up)
    - alert: AlwaysFiring
      expr: vector(1)

Nous vous recommandons de n'utiliser des GlobalRules que pour les cas d'utilisation rares où une alerte peut nécessiter des données sur tous les clusters à la fois. Pour les métriques de déploiements individuels, utilisez les ressources Rules ou ClusterRules pour améliorer la fiabilité et vous assurer que l'évaluation n'inclut pas de données indésirables.

Nous vous recommandons vivement de conserver les libellés cluster et namespace dans les résultats de l'évaluation de la règle, sauf si l'objectif de la règle est d'agréger ces libellés, sinon les performances des requêtes peuvent diminuer et vous risquez de rencontrer des problèmes de limites de cardinalité. Il est fortement déconseillé de supprimer les deux libellés.

Évaluation des règles multiprojets et globales

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 devez configurer l'évaluateur de règle qui exécute la ressource GlobalRules pour qu'il utilise un projet avec un champ d'application de métriques multiprojets. Pour cela, vous avez le choix entre deux méthodes :

  • Placez votre ressource GlobalRules dans un projet doté d'un champ d'application de métriques multiprojets.
  • Définissez le champ queryProjectID dans OperatorConfig pour utiliser un projet avec un champ d'application de métriques multiprojets.

Vous devez également mettre à jour les autorisations du compte de service utilisé par l'évaluateur de règle (il s'agit généralement du compte de service par défaut sur le nœud) 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.

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.

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 Compute Engine par défaut ou de la configuration de Workload Identity.

Dans les clusters Kubernetes non GKE, les identifiants doivent être explicitement fournis via la ressource OperatorConfig dans l'espace de noms gmp-public.

  1. Créez un compte de service :

    gcloud iam service-accounts create gmp-test-sa
    

  2. 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
    

  3. 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
    
  4. Ajoutez le fichier de clé en tant que secret à votre cluster non-GKE :

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

  5. Ouvrez la ressource OperatorConfig pour la modifier :

    kubectl -n gmp-public edit operatorconfig config
    

  6. Ajoutez le texte affiché en gras à la ressource :

    apiVersion: monitoring.googleapis.com/v1
    kind: OperatorConfig
    metadata:
      namespace: gmp-public
      name: config
    rules:
      credentials:
        name: gmp-test-sa
        key: key.json
    

  7. 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é.

Configuration d'Alertmanager

Vous pouvez utiliser la ressource OperatorConfig pour configurer l'évaluateur de règle gérée afin d'envoyer des alertes à un Alertmanager Prometheus auto-déployé. Pour configurer l'évaluateur de règle, procédez comme suit :

  1. Ouvrez la ressource OperatorConfig pour la modifier :

    kubectl -n gmp-public edit operatorconfig config
    
  2. Configurez la ressource pour envoyer des alertes à votre service Alertmanager :

    apiVersion: monitoring.googleapis.com/v1
    kind: OperatorConfig
    metadata:
      namespace: gmp-public
      name: config
    rules:
      alerting:
        alertmanagers:
        - name: SERVICE_NAME
          namespace: SERVICE_NAMESPACE
          port: PORT_NAME
    

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. La section de configuration AlertmanagerEndpoints fournit des options permettant de configurer des autorisations si nécessaire.