Exécuter une requête à l'aide de l'API ou de l'interface utilisateur Prometheus

Après avoir déployé Google Cloud Managed Service pour Prometheus, vous pouvez interroger les données envoyées au service géré et afficher les résultats dans des graphiques et des tableaux de bord.

Ce document décrit les champs d'application de métriques, qui déterminent les données que vous pouvez interroger, ainsi que les méthodes suivantes basées sur Prometheus pour récupérer et utiliser les données que vous avez collectées :

API HTTP Prometheus
Interface utilisateur Prometheus

Toutes les interfaces de requête de Managed Service pour Prometheus sont configurées pour récupérer les données de Monarch à l'aide de l'API Cloud Monitoring. En interrogeant Monarch au lieu d'interroger les données des serveurs Prometheus locaux, vous obtenez une surveillance globale à grande échelle.

Avant de commencer

Si vous n'avez pas encore déployé le service géré, configurez la collecte gérée ou la collecte auto-déployée. Vous pouvez ignorer cette étape si vous souhaitez uniquement interroger des métriques Cloud Monitoring à l'aide de PromQL.

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 limited-feature mode 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 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.

Pour autoriser votre compte de service à lire les données de métriques d'un champ d'application de métriques multiprojets, suivez ces instructions, puis consultez la section Modifier le projet interrogé.

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

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.

Champs d'application des requêtes et des métriques

Les données que vous pouvez interroger sont déterminées par le champ d'application des métriques Cloud Monitoring, quelle que soit la méthode que vous utilisez pour interroger les données. Par exemple, si vous utilisez Grafana pour interroger les données de Managed Service pour Prometheus, chaque champ d'application des métriques doit être configuré en tant que source de données distincte.

Un champ d'application des métriques Monitoring est une structure en lecture seule qui vous permet d'interroger les données de métriques appartenant à plusieurs projets Google Cloud. Chaque champ d'application des métriques est hébergé par un projet Google Cloud désigné, appelé projet de champ d'application.

Par défaut, un projet est le projet de champ d'application pour son propre champ d'application des métriques. Le champ d'application des métriques contient les métriques et la configuration de ce projet. Un projet de champ d'application peut avoir plusieurs projets surveillés dans son champ d'application des métriques, et les métriques et les configurations de tous les projets surveillés dans le champ d'application des métriques sont visibles dans le projet de champ d'application. Un projet surveillé peut également appartenir à plusieurs champs d'application des métriques.

Lorsque vous interrogez les métriques d'un projet effectuant une surveillance et si ce projet héberge un champ d'application des métriques multiprojets, vous pouvez extraire les données de plusieurs projets. Si le champ d'application des métriques contient tous vos projets, vos requêtes et règles sont évaluées globalement.

Pour en savoir plus sur les projets de champ d'application et les champs d'application des métriques, consultez la section Champs d'application des métriques. Pour en savoir plus sur la configuration d'un champ d'application de métriques multiprojets, consultez la section Afficher les métriques de plusieurs projets.

Données Managed Service pour Prometheus dans Cloud Monitoring

Le moyen le plus simple de vérifier que vos données Prometheus sont exportées consiste à utiliser la page de l'Explorateur de métriques Cloud Monitoring dans Google Cloud Console, qui est compatible avec PromQL. Pour obtenir des instructions, consultez la page Interroger des données à l'aide de PromQL dans Cloud Monitoring.

Interface utilisateur autonome de Prometheus

Vous pouvez utiliser l'interface utilisateur autonome de Prometheus pour accéder aux données ingérées et les visualiser. Cette interface utilisateur exécute les requêtes PromQL sur toutes les données de votre projet Google Cloud, comme déterminé par le champ d'application des métriques associé à votre projet.

L'interface utilisateur agit également en tant que proxy d'authentification pour l'accès aux données ingérées. Cette fonctionnalité peut être utilisée pour les outils clients qui ne sont pas compatibles avec OAuth2 pour les comptes de service, y compris Grafana ou l'autoscaling horizontal des pods à l'aide de la bibliothèque prometheus-adapter.

