Résoudre des problèmes liés au service géré pour Prometheus

Ce document décrit certains problèmes que vous pouvez rencontrer lors de l'utilisation du service géré Google Cloud pour Prometheus et fournit des informations sur le diagnostic et la résolution des problèmes.

Vous avez configuré le service géré pour Prometheus, mais vous ne voyez aucune donnée de métrique dans Grafana ou dans l'interface utilisateur de Prometheus. La cause peut être l'une des suivantes :

Il s'agit d'un problème côté requête, et les données ne peuvent pas être lues. Les problèmes côté requête sont souvent provoqués par des autorisations incorrectes sur le compte de service qui lit les données ou par une mauvaise configuration de Grafana.
Problème côté ingestion, de sorte qu'aucune donnée n'est envoyée. Les problèmes d'ingestion peuvent être dus à des problèmes de configuration des comptes de service, des collecteurs ou de l'évaluation des règles.

Pour déterminer si le problème se trouve du côté de l'ingestion ou de la requête, essayez d'interroger les données à l'aide de l'onglet PromQL de l'explorateur de métriques dans la console Google Cloud. Vous avez la garantie que cette page ne présente aucun problème avec les autorisations de lecture ou les paramètres Grafana.

Pour afficher cette page, procédez comme suit :

Utilisez l'outil de sélection de projets de la console Google Cloud pour sélectionner le projet pour lequel vous ne voyez pas de données.
Dans la console Google Cloud, accédez à la page Explorateur de métriques :
Accéder à l'explorateur de métriques

Si vous utilisez la barre de recherche pour trouver cette page, sélectionnez le résultat dont le sous-titre est Monitoring.
Dans la barre d'outils du volet de création de requêtes, sélectionnez le bouton nommé MQL ou PromQL.
Vérifiez que PromQL est sélectionné dans le bouton d'activation Langage. Le bouton de langage se trouve dans la barre d'outils qui vous permet de mettre en forme votre requête.
Saisissez la requête suivante dans l'éditeur, puis cliquez sur Exécuter la requête :
```
up
```

Si vous interrogez la métrique up et voyez les résultats, le problème se trouve côté requête. Pour en savoir plus sur la résolution de ces problèmes, consultez la section Problèmes côté requête.

Si vous interrogez la métrique up et que vous ne voyez aucun résultat, le problème est côté ingestion. Pour en savoir plus sur la résolution de ces problèmes, consultez la section Problèmes côté ingestion.

Un pare-feu peut également causer des problèmes d'ingestion et de requête. Pour plus d'informations, consultez la section Pare-feu.

La page Gestion des métriques de Cloud Monitoring fournit des informations qui peuvent vous aider à contrôler les sommes que vous consacrez aux métriques facturables, sans affecter l'observabilité. La page Gestion des métriques fournit les informations suivantes :

Les volumes d'ingestion pour la facturation à base d'octets et celle à base d'exemples, englobant les différents domaines de métriques et des métriques individuelles
Les données sur les libellés et la cardinalité des métriques
Nombre de lectures pour chaque métrique.
L'utilisation de métriques dans les règles d'alerte et les tableaux de bord personnalisés
Les taux d'erreurs d'écriture de métriques

Vous pouvez également utiliser la gestion des métriques pour exclure les métriques inutiles, ce qui élimine le coût de leur ingestion.

Procédez comme suit pour afficher la page Gestion des métriques :

Dans la console Google Cloud, accédez à la page Gestion des métriques :
Accédez à la page Gestion des métriques

Si vous utilisez la barre de recherche pour trouver cette page, sélectionnez le résultat dont le sous-titre est Monitoring.
Dans la barre d'outils, sélectionnez votre période. Par défaut, la page Gestion des métriques affiche des informations sur les métriques collectées au cours du jour précédent.

Pour en savoir plus sur la page Gestion des métriques, consultez la section Afficher et gérer l'utilisation des métriques.

Problèmes côté requête

La cause de la plupart des problèmes côté requête est l'une des suivantes :

Autorisations ou identifiants incorrects pour les comptes de service.
Mauvaise configuration de Workload Identity Federation for GKE, si cette fonctionnalité est activée sur votre cluster Pour en savoir plus, consultez la section Configurer un compte de service pour Workload Identity Federation for GKE.

Commencez par effectuer les opérations suivantes :

Vérifiez attentivement votre configuration en suivant les instructions de configuration pour l'interrogation.
Si vous utilisez Workload Identity Federation for GKE, vérifiez que votre compte de service dispose des autorisations appropriées en procédant comme suit :
1. Dans la console Google Cloud, accédez à la page IAM :
  Accéder à IAM
  
  Si vous utilisez la barre de recherche pour trouver cette page, sélectionnez le résultat dont le sous-titre est IAM et administration.
2. Identifiez le nom du compte de service dans la liste des comptes principaux. Vérifiez que le nom du compte de service est correctement orthographié. Cliquez ensuite sur Modifier.
3. Sélectionnez le champ Rôle, puis cliquez sur Actuellement utilisé et recherchez le rôle "Lecteur Monitoring". Si le compte de service ne dispose pas de ce rôle, ajoutez-le maintenant.

Si le problème persiste, envisagez les solutions suivantes :

Secrets mal configurés ou mal orthographiés

Si l'un des éléments suivants s'affiche, il est possible que votre code secret soit manquant ou mal saisi :

L'une de ces erreurs "Interdit" dans Grafana ou dans l'interface utilisateur Prometheus :
- "Avertissement : État de réponse inattendu lors de la récupération de l'heure du serveur : Interdit"
- "Avertissement : Erreur lors de la récupération de la liste des métriques : État de réponse inattendu lors de la récupération des noms de métriques : Interdit"
Un message de ce type s'affiche dans vos journaux :
"Impossible de lire le fichier d'identifiants : ouvrir /gmp/key.json : aucun fichier ni répertoire de ce type"

Si vous utilisez le synchronisateur de sources de données pour authentifier et configurer Grafana, procédez comme suit pour résoudre ces erreurs :

Vérifiez que vous avez choisi le point de terminaison de l'API Grafana, l'UID de la source de données Grafana et le jeton d'API Grafana appropriés. Vous pouvez inspecter les variables dans la tâche cron en exécutant la commande kubectl describe cronjob datasource-syncer.
Vérifiez que vous avez défini l'ID du projet du synchronisateur de sources de données sur le même champ d'application des métriques ou le projet pour lequel votre compte de service dispose d'identifiants.
Vérifiez que votre compte de service Grafana dispose du rôle "Administrateur" et que votre jeton d'API n'a pas expiré.
Vérifiez que votre compte de service dispose du rôle "Lecteur Monitoring" pour l'ID de projet choisi.
Vérifiez qu'il n'y a pas d'erreur dans les journaux du job de synchronisation des sources de données en exécutant kubectl logs job.batch/datasource-syncer-init. Cette commande doit être exécutée immédiatement après l'application du fichier datasource-syncer.yaml.
Si vous utilisez Workload Identity Federation for GKE, vérifiez que vous n'avez pas mal saisi la clé ou les identifiants du compte, et que vous l'avez associée au bon espace de noms.

