Résoudre les problèmes liés à l'API Monitoring

Ce guide explique certains des problèmes qui peuvent survenir lorsque vous utilisez l'API Monitoring.

L'API Monitoring est l'un des ensembles d'API Cloud. Ces API partagent un ensemble commun de codes d'erreur. Pour obtenir la liste des codes d'erreur définis par les API Cloud et des suggestions générales sur la gestion des erreurs, consultez la page Gérer les erreurs.

Utiliser APIs Explorer pour le débogage

APIs Explorer est un widget intégré aux pages de référence pour les méthodes d'API. Il vous permet d'appeler la méthode en remplissant des champs. Il n'est pas nécessaire d'écrire du code.

Si vous rencontrez des problèmes avec un appel de méthode, utilisez le widget APIs Explorer (Essayer cette API) sur la page de référence de cette méthode pour déboguer votre problème. Pour en savoir plus, consultez la page APIs Explorer.

Erreurs d'API générales

Voici quelques erreurs et messages d'erreur liés à l'API Monitoring que vous pouvez rencontrer lors de vos appels d'API :

• 404 NOT_FOUND avec "The requested URL was not found on this server" (L'URL demandée est introuvable sur ce serveur) : une partie de l'URL est incorrecte. Comparez l'URL à l'URL de la méthode indiquée sur la page de référence de la méthode. Cette erreur peut indiquer une erreur d'orthographe (par exemple, "projet" au lieu de "projets") ou de majuscules (par exemple, "TimeSeries" au lieu de "timeSeries").

• 401 UNAUTHENTICATED avec "User is not authorized to access the project (or metric)" (L'utilisateur n'est pas autorisé à accéder au projet [ou à la métrique]) : ce code d'erreur indique généralement un problème d'autorisation, mais il peut également signifier qu'il existe une erreur dans l'ID du projet ou le nom du type de métrique. Vérifiez l'orthographe et la casse.

  Si vous n'utilisez pas APIs Explorer, essayez de l'utiliser. Lorsque votre appel d'API fonctionne dans APIs Explorer, il existe probablement un problème d'autorisation dans l'environnement dans lequel vous effectuez l'appel d'API. Accédez à la page du gestionnaire d'API pour vérifier que l'API Monitoring est activée pour votre projet.

• 400 INVALID_ARGUMENT avec "Field filter had an invalid value" (Le filtre de champ comportait une valeur non valide) : vérifiez l'orthographe et la mise en forme du filtre de surveillance. Pour en savoir plus, consultez la page Filtres de surveillance.

• 400 INVALID_ARGUMENT avec "Request was missing field interval.endTime" (Champ interval.endTime manquant dans la requête) : ce message s'affiche si l'heure de fin n'est pas spécifiée ou si elle est présente, mais que son format est incorrect. Si vous utilisez APIs Explorer, ne citez pas la valeur du champ de temps.

  Voici quelques exemples de spécifications de temps valides:

  2024-05-11T01:23:45Z
  2024-05-11T01:23:45.678Z
  2024-05-11T01:23:45.678+05:00
  2024-05-11T01:23:45.678-04:30
  

Résultats manquants

Lorsqu'un appel d'API renvoie le code d'état 200 et une réponse vide, tenez compte des points suivants:

• Lorsque l'appel utilise un filtre, il est possible que ce dernier n'ait rien trouvé. La correspondance du filtre est sensible à la casse. Pour résoudre les problèmes de filtre, commencez par spécifier un seul composant de filtre, tel que metric.type, et vérifiez que vous obtenez des résultats. Ajoutez les autres composants de filtre un par un pour créer votre requête.

• Lorsque vous utilisez une métrique personnalisée, vérifiez que le projet qui définit la métrique est spécifié.

Plusieurs raisons peuvent expliquer qu'il manque des points de données lorsque vous utilisez la méthode timeSeries.list:

• Les données peuvent être obsolètes. Pour en savoir plus, consultez l'article Conservation des données.

• Il est possible que les données ne se soient pas encore propagées dans Monitoring. Pour en savoir plus, consultez la section Latence des données de métriques.

• L'intervalle n'est pas valide:

  • Vérifiez que l'heure de fin est correcte.
  • Vérifiez que l'heure de début est correcte et antérieure à l'heure de fin. Lorsque l'heure de début est manquante ou mal mise en forme, l'API définit l'heure de début sur l'heure de fin. Pour les métriques GAUGE, cet intervalle de temps ne correspond qu'aux points dont les heures de début et de fin correspondent exactement à l'heure de fin de l'intervalle. Pour les métriques CUMULATIVE ou DELTA, qui mesurent sur des intervalles de temps, aucun point n'est mis en correspondance. Pour en savoir plus, consultez la page Intervalles de temps.

Réessayer les erreurs d'API

Deux des codes d'erreur des API Cloud indiquent des circonstances dans lesquelles il peut être utile de réessayer la requête :

• 503 UNAVAILABLE: les tentatives sont utiles lorsque le problème est une condition de courte durée ou temporaire.
• 429 RESOURCE_EXHAUSTED: les nouvelles tentatives sont utiles, après un délai, pour les tâches en arrière-plan de longue durée associées à un quota horaire, par exemple n appels par t secondes. Les tentatives ne sont pas utiles lorsque le problème est une condition de courte durée ou temporaire, ou lorsque vous avez épuisé un quota basé sur le volume. Pour les conditions transitoires, envisagez de tolérer la défaillance. En cas de problème lié aux quotas, envisagez de réduire votre utilisation des quotas ou de demander une augmentation de quota.

Lorsque vous écrivez du code susceptible de relancer des requêtes, assurez-vous d'abord que la requête est sécurisée.

La requête peut-elle être réessayée en toute sécurité ?

Si la requête est idempotente, vous pouvez réessayer en toute sécurité. Une action idempotente est une opération où toute modification de l'état ne dépend pas de l'état actuel. Exemple :

• La lecture de x est idempotente. La valeur ne change pas.
• Définir x sur 10 est idempotent. Cela peut modifier l'état, si la valeur n'est pas déjà égale à 10, mais peu importe la valeur actuelle. Peu importe le nombre de fois que vous tentez de définir la valeur.
• Augmenter x n'est pas idempotent. La nouvelle valeur dépend de la valeur actuelle.

Réessayer avec un intervalle exponentiel entre les tentatives

Lorsque vous mettez en œuvre du code pour relancer des requêtes, vous ne souhaitez pas rapidement émettre de nouvelles requêtes indéfiniment. Si un système est surchargé, cette approche contribue au problème.

Optez plutôt pour un intervalle exponentiel tronqué entre les tentatives. Lorsque les requêtes échouent à cause d'une surcharge transitoire plutôt que d'une véritable indisponibilité, la solution réduit la charge. Un intervalle exponentiel tronqué entre les tentatives suit le modèle général suivant :

• Déterminez la durée pendant laquelle vous souhaitez attendre ou le nombre de tentatives que vous êtes prêt à effectuer. Lorsque cette limite est dépassée, considérez le service comme indisponible et gérez cette condition correctement pour votre application. C'est ce qui rend l'intervalle exponentiel entre les tentatives tronqué. Vous arrêtez d'effectuer de nouvelles tentatives à un moment donné.

• Réessayez d'exécuter la requête avec des pauses de plus en plus longues avec un intervalle entre la fréquence des tentatives. Réessayez jusqu'à ce que la requête aboutisse ou que la limite établie soit atteinte.

  L'intervalle est généralement augmenté par une fonction de la puissance du nombre de nouvelles tentatives, ce qui en fait un intervalle exponentiel entre les tentatives.

Il existe plusieurs façons de mettre en œuvre un intervalle exponentiel entre les tentatives. Voici un exemple qui ajoute un délai d'attente croissant à un délai minimal de 1 000 ms. Le délai initial est de 2 ms, puis il augmente à 2^retry_count ms à chaque tentative.

Le tableau suivant indique les intervalles de nouvelles tentatives à l'aide des valeurs initiales :

• Délai minimal = 1 s = 1 000 ms
• Intervalle initial entre les tentatives = 2 ms

Nombre de nouvelles tentatives	Délai supplémentaire (ms)	Réessayer après (ms)
0	2^0 = 1	1001
1	2^1 = 2	1002
2	2^2 = 4	1004
3	2^3 = 8	1008
4	2^4 = 16	1016
…	...	…
n	2^n	1 000 + 2^n

Vous pouvez tronquer le cycle de nouvelle tentative en arrêtant n fois ou lorsque le temps passé est supérieur à une valeur raisonnable pour votre application.

Pour en savoir plus, consultez l'article Wikipédia Intervalle exponentiel entre les tentatives.