Nous vous recommandons vivement de configurer Grafana pour visualiser les données de Managed Service pour Prometheus à l'aide du synchronisateur de sources de données. Les instructions de configuration de Grafana à l'aide de l'interface utilisateur autonome de Prometheus sont incluses ici comme référence pour les utilisateurs qui ont déjà configuré Grafana en utilisant cette méthode.

Déployer l'interface utilisateur

Pour déployer l'interface utilisateur autonome de Prometheus afin de l'utiliser avec Managed Service pour Prometheus, exécutez les commandes suivantes :

Déployez le service frontend et configurez-le pour interroger le projet de champ d'application du champ d'application des métriques de votre choix :

curl https://raw.githubusercontent.com/GoogleCloudPlatform/prometheus-engine/v0.12.0/examples/frontend.yaml |
sed 's/\$PROJECT_ID/PROJECT_ID/' |
kubectl apply -n NAMESPACE_NAME -f -

Transférez le service frontend vers votre ordinateur local. L'exemple suivant transfère le service au port 9090 :
```
kubectl -n NAMESPACE_NAME port-forward svc/frontend 9090
```
Cette commande ne renvoie pas de résultat et signale les accès à l'URL pendant son exécution.

Si vous souhaitez continuer à utiliser un déploiement Grafana installé par kube-prometheus, déployez plutôt l'interface utilisateur autonome de Prometheus dans l'espace de noms monitoring.

Vous pouvez accéder à l'interface utilisateur autonome de Prometheus dans votre navigateur à l'adresse http://localhost:9090. Si vous utilisez Cloud Shell à cette étape, vous pouvez obtenir un accès à l'aide du bouton Aperçu sur le Web.

La capture d'écran suivante montre une table contenant la métrique up dans l'interface utilisateur autonome de Prometheus :

Afficher une métrique dans l'interface de Prometheus.

Vous pouvez également configurer l'authentification et l'autorisation appropriées sur le service frontend en utilisant, par exemple, Identity Aware Proxy. Pour en savoir plus sur l'exposition des services, consultez la page Exposer des applications à l'aide de services.

Modifier le projet interrogé pour obtenir une surveillance multiprojet

Le déploiement frontend utilise le projet Google Cloud configuré comme projet de champ d'application. Si ce projet est le projet d'un champ d'application des métriques multiprojets, il peut lire les métriques de tous les projets dans le champ d'application des métriques.

Vous pouvez spécifier un projet avec un champ d'application de métriques multiprojets à l'aide de l'option --query.project-id.

En règle générale, vous utilisez un projet dédié en tant que projet de champ d'application. Ce projet n'est pas le même que celui dans lequel le déploiement frontend s'exécute. Pour permettre au déploiement de lire un autre projet cible, vous devez procéder comme suit :

Indiquez au déploiement frontend quel projet est le projet cible.
Accordez au compte de service l'autorisation de lire le projet cible. Si vous avez utilisé le compte de service Compute Engine default, vous pouvez effectuer l'une des opérations suivantes :
- Activez Workload Identity pour votre cluster et suivez les étapes de configuration.
- Indiquez une clé de compte de service explicite.

Pour accorder les autorisations nécessaires pour accéder à un autre projet Google Cloud, procédez comme suit :

Accordez au compte de service l'autorisation de lire à partir du projet cible que vous souhaitez interroger :

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

Ouvrez le déploiement frontend créé précédemment pour le modifier :
```
kubectl -n NAMESPACE_NAME edit deploy frontend
```
Spécifiez le projet cible à l'aide de l'option --query.project-id :
```
apiVersion: apps/v1
kind: Deployment
metadata:
  namespace: NAMESPACE_NAME
  name: frontend
spec:
  template
    containers:
    - name: frontend
      args:
      - --query.project-id=SCOPING_PROJECT_ID
...
```
Enregistrez le fichier et fermez l'éditeur. Une fois la modification appliquée, les pods frontend sont redémarrés et interrogent le nouveau projet de champ d'application.