Si vous utilisez l'ancien proxy d'interface utilisateur, procédez comme suit pour résoudre ces erreurs :

Vérifiez que vous avez défini l'ID de projet de l'interface utilisateur sur le même champ d'application des métriques ou le même projet pour lequel votre compte de service dispose d'identifiants.
Vérifiez l'ID du projet que vous avez spécifié pour les options --query.project-id.
Vérifiez que votre compte de service dispose du rôle "Lecteur Monitoring" pour l'ID de projet choisi.
Vérifiez que vous avez défini l'ID de projet approprié lors du déploiement de l'interface utilisateur et que vous ne l'avez pas défini sur la chaîne littérale PROJECT_ID.
Si vous utilisez Workload Identity, vérifiez que vous n'avez pas mal saisi la clé ou les identifiants du compte, et que vous l'avez associée au bon espace de noms.
Si vous installez votre propre secret, assurez-vous qu'il est présent :
```
kubectl get secret gmp-test-sa -o json | jq '.data | keys'
```

Vérifiez que le secret est correctement installé :

kubectl get deploy frontend -o json | jq .spec.template.spec.volumes

kubectl get deploy frontend -o json | jq .spec.template.spec.containers[].volumeMounts

Assurez-vous que le secret est correctement transmis au conteneur :

kubectl get deploy frontend -o json | jq .spec.template.spec.containers[].args

Méthode HTTP incorrecte pour Grafana

Si l'erreur d'API suivante s'affiche depuis Grafana, Grafana est configuré pour envoyer une requête POST au lieu d'une requête GET :

"{"status":"error","errorType":"bad_data","error":"no match[] parameter provided"}%"

Pour résoudre ce problème, configurez Grafana pour utiliser une requête GET en suivant les instructions de la section Configurer une source de données.

Délais avant expiration des requêtes volumineuses ou de longue durée

Si l'erreur suivante s'affiche dans Grafana, le délai avant expiration par défaut de la requête est trop faible :

"Post "http://frontend.NAMESPACE_NAME.svc:9090/api/v1/query_range": net/http: timeout awaiting response headers"

Managed Service pour Prometheus ne renvoie pas d'expiration de délai tant qu'une requête ne dépasse pas 120 secondes, contre 30 secondes par défaut avec Grafana. Pour résoudre ce problème, portez les délais avant expiration dans Grafana à 120 secondes en suivant les instructions de la section Configurer une source de données.

Erreurs de validation de libellés

Si l'une des erreurs suivantes s'affiche dans Grafana, vous utilisez peut-être un point de terminaison non compatible :

"Validation : les libellés autres que name ne sont pas encore acceptés."
"Modélisation [tâche] : erreur de mise à jour des options : les étiquettes autres que name ne sont pas encore acceptées."

Le service géré pour Prometheus n'accepte le point de terminaison /api/v1/$label/values que pour le libellé __name__. Cette limitation entraîne l'échec des requêtes utilisant la variable label_values($label) dans Grafana.

Utilisez plutôt le format label_values($metric, $label). Cette requête est recommandée, car elle restreint les valeurs de libellés renvoyées par la métrique, ce qui empêche la récupération de valeurs non liées au contenu du tableau de bord. Cette requête appelle un point de terminaison compatible avec Prometheus.

Pour plus d'informations sur les points de terminaison compatibles, consultez la section Compatibilité avec les API.

Quota dépassé

Si l'erreur suivante s'affiche, cela signifie que vous avez dépassé votre quota de lecture pour l'API Cloud Monitoring :

"429: RESOURCE_EXHAUSTED: Quota exceeded for quota metric 'Time series queries ' and limit 'Time series queries per minute' of service 'monitoring.googleapis.com' for consumer 'project_number:...'."

Pour résoudre ce problème, envoyez une demande d'augmentation de votre quota de lecture pour l'API Monitoring. Pour obtenir de l'aide, contactez l'assistance Google Cloud. Pour en savoir plus sur les quotas, consultez la page Utiliser des quotas :

Métriques de plusieurs projets

Si vous souhaitez afficher les métriques de plusieurs projets Google Cloud, vous n'avez pas besoin de configurer plusieurs synchroniseurs de sources de données ni de créer plusieurs sources de données dans Grafana.

À la place, créez un champ d'application des métriques Cloud Monitoring dans un projet Google Cloud (le projet de champ d'application) contenant les projets que vous souhaitez surveiller. Lorsque vous configurez la source de données Grafana avec un projet de champ d'application, vous accédez aux données de tous les projets dans le champ d'application des métriques. Pour plus d'informations, consultez la section Champs d'application des requêtes et des métriques.

Aucun type de ressource surveillée spécifié

Si l'erreur suivante s'affiche, vous devez spécifier un type de ressource surveillée lorsque vous utilisez PromQL pour interroger une métrique système Google Cloud :

"la métrique est configurée pour être utilisée avec plusieurs types de ressources surveillées ; le sélecteur de série doit spécifier un outil de mise en correspondance des libellés sur le nom de la ressource surveillée"

Vous pouvez spécifier un type de ressource surveillée en filtrant à l'aide du libellé monitored_resource. Pour en savoir plus sur l'identification et le choix d'un type de ressource surveillée valide, consultez la page Spécifier un type de ressource surveillée.

Les valeurs brutes des compteurs, des histogrammes et des récapitulatifs ne correspondent pas entre l'interface utilisateur du collecteur et la console Google Cloud

Vous remarquerez peut-être une différence entre les valeurs de l'interface utilisateur Prometheus du collecteur local et celles de la console Google Cloud lorsque vous interrogez la valeur brute des métriques Prometheus cumulatives, y compris les compteurs, les histogrammes et les récapitulatifs. Ce comportement est normal.

Monarch nécessite des horodatages de début, mais Prometheus n'en a pas. Le service géré pour Prometheus génère des horodatages de début en ignorant le premier point ingéré de n'importe quelle série temporelle et en le convertissant en horodatage de début. La valeur des points suivants est diminuée de la valeur du point initial ignoré pour garantir la précision des tarifs. Cela entraîne un déficit persistant dans la valeur brute de ces points.

La différence entre le nombre indiqué dans l'interface utilisateur du collecteur et le nombre indiqué dans la console Google Cloud est égale à la première valeur enregistrée dans l'interface utilisateur du collecteur, ce qui est normal, car le système ignore cette valeur initiale et la soustrait des points suivants.

C'est acceptable car la production ne nécessite pas d'exécuter une requête pour les valeurs brutes des métriques cumulatives. Toutes les requêtes utiles nécessitent une fonction rate() ou similaire, auquel cas la différence sur l'horizon temporel est identique entre les deux UI. Les métriques cumulatives ne cessent d'augmenter. Vous ne pouvez donc pas définir une alerte sur une requête brute, car une série temporelle n'atteint un seuil qu'une seule fois. Toutes les alertes et les graphiques utiles examinent les variations ou le taux de variation de la valeur.

Le collecteur ne conserve environ que 10 minutes de données en local. Des écarts entre les valeurs cumulées brutes peuvent également survenir en raison d'une réinitialisation avant l'horizon des 10 minutes. Pour éliminer cette possibilité, essayez de définir une période d'analyse des requêtes de 10 minutes uniquement lorsque vous comparez l'interface utilisateur du collecteur à la console Google Cloud.

Les écarts peuvent également être causés par plusieurs threads de calcul dans votre application, chacun avec un point de terminaison /metrics. Si votre application lance plusieurs threads, vous devez passer la bibliothèque cliente Prometheus en mode multiprocessus. Pour en savoir plus, consultez la documentation sur l'utilisation du mode multiprocessus dans la bibliothèque cliente Python de Prometheus.

Données de compteur manquantes ou histogrammes défectueux

Le signal le plus courant de ce problème est l'absence de données ou la présence de données manquantes lors de l'interrogation d'une métrique de compteur simple (par exemple, une requête PromQL de metric_name_foo). Vous pouvez le vérifier si des données apparaissent après l'ajout d'une fonction rate à votre requête (par exemple, rate(metric_name_foo[5m])).

Vous remarquerez également que vos échantillons ingérés ont considérablement augmenté sans aucune modification majeure du volume de scrape ou que de nouvelles métriques sont créées avec des suffixes "unknown" ou "unknown:counter" dans Cloud Monitoring.

Vous remarquerez également que les opérations d'histogramme, telles que la fonction quantile(), ne fonctionnent pas comme prévu.

Ces problèmes se produisent lorsqu'une métrique est collectée sans TYPE de métrique Prometheus. Comme Monarch est fortement typé, Managed Service pour Prometheus prend en compte les métriques non typées qui comportent le suffixe "inconnu" et les ingère deux fois, une fois comme jauge et une fois comme compteur. Le moteur de requêtes choisit ensuite d'interroger la métrique de jauge ou de compteur sous-jacente selon les fonctions de requête que vous utilisez.

Bien que cette heuristique fonctionne généralement assez bien, elle peut entraîner des problèmes tels que des résultats étranges lors de l'interrogation d'une métrique brute "unknown:counter". De plus, comme les histogrammes sont des objets spécifiquement typés dans Monarch, l'ingestion des trois métriques d'histogramme requises en tant que métriques de compteur individuelles entraîne le dysfonctionnement des fonctions d'histogramme. Comme les métriques de type "unknown" sont ingérées deux fois, le fait de ne pas définir de type TYPE double vos échantillons ingérés.

Les raisons courantes pour lesquelles TYPE ne peut pas être défini sont les suivantes :

Configuration accidentelle d'un collecteur Managed Service pour Prometheus en tant que serveur de fédération. La fédération n'est pas disponible lorsque vous utilisez le service géré pour Prometheus. Étant donné que la fédération supprime intentionnellement les informations TYPE, la mise en œuvre de la fédération entraîne des métriques de type "inconnu".
Utilisation de l'écriture distante Prometheus à tout moment du pipeline d'ingestion. Ce protocole supprime également intentionnellement les informations TYPE.
Utiliser une règle de modification de libellés qui modifie le nom de la métrique. La métrique renommée est dissociée des informations TYPE associées au nom de la métrique d'origine.
L'exportateur n'émet pas de TYPE pour chaque métrique.
Un problème temporaire où TYPE est supprimé au démarrage du collecteur.

Pour résoudre ce problème, procédez comme suit :

Cessez d'utiliser la fédération avec le service géré pour Prometheus. Si vous souhaitez réduire la cardinalité et les coûts en pratiquant le "roll up" de données avant de les envoyer à Monarch, consultez la page Configurer l'agrégation locale.
Cessez d'utiliser l'écriture distante Prometheus dans votre chemin d'accès à la collection.
Vérifiez que le champ # TYPE existe pour chaque métrique en accédant au point de terminaison /metrics.
Supprimez toutes les règles de modification de libellés qui modifient le nom d'une métrique.
Supprimez toutes les métriques en conflit avec le suffixe "unknown" ou "unknown:counter" en appelant DeleteMetricDescriptor.
Vous pouvez également interroger toujours les compteurs à l'aide d'une fonction rate ou d'une autre fonction de traitement des compteurs.

Données Grafana non conservées après le redémarrage du pod

Si vos données semblent disparaître de Grafana après un redémarrage du pod, mais qu'elles sont visibles dans Cloud Monitoring, utilisez Grafana pour interroger l'instance Prometheus locale au lieu de Managed Service pour Prometheus.

Pour plus d'informations sur la configuration de Grafana en vue de l'utilisation du service géré en tant que source de données, consultez la page Grafana.

Importer des tableaux de bord Grafana

Pour en savoir plus sur l'utilisation de l'outil d'importation de tableau de bord et son dépannage, consultez la page Importer des tableaux de bord Grafana dans Cloud Monitoring.

Pour en savoir plus sur les problèmes de conversion du contenu du tableau de bord, consultez le fichier README de l'outil d'importation.

Problèmes côté ingestion

Les problèmes côté ingestion peuvent être liés à la collecte ou l'évaluation des règles. Commencez par consulter les journaux d'erreurs de la collecte gérée. Vous pouvez exécuter les commandes suivantes :

kubectl logs -f -n gmp-system -lapp.kubernetes.io/part-of=gmp

kubectl logs -f -n gmp-system -lapp.kubernetes.io/name=collector -c prometheus

Sur les clusters GKE Autopilot, vous pouvez exécuter les commandes suivantes :

kubectl logs -f -n gke-gmp-system -lapp.kubernetes.io/part-of=gmp

kubectl logs -f -n gke-gmp-system -lapp.kubernetes.io/name=collector -c prometheus

La fonctionnalité d'état de la cible peut vous aider à déboguer la cible de scrape. Pour en savoir plus, consultez la page Informations sur l'état de la cible.

L'état du point de terminaison est manquant ou trop ancien

Si vous avez activé la fonctionnalité d'état de la cible, mais qu'il manque un champ ou une valeur Status.Endpoint Statuses dans une ou plusieurs de vos ressources PodMonitoring ou ClusterPodMonitoring, vous risquez de rencontrer les problèmes suivants :