Authentifier l'interface utilisateur

Le déploiement frontend est compatible avec l'authentification de base pour l'accès authentifié dans les versions 0.5.0 et ultérieures. Pour activer l'authentification, ajoutez les variables d'environnement AUTH_USERNAME et AUTH_PASSWORD au déploiement :

apiVersion: apps/v1
kind: Deployment
metadata:
  namespace: NAMESPACE_NAME
  name: frontend
spec:
  template
    containers:
    - name: frontend
      env:
      - name: AUTH_USERNAME
        value: USERNAME
      - name: AUTH_PASSWORD
        value: PASSWORD
...

Fournir des identifiants de manière explicite

Vous pouvez ignorer cette section si vous exécutez le conteneur frontend dans un cluster Google Kubernetes Engine. Si vous rencontrez des problèmes d'authentification sur GKE, consultez la page Vérifier les identifiants du compte de service.

Lors de l'exécution sur GKE, l'interface 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'interface à 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

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'interface pour la modifier :
```
kubectl -n NAMESPACE_NAME edit deploy frontend
```
1. Ajoutez le texte affiché en gras à la ressource :
```
apiVersion: apps/v1
kind: Deployment
metadata:
  namespace: NAMESPACE_NAME
  name: frontend
spec:
  template
    containers:
    - name: frontend
      args:
      - --query.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.
Utiliser Grafana via le proxy d'interface

Managed Service pour Prometheus utilise la source de données Prometheus intégrée pour Grafana, ce qui signifie que vous pouvez continuer à utiliser n'importe quel tableau de bord Grafana créé par la communauté ou personnel sans aucune modification. Vous pouvez également importer vos tableaux de bord Grafana dans Cloud Monitoring.

S'authentifier sur les API Google Cloud

Avertissement : Nous vous recommandons vivement de configurer Grafana pour visualiser les données de Managed Service pour Prometheus à l'aide du synchronisateur de sources de données. Ces instructions de configuration de Grafana à l'aide de l'interface utilisateur autonome de Prometheus sont incluses dans cette documentation de référence pour les utilisateurs qui ont déjà configuré Grafana en utilisant cette méthode.

Les API Google Cloud nécessitent toutes une authentification via OAuth2. Toutefois, Grafana n'est pas compatible avec l'authentification OAuth2 pour les comptes de service utilisés avec des sources de données Prometheus. Pour utiliser Grafana avec Managed Service pour Prometheus, vous devez utiliser l'interface utilisateur autonome de Prometheus en tant que proxy d'authentification.

Vous devez pointer Grafana vers le proxy de l'interface utilisateur autonome pour interroger les données à l'échelle mondiale. Si vous n'appliquez pas ces étapes, Grafana n'exécute des requêtes que sur les données du serveur Prometheus local.

Si vous n'avez pas encore déployé le service frontend de l'interface utilisateur Prometheus en tant que proxy, déployez-le maintenant en exécutant la commande suivante :
```
curl https://raw.githubusercontent.com/GoogleCloudPlatform/prometheus-engine/v0.12.0/examples/frontend.yaml |
sed 's/\$PROJECT_ID/PROJECT_ID/' |
kubectl apply -n NAMESPACE_NAME -f -
```
Pour les clusters Kubernetes non GKE tels que les clusters Anthos, consultez également la section Fournir des identifiants explicitement pour accorder au service frontend les autorisations nécessaires pour interroger les métriques.

Pour savoir comment configurer le champ d'application des métriques utilisé par le service frontend afin d'interroger plusieurs projets, consultez la section Modifier le projet interrogé.

Si vous disposez d'un déploiement Grafana préexistant, tel que celui installé par la bibliothèque kube-prometheus ou un déploiement utilisant un chart Helm, vous pouvez continuer à l'utiliser avec Managed Service pour Prometheus. Si tel est le cas, consultez la page Configurer une source de données pour les étapes suivantes. Sinon, vous devez d'abord déployer Grafana.

Déployer Grafana

Si vous n'avez pas de déploiement Grafana en cours d'exécution sur votre cluster, vous pouvez créer un déploiement test éphémère.

Pour créer un déploiement Grafana éphémère, appliquez le fichier manifeste de Managed Service pour Prometheus grafana.yaml à votre cluster et transférez le service grafana vers votre ordinateur local. L'exemple suivant transfère le service au port 3000.
1. Appliquez le fichier manifeste grafana.yaml :
```
kubectl -n NAMESPACE_NAME apply -f  https://raw.githubusercontent.com/GoogleCloudPlatform/prometheus-engine/beb779d32f4dd531a3faad9f2916617b8d9baefd/examples/grafana.yaml
```
2. Transférez le service grafana vers votre ordinateur local. Cet exemple transfère le service vers le port 3000 :
```
kubectl -n NAMESPACE_NAME port-forward svc/grafana 3000
```
  Cette commande ne renvoie pas de résultat et signale les accès à l'URL pendant son exécution.
  
  Vous pouvez accéder à Grafana dans votre navigateur à l'adresse http://localhost:3000 avec le nom d'utilisateur et le mode de passe admin:admin.
Configurer une source de données

Pour interroger Managed Service pour Prometheus dans Grafana en utilisant l'interface utilisateur Prometheus comme proxy d'authentification, vous devez ajouter une source de données à Grafana. Pour ajouter une source de données pour le service géré, procédez comme suit :
1. Accédez à votre déploiement Grafana, par exemple en recherchant l'URL http://localhost:3000 pour accéder à la page d'accueil de Grafana.
2. Dans le menu principal de Grafana, sélectionnez Configuration, puis Data Sources (Sources de données).
3. Sélectionnez Add data source (Ajouter une source de données), puis sélectionnez Prometheus comme base de données de séries temporelles.
4. Dans le champ URL du volet HTTP, saisissez l'URL du service frontend de Managed Service pour Prometheus. Si vous avez configuré l'interface utilisateur Prometheus pour qu'elle s'exécute sur le port 9090, l'URL du service pour ce champ est http://frontend.NAMESPACE_NAME.svc:9090.
  
  Dans le champ Timeout (Délai avant expiration) du volet HTTP, définissez la valeur sur 120.
  
  Si vous avez configuré le proxy d'interface utilisateur avec l'authentification de base, activez le bouton Authentification de base dans le volet Authentification, puis renseignez le nom d'utilisateur et le mot de passe.
  
  Dans le champ Query timeout (Délai avant expiration de la requête), définissez la valeur sur 2m.
  
  Dans le champ Méthode HTTP, sélectionnez GET.
  
  Dans le champ Type Prometheus, sélectionnez Prometheus.
  
  Dans le champ Version Prometheus, sélectionnez 2.40.x ou une version ultérieure.
  
  Si vous disposez de plusieurs sources de données Prometheus, vous pouvez leur attribuer un nom tel que "Managed Prometheus Service". Vous pouvez conserver les valeurs par défaut dans les autres champs.
5. Cliquez sur Save & Test (Enregistrer et tester), puis recherchez le message "The data source is working" (La source de données fonctionne).
Remarque : Vous pouvez également déployer le conteneur frontend en tant que side-car dans le pod Grafana. Cette source de données peut y accéder à l'URL http://localhost:9090.

Utiliser la nouvelle source de données

Vous pouvez maintenant créer des tableaux de bord Grafana en utilisant la nouvelle source de données. Vous pouvez également rediriger les tableaux de bord existants vers la nouvelle source de données. La capture d'écran suivante montre un graphique Grafana qui affiche la métrique up :

Connecter Managed Service pour Prometheus à Thanos

Vous pouvez fédérer Managed Service pour Prometheus à une pile Thanos auto-déployée à l'aide du connecteur Open Source thanos-promql-connector. Google Cloud ne propose pas d'assistance pour cette intégration.

API HTTP Prometheus

Managed Service pour Prometheus est compatible avec l'API HTTP Prometheus en amont à l'URL précédée du préfixe https://monitoring.googleapis.com/v1/projects/PROJECT_ID/location/global/prometheus/api/v1/. Pour en savoir plus sur les points de terminaison compatibles, consultez la section Compatibilité de l'API.

Cette API est accessible par n'importe quel outil pouvant interagir avec un serveur Prometheus standard. Il s'agit d'un point de terminaison d'API uniquement. il ne livre pas d'UI. En tant qu'API Google Cloud, l'API utilise l'authentification OAuth2. Dans le cadre de l'API Cloud Monitoring, la valeur de PROJECT_ID correspond au projet de champ d'application d'un champ d'application des métriques. Vous pouvez donc extraire des données de projet dans le champ d'application des métriques. Pour en savoir plus sur les champs d'application, consultez la section Champs d'application des métriques.

Pour utiliser ce point de terminaison, fournissez une expression PromQL. Par exemple, la requête instantanée suivante récupère toutes les séries temporelles portant le nom de métrique up :
```
curl https://monitoring.googleapis.com/v1/projects/PROJECT_ID/location/global/prometheus/api/v1/query \
  -d "query=up" \
  -H "Authorization: Bearer $(gcloud auth print-access-token)"