Managed Service pour Prometheus ne pouvait pas atteindre un collecteur sur le même nœud que l'un de vos points de terminaison.
Une ou plusieurs de vos configurations PodMonitoring ou ClusterPodMonitoring n'a abouti à aucune cible valide.

Des problèmes semblables peuvent également entraîner une valeur inférieure de quelques minutes dans le champ Status.Endpoint Statuses.Last Update Time, plus votre intervalle de scraping.

Pour résoudre ce problème, commencez par vérifier que les pods Kubernetes associés à votre point de terminaison de scraping sont en cours d'exécution. Si vos pods Kubernetes sont en cours d'exécution, les sélecteurs de libellés correspondent et vous pouvez accéder manuellement aux points de terminaison de scraping (généralement en accédant au point de terminaison /metrics), puis vérifier si les collecteurs de Managed Service pour Prometheus sont en cours d'exécution.

La fraction des collecteurs est inférieure à 1

Si vous avez activé la fonctionnalité d'état de la cible, vous obtenez des informations sur l'état de vos ressources. La valeur Status.Endpoint Statuses.Collectors Fraction de vos ressources PodMonitoring ou ClusterPodMonitoring représente la fraction des collecteurs, exprimée entre 0 et 1, qui sont accessibles. Par exemple, une valeur 0.5 indique que 50 % de vos collecteurs sont accessibles, tandis que la valeur 1 indique que 100 % de vos collecteurs sont accessibles.

Si le champ Collectors Fraction a une valeur autre que 1, un ou plusieurs collecteurs sont inaccessibles, et les métriques de l'un de ces nœuds ne sont peut-être pas scrapées. Assurez-vous que tous les collecteurs sont en cours d'exécution et accessibles sur le réseau du cluster. Vous pouvez afficher l'état des pods de collecteur à l'aide de la commande suivante :

kubectl -n gmp-system get pods --selector="app.kubernetes.io/name=collector"

Sur les clusters GKE Autopilot, cette commande est légèrement différente :

kubectl -n gke-gmp-system get pods --selector="app.kubernetes.io/name=collector"

Vous pouvez examiner des pods de collecteurs individuels (par exemple, un pod de collecteur nommé collector-12345) à l'aide de la commande suivante :

kubectl -n gmp-system describe pods/collector-12345

Sur les clusters GKE Autopilot, exécutez la commande suivante :

kubectl -n gke-gmp-system describe pods/collector-12345

Si les collecteurs ne sont pas opérationnels, consultez la section Dépannage de charge de travail GKE.

Si les collecteurs sont opérationnels, consultez les journaux de l'opérateur. Pour vérifier les journaux de l'opérateur, commencez par exécuter la commande suivante afin de trouver le nom du pod d'opérateur :

kubectl -n gmp-system get pods --selector="app.kubernetes.io/name=gmp-collector"

Sur les clusters GKE Autopilot, exécutez la commande suivante :

kubectl -n gke-gmp-system get pods --selector="app.kubernetes.io/name=gmp-collector"

Vérifiez ensuite les journaux de l'opérateur (par exemple, un pod d'opérateur nommé gmp-operator-12345) à l'aide de la commande suivante :

kubectl -n gmp-system logs pods/gmp-operator-12345

Sur les clusters GKE Autopilot, exécutez la commande suivante :

kubectl -n gke-gmp-system logs pods/gmp-operator-12345

Cibles non opérationnelles

Si vous avez activé la fonctionnalité d'état de la cible, mais que le champ Status.Endpoint Statuses.Unhealthy Targets d'une ou ou plusieurs de vos ressources PodMonitoring ou ClusterPodMonitoring comporte une valeur autre que 0, le collecteur ne peut pas récupérer une ou plusieurs de vos cibles.

Affichez le champ Sample Groups, qui regroupe les cibles par message d'erreur, puis recherchez le champ Last Error. Le champ Last Error provient de Prometheus et vous indique pourquoi la cible n'a pas pu être scrapée. Pour résoudre ce problème, en utilisant les exemples de cibles comme référence, vérifiez si vos points de terminaison de scraping sont en cours d'exécution.

Point de terminaison de scraping non autorisé

Si l'une des erreurs suivantes s'affiche et que votre cible de scraping nécessite une autorisation, cela signifie que votre collecteur n'est pas configuré pour utiliser le type d'autorisation approprié ou qu'ilutilise la charge utile d'autorisation incorrecte :

server returned HTTP status 401 Unauthorized
x509: certificate signed by unknown authority

Pour résoudre ce problème, consultez la section Configurer un point de terminaison de scraping autorisé.

Quota dépassé

Si l'erreur suivante s'affiche, cela signifie que vous avez dépassé votre quota d'ingestion pour l'API Cloud Monitoring :

"429: Quota exceeded for quota metric 'Time series ingestion requests' and limit 'Time series ingestion requests per minute' of service 'monitoring.googleapis.com' for consumer 'project_number:PROJECT_NUMBER'., rateLimitExceeded"

Cette erreur se produit le plus souvent lors de la première activation du service géré. Le quota par défaut sera épuisé pour 100 000 échantillons par seconde ingérés.

Pour résoudre ce problème, envoyez une demande d'augmentation de votre quota d'ingestion pour l'API Monitoring. Pour obtenir de l'aide, contactez l'assistance Google Cloud. Pour en savoir plus sur les quotas, consultez la page Utiliser des quotas :

Autorisation manquante sur le compte de service par défaut du nœud

Si l'une des erreurs suivantes s'affiche, il est possible que des autorisations ne soient pas accordées au compte de service par défaut du nœud :

"execute query: Erreur lors de l'interrogation de Prometheus: client_error: client error: 403"
"Readiness probe failed: échec de la vérification HTTP avec le code d'état: 503"
"Erreur lors de l'interrogation de l'instance Prometheus"

La collecte gérée et l'évaluateur de règles gérées dans le service géré pour Prometheus utilisent tous deux le compte de service par défaut sur le nœud. Ce compte est créé avec toutes les autorisations nécessaires, mais les clients peuvent parfois supprimer manuellement les autorisations Monitoring. Cette suppression entraîne l'échec de la collecte et de l'évaluation des règles.

Pour vérifier les autorisations du compte de service, effectuez l'une des opérations suivantes :

Identifiez le nom du nœud Compute Engine sous-jacent, puis exécutez la commande suivante :
```
gcloud compute instances describe NODE_NAME --format="json" | jq .serviceAccounts
```
Recherchez la chaîne https://www.googleapis.com/auth/monitoring. Si nécessaire, ajoutez Monitoring comme décrit dans la section Compte de service mal configuré.
Accédez à la VM sous-jacente du cluster et vérifiez la configuration du compte de service du nœud :
1. Dans la console Cloud Console, accédez à la page des clusters Kubernetes.
  Accéder à la page Clusters Kubernetes
  
  Si vous utilisez la barre de recherche pour trouver cette page, sélectionnez le résultat dont le sous-titre est Kubernetes Engine.