```
Si la requête aboutit, elle renvoie un résultat semblable à celui-ci, qui a été formaté pour faciliter la lecture :
```
{
  "status":"success",
  "data":{
    "resultType":"vector",
    "result":[{
      "metric": {
        "__name__":"up",
        "cluster":"gmp-test",
        "instance":"prom-example-84c6f547f5-g4ljn:web",
        "job":"prometheus",
        "location":"us-central1-a",
        "project_id":"a-gcp-project"
      },
      "value": [1634873239.971,"1"]
    }]
  }
}
```
Pour en savoir plus sur l'interrogation des métriques système Google Cloud à l'aide de PromQL, consultez la page PromQL pour les métriques Cloud Monitoring.

Compatibilité avec les API

Les points de terminaison de l'API HTTP Prometheus suivants sont compatibles avec Managed Service pour Prometheus sous l'URL précédée du préfixe https://monitoring.googleapis.com/v1/projects/PROJECT_ID/location/global/prometheus/api/v1/.

Pour obtenir la documentation complète, consultez la documentation de référence de l'API Cloud Monitoring.

Pour plus d'informations sur la compatibilité PromQL, consultez la page Compatibilité de PromQL.
- Les points de terminaison suivants sont entièrement compatibles :
  - /api/v1/query
  - /api/v1/query_range
  - /api/v1/metadata
  - /api/v1/labels
  - /api/v1/query_exemplars
- Le point de terminaison /api/v1/label/<label_name>/values ne fonctionne que si l'étiquette __name__ est fournie en l'utilisant en tant que valeur <label_name> ou comme correspondance exacte dans le sélecteur de séries. Par exemple, les appels suivants sont entièrement compatibles :
  - /api/v1/label/__name__/values
  - /api/v1/label/__name__/values?match[]={__name__=~".*metricname.*"}
  - /api/v1/label/labelname/values?match[]={__name__="metricname"}
  Cette limitation entraîne l'échec des requêtes de variables label_values($label) dans Grafana. Vous pouvez utiliser label_values($metric, $label) à la place. Ce type de requête est recommandé, car il évite de récupérer des valeurs d'étiquettes sur les métriques qui ne sont pas pertinentes pour le tableau de bord donné.
- Le point de terminaison /api/v1/series est compatible avec les requêtes GET, mais pas POST. Lorsque vous utilisez le synchronisateur de sources de données ou le proxy d'interface, cette restriction est gérée automatiquement. Vous pouvez également configurer vos sources de données Prometheus dans Grafana pour n'émettre que des requêtes GET. Le paramètre match[] n'accepte pas la correspondance d'expression régulière sur le libellé __name__.