2. Sélectionnez Nœuds, puis cliquez sur le nom du nœud dans la table Nœuds.
3. Cliquez sur Détails.
4. Cliquez sur le lien Instance de VM.
5. Recherchez le volet API et gestion des identités, puis cliquez sur Afficher les détails.
6. Recherchez l'API Stackdriver Monitoring avec un accès complet.

Il est également possible que le synchroniseur de sources de données ou l'interface utilisateur de Prometheus aient été configurés pour examiner le mauvais projet. Pour savoir comment vérifier que vous interrogez le champ d'application des métriques prévues, consultez la section Modifier le projet interrogé.

Compte de service mal configuré

Si l'un des messages d'erreur suivants s'affiche, cela signifie que le compte de service utilisé par le collecteur ne dispose pas des autorisations appropriées :

"code = PermissionDenied desc = Permission monitoring.timeSeries.create denied (ou la ressource peut ne pas exister)"
"google : Impossible de trouver les identifiants par défaut. Consultez la page https://developers.google.com/accounts/docs/application-default-credentials.

Pour vérifier que votre compte de service dispose des autorisations appropriées, procédez comme suit :

Dans la console Google Cloud, accédez à la page IAM :
Accéder à IAM

Si vous utilisez la barre de recherche pour trouver cette page, sélectionnez le résultat dont le sous-titre est IAM et administration.
Identifiez le nom du compte de service dans la liste des comptes principaux. Vérifiez que le nom du compte de service est correctement orthographié. Cliquez ensuite sur Modifier.
Sélectionnez le champ Rôle, puis cliquez sur Actuellement utilisé et recherchez le rôle "Rédacteur de métriques Monitoring" ou "Éditeur Monitoring". Si le compte de service ne possède pas l'un de ces rôles, attribuez-lui le rôle Rédacteur de métriques Monitoring (roles/monitoring.metricWriter).

Si vous utilisez une solution Kubernetes non GKE, vous devez transmettre explicitement les identifiants au collecteur et à l'évaluateur de règle. Vous devez répéter les identifiants dans les sections rules et collection. Pour en savoir plus, consultez la section Fournir les identifiants explicitement (pour la collecte) ou Fournir les identifiants explicitement (pour les règles).

Les comptes de service sont souvent limités à un seul projet Google Cloud. L'utilisation d'un compte de service pour écrire des données de métriques pour plusieurs projets, par exemple lorsqu'un évaluateur de règles gérées interroge un champ d'application des métriques multiprojets, peut provoquer cette erreur d'autorisation. Si vous utilisez le compte de service par défaut, envisagez de configurer un compte de service dédié afin de pouvoir ajouter l'autorisation monitoring.timeSeries.create en toute sécurité pour plusieurs projets. Si vous ne pouvez pas accorder cette autorisation, vous pouvez utiliser le réétiquetage de métriques pour réécrire le libellé project_id sous un autre nom. L'ID du projet est donc défini par défaut sur le projet Google Cloud dans lequel votre serveur Prometheus ou votre évaluateur de règle est en cours d'exécution.

Configuration de scraping non valide

Si l'erreur suivante s'affiche, votre PodMonitoring ou ClusterPodMonitoring n'est pas correctement formé :

"Erreur interne : échec de l'appel du webhook "validate.podmonitorings.gmp-operator.gmp-system.monitoring.googleapis.com": Post "https://gmp-operator.gmp-system.svc:443/validate/monitoring.googleapis.com/v1/podmonitorings?timeout=10s": EOF""

Pour résoudre ce problème, assurez-vous que votre ressource personnalisée est correctement formée selon la spécification.

Échec de l'analyse du webhook d'admission ou configuration client HTTP non valide

Sur les versions de Managed Service pour Prometheus antérieures à la version 0.12, vous pouvez rencontrer une erreur semblable à la suivante, qui est liée à l'injection de secrets dans l'espace de noms non par défaut :

"Le webhook d'admission "validate.podmonitorings.gmp-operator.gmp-system.monitoring.googleapis.com" a refusé la requête : définition non valide pour le point de terminaison avec l'index 0 : échec de l'analyse ou configuration client HTTP Prometheus non valide : vous devez utiliser l'espace de noms "my-custom-namespace", obtenu : "default""

Pour résoudre ce problème, mettez à niveau votre version vers la version 0.12 ou une version ultérieure.

Problèmes liés aux intervalles et aux délais d'inactivité de scraping

Lorsque vous utilisez le service géré pour Prometheus, le délai avant expiration de scraping ne peut pas être supérieur à l'intervalle de scraping. Pour vérifier ce problème dans vos journaux, exécutez la commande suivante :

kubectl -n gmp-system logs ds/collector prometheus

Sur les clusters GKE Autopilot, exécutez la commande suivante :

kubectl -n gke-gmp-system logs ds/collector prometheus

Recherchez ce message :

"scrape timeout greater than scrape interval for scrape config with job name "PodMonitoring/gmp-system/example-app/go-metrics""

Pour résoudre ce problème, définissez une valeur de l'intervalle de scraping égale ou supérieure à la valeur du délai avant expiration de scraping.

TYPE manquant dans la métrique

Si l'erreur suivante s'affiche, la métrique ne contient pas d'informations de type :

"aucune métadonnée trouvée pour le nom de métrique "{metric_name}"

Pour vérifier que les informations de type manquantes sont le problème, vérifiez le résultat /metrics de l'application d'exportation. S'il n'y a pas de ligne semblable à la suivante, les informations de type sont manquantes :

# TYPE {metric_name} <type>

Certaines bibliothèques, telles que celles de VictoriaMetrics antérieures à la version 1.28.0, suppriment intentionnellement les informations de type. Ces bibliothèques ne sont pas compatibles avec le service géré pour Prometheus.

Conflits de séries temporelles

Si l'une des erreurs suivantes s'affiche, plusieurs collecteurs peuvent tenter d'écrire dans la même série temporelle :

"Une ou plusieurs séries temporelles n'ont pas pu être écrites : un ou plusieurs points ont été écrits plus souvent que la période d'échantillonnage maximale configurée pour la métrique."
"Une ou plusieurs séries temporelles n'ont pas pu être écrites : les points doivent être écrits dans l'ordre. Un ou plusieurs points spécifiés ont une heure de fin plus ancienne que le point le plus récent.

Les causes et solutions les plus courantes sont les suivantes :

Utilisez des paires haute disponibilité. Le service géré pour Prometheus ne prend pas en charge la collecte traditionnelle à haute disponibilité. L'utilisation de cette configuration peut créer plusieurs collecteurs qui tentent d'écrire des données dans la même série temporelle, ce qui génère cette erreur.

Pour résoudre le problème, désactivez les collecteurs en double en réduisant le nombre d'instances dupliquées à 1, ou utilisez la méthode de haute disponibilité compatible.
Utiliser des règles de modification de libellés, en particulier celles qui opèrent sur des tâches ou des instances. Le service géré pour Prometheus identifie partiellement une série temporelle unique en combinant les libellés {project_id, location, cluster, namespace, job, instance}. L'utilisation d'une règle de changement de libellés pour supprimer ces libellés, en particulier les libellés job et instance, peut provoquer des conflits. Il n'est pas recommandé de réécrire ces libellés.

Pour résoudre le problème, supprimez la règle qui en est à l'origine. Cette opération peut souvent être effectuée par la règle metricRelabeling qui utilise l'action labeldrop. Vous pouvez identifier la règle problématique en ajoutant des commentaires à toutes les règles de réécriture de libellés, puis en les rétablissant une par une, jusqu'à ce que l'erreur se reproduise.

Une cause moins courante des conflits de séries temporelles consiste à utiliser un intervalle de scraping inférieur à 5 secondes. L'intervalle de scraping minimal accepté par le service géré pour Prometheus est de 5 secondes.

Dépassement de la limite du nombre d'étiquettes

Si l'erreur suivante s'affiche, il est possible que trop d'étiquettes soient définies pour l'une de vos métriques :

"Une ou plusieurs séries temporelles n'ont pas pu être écrites : les nouvelles étiquettes entraîneraient le dépassement du nombre d'étiquettes PER_PROJECT_LIMIT pour la métrique prometheus.googleapis.com/METRIC_NAME.

Cette erreur se produit généralement lorsque vous modifiez rapidement la définition de la métrique de sorte qu'un nom de métrique contienne plusieurs ensembles indépendants de clés d'étiquettes sur toute la durée de vie de la métrique. Cloud Monitoring impose une limite sur le nombre d'étiquettes pour chaque métrique. Pour en savoir plus, consultez les limites définies pour les métriques définies par l'utilisateur.

Vous pouvez résoudre ce problème en trois étapes :

Identifiez la raison pour laquelle une métrique donnée a trop d'étiquettes ou des étiquettes qui changent fréquemment.
- Vous pouvez utiliser le widget APIs Explorer sur la page metricDescriptors.list pour appeler la méthode. Pour en savoir plus, consultez la page APIs Explorer. Pour obtenir des exemples, consultez Répertorier les types de métriques et de ressources.
Corrigez la source du problème. Cela peut nécessiter d'ajuster les règles de modification des étiquettes de PodMonitoring, de modifier l'exportateur ou de corriger votre instrumentation.
Supprimez le descripteur de cette métrique (ce qui entraînera une perte de données) afin de pouvoir le recréer avec un ensemble d'étiquettes plus petit et plus stable. Pour ce faire, vous pouvez utiliser la méthode metricDescriptors.delete.

Les causes les plus courantes du problème sont les suivantes :

Collecte de métriques à partir d'exportateurs ou d'applications qui associent des étiquettes dynamiques à des métriques. Par exemple, l'agent cAdvisor déployé automatiquement avec des étiquettes de conteneur et des variables d'environnement supplémentaires ou l'agent DataDog, qui injecte des annotations dynamiques.

Pour résoudre ce problème, vous pouvez utiliser une section metricRelabeling sur le PodMonitoring pour conserver ou supprimer des étiquettes. Certains exportateurs et applications permettent également d'effectuer une configuration qui modifie les métriques exportées. Par exemple, cAdvisor dispose d'un certain nombre de paramètres d'exécution avancés qui peuvent ajouter des étiquettes de manière dynamique. Lorsque vous utilisez la collecte gérée, nous vous recommandons d'utiliser la collecte kubelet automatique intégrée.
L'utilisation de règles de modification des étiquettes, en particulier celles qui associent des noms d'étiquettes de manière dynamique, peut entraîner un nombre inattendu d'étiquettes.

Pour résoudre le problème, supprimez l'entrée de règle qui en est à l'origine.

Limitation du débit pour la création et la mise à jour des métriques et des étiquettes

Si l'erreur suivante s'affiche, cela signifie que vous avez atteint la limite de débit par minute pour la création de métriques et l'ajout de libellés de métriques aux métriques existantes :

"La requête est limitée. Vous avez atteint la limite par projet pour les modifications de définition de métrique ou d'étiquette par minute."

Cette limite de débit n'est généralement atteinte que lors de la première intégration à Managed Service pour Prometheus, par exemple lorsque vous migrez un déploiement Prometheus existant qui a fait ses preuves pour utiliser une collection auto-déployée. Il ne s'agit pas d'une limite de débit pour l'ingestion de points de données. Cette limite de débit s'applique uniquement à la création de métriques qui n'existaient pas auparavant ou à l'ajout de nouveaux libellés aux métriques existantes.

Ce quota est fixe, mais les problèmes éventuels doivent être automatiquement résolus à mesure que de nouvelles métriques et de nouveaux libellés de métriques sont créés dans la limite définie par minute.

Limites concernant le nombre de descripteurs de métrique

Si l'erreur suivante s'affiche, cela signifie que vous avez atteint la limite de quota pour le nombre de descripteurs de métriques dans un seul projet Google Cloud :

"Votre quota de descripteur de métrique est épuisé."

Par défaut, cette limite est définie sur 25 000. Bien que ce quota puisse être augmenté par requête si vos métriques sont correctement formées, il est beaucoup plus probable que vous ayez atteint cette limite car vous ingérez des noms de métriques incorrects dans le système.

Prometheus possède un modèle de données de dimension dans lequel les informations telles que le nom de cluster ou d'espace de noms doivent être encodées en tant que valeur de libellé. Lorsque les informations dimensionnelles sont intégrées dans le nom de la métrique lui-même, le nombre de descripteurs de métriques augmente indéfiniment. De plus, comme les libellés ne sont pas correctement utilisés dans ce scénario, il devient beaucoup plus difficile d'interroger et d'agréger des données sur des clusters, des espaces de noms ou des services.

Ni Cloud Monitoring, ni Managed Service pour Prometheus n'acceptent les métriques non dimensionnelles, telles que celles formatées pour StatsD ou Graphite. Bien que la plupart des exportateurs Prometheus soient configurés correctement par défaut, certains exportateurs, tels que l'exportateur StatsD, Vault ou le proxy Envoy fourni avec Istio, doivent être explicitement configurés pour utiliser des libellés au lieu d'intégrer les informations dans le nom de la métrique. Voici quelques exemples de noms de métriques mal formés :

request_path_____path_to_a_resource____istio_request_duration_milliseconds
envoy_cluster_grpc_method_name_failure
envoy_cluster_clustername_upstream_cx_connect_ms_bucket
vault_rollback_attempt_path_name_1700683024
service__________________________________________latency_bucket

Pour confirmer ce problème, procédez comme suit :

Dans la console Google Cloud, sélectionnez le projet Google Cloud associé à l'erreur.
Dans la console Google Cloud, accédez à la page Gestion des métriques :
Accédez à la page Gestion des métriques

Si vous utilisez la barre de recherche pour trouver cette page, sélectionnez le résultat dont le sous-titre est Monitoring.
Vérifiez que la somme des métriques actives et inactives est supérieure à 25 000. Dans la plupart des cas, vous devriez voir un grand nombre de métriques inactives.
Triez par Volume facturable d'échantillons dans l'ordre croissant, parcourez la liste et recherchez des schémas.

Vous pouvez également confirmer ce problème à l'aide de l'explorateur de métriques :

Dans la console Google Cloud, sélectionnez le projet Google Cloud associé à l'erreur.
Dans la console Google Cloud, accédez à la page Explorateur de métriques :
Accéder à l'explorateur de métriques

Si vous utilisez la barre de recherche pour trouver cette page, sélectionnez le résultat dont le sous-titre est Monitoring.
Dans le générateur de requêtes, cliquez sur une métrique, puis décochez la case "Actif".
Saisissez "prometheus" dans la barre de recherche.
Recherchez des tendances dans les noms des métriques.

Une fois que vous avez identifié les modèles indiquant des métriques incorrectes, vous pouvez atténuer le problème en corrigeant l'exportateur au niveau de la source, puis en supprimant les descripteurs de métrique mis en cause.

Pour éviter que ce problème ne se reproduise, vous devez d'abord configurer l'exportateur concerné pour qu'il n'émette plus de métriques incorrectes. Nous vous recommandons de consulter la documentation de votre exportateur pour obtenir de l'aide. Vous pouvez vérifier que vous avez résolu le problème en accédant manuellement au point de terminaison /metrics et en inspectant les noms de métriques exportés.

Vous pouvez ensuite libérer votre quota en supprimant les métriques incorrectes à l'aide de la méthode projects.metricDescriptors.delete. Pour parcourir plus facilement la liste des métriques incorrectes, nous fournissons un script Golang. Ce script accepte une expression régulière permettant d'identifier les métriques incorrectes et supprime les descripteurs de métrique correspondant au modèle. La suppression de métriques étant irréversible, nous vous recommandons vivement d'exécuter le script au préalable à l'aide du mode de simulation.

Aucune erreur et aucune métrique

Si vous utilisez une collection gérée et qu'aucune erreur ne s'affiche, mais que les données n'apparaissent pas dans Cloud Monitoring, la cause la plus probable est que vos exportateurs de métriques ou vos configurations de scrape ne sont pas correctement configurés. Le service géré pour Prometheus n'envoie aucune donnée de série temporelle, sauf si vous appliquez d'abord une configuration de scrape valide.

Pour identifier la cause du problème, essayez de déployer l'exemple d'application et l'exemple de ressource PodMonitoring. Si la métrique up s'affiche maintenant (ce qui peut prendre quelques minutes), le problème se situe au niveau de votre configuration de scrape ou de votre exportateur.

Plusieurs causes sont possibles. Nous vous recommandons de vérifier les éléments suivants :

PodMonitoring fait référence à un port valide.
Les ports de la spécification de déploiement de votre exportateur sont correctement nommés.
Vos sélecteurs (le plus souvent app) correspondent à vos ressources de déploiement et de PodMonitoring.
Vous pouvez consulter les données au niveau du point de terminaison et du port prévus, en y accédant manuellement.
Vous avez installé votre ressource PodMonitoring dans le même espace de noms que l'application que vous souhaitez scraper. N'installez aucune application ou ressource personnalisée dans l'espace de noms gmp-system ou gke-gmp-system.
Les noms de métriques et de libellés correspondent à l'expression régulière de validation de Prometheus. Le service géré pour Prometheus n'accepte pas les noms de libellés commençant par le caractère _.
L'ensemble de filtres que vous utilisez n'entraîne pas le filtrage de toutes les données. Veillez à ne pas créer de filtres conflictuels lorsque vous utilisez un filtre collection dans la ressource OperatorConfig.
En cas d'exécution en dehors de Google Cloud, project ou project-id est défini sur un projet Google Cloud valide et location est défini sur une région Google Cloud valide. Vous ne pouvez pas utiliser global comme valeur pour location.
Votre métrique est l'un des quatre types de métriques Prometheus. Certaines bibliothèques telles que Kube State Metrics exposent des types de métriques OpenMetrics, tels que Info, Stateset et GaugeHistogram, mais ces types de métriques ne sont pas compatibles avec le service géré pour Prometheus et sont ignorés sans notification.

Certaines métriques sont manquantes pour les cibles de courte durée

Google Cloud Managed Service pour Prometheus est déployé et il n'y a aucune erreur de configuration. Cependant, certaines métriques sont manquantes.

Déterminez le déploiement qui génère les métriques partiellement manquantes. Si le déploiement est une tâche cron de Google Kubernetes Engine, déterminez la durée générale de la tâche:

Recherchez le fichier yaml de déploiement du job Cron et recherchez son état, qui se trouve à la fin du fichier. Dans cet exemple, l'état indique que le job a été exécutée pendant une minute :
```
  status:
    lastScheduleTime: "2024-04-03T16:20:00Z"
    lastSuccessfulTime: "2024-04-03T16:21:07Z"
```
Si la durée d'exécution est inférieure à cinq minutes, le job ne s'exécute pas suffisamment longtemps pour que les données de métrique soient systématiquement scrapées.

Pour résoudre ce problème, procédez comme suit :
- Configurez le job pour vous assurer qu'il ne se ferme pas avant qu'au moins cinq minutes se soient écoulées depuis le démarrage du job.
- Configurez le job pour détecter si les métriques ont été scrapées avant de quitter. Cette fonctionnalité nécessite une compatibilité avec les bibliothèques.
- Envisagez de créer une métrique à valeur de distribution basée sur les journaux au lieu de collecter des données de métrique. Cette approche est suggérée lorsque les données sont publiées à un faible taux. Pour en savoir plus, consultez la page Métriques basées sur les journaux.
Si la durée d'exécution est supérieure à cinq minutes ou si elle est incohérente, consultez la section Cibles non opérationnelles de ce document.

Problèmes liés à la collecte par les exportateurs

Si vos métriques d'un exportateur ne sont pas ingérées, vérifiez les points suivants :

Vérifiez que l'exportateur fonctionne et exporte des métriques à l'aide de la commande kubectl port-forward.

Par exemple, pour vérifier que les pods portant le sélecteur app.kubernetes.io/name=redis dans l'espace de noms test émettent des métriques au point de terminaison /metrics sur le port 9121, vous pouvez transférer les ports comme suit :
```
kubectl port-forward "$(kubectl get pods -l app.kubernetes.io/name=redis -n test -o jsonpath='{.items[0].metadata.name}')" 9121
```
Accédez au point de terminaison localhost:9121/metrics à l'aide du navigateur ou de curl dans une autre session de terminal pour vérifier que les métriques sont exposées par l'exportateur pour la récupération.
Vérifiez si vous pouvez interroger les métriques dans la console Google Cloud, mais pas dans Grafana. Si tel est le cas, le problème concerne Grafana, et non la collecte de vos métriques.
Vérifiez que le collecteur géré est capable de scraper l'exportateur en inspectant l'interface Web de Prometheus qu'il expose.
1. Identifiez le collecteur géré exécuté sur le même nœud que celui sur lequel votre exportateur s'exécute. Par exemple, si votre exportateur s'exécute sur des pods dans l'espace de noms test et que les pods sont libellés app.kubernetes.io/name=redis, la commande suivante identifie le collecteur géré s'exécutant sur le même nœud :
```
kubectl get pods -l app=managed-prometheus-collector --field-selector="spec.nodeName=$(kubectl get pods -l app.kubernetes.io/name=redis -n test -o jsonpath='{.items[0].spec.nodeName}')" -n gmp-system -o jsonpath='{.items[0].metadata.name}'
```
2. Configurez un transfert de port à partir du port 19090 du collecteur géré :
```
kubectl port-forward POD_NAME -n gmp-system 19090
```
3. Accédez à l'URL localhost:19090/targets pour accéder à l'interface Web. Si l'exportateur est répertorié comme l'une des cibles, le collecteur géré collecte le scrape de l'exportateur.

Erreurs de mémoire insuffisante (OOM) du collecteur

Si vous utilisez la collecte gérée et que vous rencontrez des erreurs de mémoire insuffisante (OOM) sur vos collecteurs, envisagez d'activer l'autoscaling vertical des pods.

L'opérateur génère des erreurs de mémoire insuffisante (OOM)

Si vous utilisez la collecte gérée et que vous rencontrez des erreurs de mémoire insuffisante (OOM) sur votre opérateur, envisagez de désactiver la fonctionnalité d'état de la cible. La fonctionnalité d'état de la cible peut entraîner des problèmes de performances de l'opérateur dans les clusters plus importants.

Pare-feu

Un pare-feu peut entraîner des problèmes d'ingestion et de requête. Votre pare-feu doit être configuré pour autoriser les requêtes POST et GET au service de l'API Monitoring, monitoring.googleapis.com, afin d'autoriser l'ingestion et les requêtes.

Erreur concernant les modifications simultanées

Le message d'erreur "Trop de modifications simultanées de la configuration du projet" est généralement temporaire, et disparaît après quelques minutes. Cela est généralement dû à la suppression d'une règle de réécriture de libellé qui affecte de nombreuses métriques différentes. La suppression entraîne la création d'une file d'attente de mises à jour des descripteurs de métriques dans votre projet. L'erreur disparaît lorsque la file d'attente est traitée.

Pour en savoir plus, consultez la section Limites pour la création et la mise à jour des métriques et des étiquettes.

Types de valeurs incompatibles

Si l'erreur suivante s'affiche lors de l'ingestion ou de la requête, cela signifie qu'il existe une incompatibilité de type de valeur dans vos métriques :

"Le type de valeur de la métrique prometheus.googleapis.com/metric_name/gauge doit être INT64, mais est DOUBLE"
"Le type de valeur de la métrique prometheus.googleapis.com/metric_name/gauge doit être DOUBLE, mais il est INT64"
"Une ou plusieurs séries temporelles n'ont pas pu être écrites : le type de valeur de la métrique prometheus.googleapis.com/target_info/gauge est en conflit avec le type de valeur existant (INT64)"

Cette erreur peut se produire lors de l'ingestion, car Monarch n'accepte pas l'écriture de données de type DOUBLE dans des métriques de type INT64, ni l'écriture de données de type INT64 dans des métriques de type DOUBLE. Cette erreur peut également s'afficher lors d'une requête utilisant un champ d'application de métriques multiprojets, car Monarch ne peut pas unir les métriques de type DOUBLE d'un projet avec des métriques de type INT64 d'un autre projet.

Cette erreur ne se produit que lorsque des collecteurs OpenTelemetry génèrent des données de rapport. Elle est plus susceptible de se produire si vous utilisez à la fois OpenTelemetry (à l'aide de l'exportateur googlemanagedprometheus) et Prometheus pour générer des données de rapport pour la même métrique, comme cela se produit généralement pour la métrique target_info.

La cause est probablement l'une des suivantes :

Vous collectez des métriques OTLP, et la bibliothèque de métriques OTLP a modifié son type de valeur de DOUBLE à INT64, comme cela s'est produit avec les métriques Java d'OpenTelemetry. La nouvelle version de la bibliothèque de métriques est désormais incompatible avec le type de valeur de métrique créé par l'ancienne version de la bibliothèque de métriques.
Vous collectez la métrique target_info à l'aide de Prometheus et d'OpenTelemetry. Prometheus collecte cette métrique avec le type DOUBLE, tandis qu'OpenTelemetry la collecte avec le type INT64. Vos collecteurs écrivent maintenant deux types de valeurs dans la même métrique du même projet, et seul le collecteur qui a créé le descripteur de la métrique réussit.
Vous collectez target_info à l'aide d'OpenTelemetry avec le type INT64 dans un projet et target_info à l'aide de Prometheus avec le type DOUBLE dans un autre projet. L'ajout des deux métriques au même champ d'application des métriques, puis l'interrogation de cette métrique via le champ d'application des métriques entraîne une union non valide entre des types de valeurs de métriques incompatibles.

Pour résoudre ce problème, forcez tous les types de valeurs de métrique vers le type DOUBLE en procédant comme suit :

Reconfigurez vos collecteurs OpenTelemetry pour forcer toutes les métriques vers le type DOUBLE en activant l'option exporter.googlemanagedprometheus.intToDouble de la fonctionnalité.
Supprimez tous les descripteurs de métrique INT64 et laissez-les être recréés avec le type DOUBLE. Vous pouvez utiliser le script delete_metric_descriptors.go pour automatiser cette opération.

Suivez ces étapes pour supprimer toutes les données stockées en tant que métrique INT64. Il n'existe pas d'alternative à la suppression des métriques INT64 qui résolvent complètement ce problème.