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. Vous n'avez pas besoin d'écrire de 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_FOUNDavec "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 à celle de la méthode indiquée sur la page de référence de la méthode. Cette erreur peut signifier qu'il existe une faute d'orthographe, telle que "project" au lieu de "projects", ou une erreur de casse, telle que "TimeSeries" au lieu de "timeSeries".401 UNAUTHENTICATEDavec "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 peut signifier qu'il y a une erreur dans l'ID de 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 y a probablement un problème d'autorisation dans l'environnement où vous effectuez l'appel d'API. Accédez à la page du gestionnaire d'API afin de vérifier que l'API Monitoring est activée pour votre projet.
400 INVALID_ARGUMENTavec le message "Le filtre de champ présente 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_ARGUMENTwith "Request was missing fieldinterval.endTime" : ce message s'affiche lorsque l'heure de fin est manquante ou lorsqu'elle est présente, mais qu'elle n'est pas correctement formatée. Si vous utilisez APIs Explorer, ne mettez pas de guillemets la valeur du champ "time" (heure).Voici quelques exemples de spécifications temporelles 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, celui-ci peut ne correspondre à rien. La correspondance du filtre est sensible à la casse. Pour résoudre les problèmes de filtre, commencez par ne spécifier qu'un seul composant de filtre, tel que
metric.type, puis 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 l'absence de points de données lorsque vous utilisez la méthode timeSeries.list:
Les données ont peut-être expiré. Pour en savoir plus, consultez l'article Conservation des données.
Il est possible que les données n'aient pas encore été 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 qu'elle est antérieure à l'heure de fin. Si l'heure de début est manquante ou incorrecte, 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étriquesCUMULATIVEouDELTA, 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 nouvelles 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 d'arrière-plan de longue durée avec un quota basé sur le temps, telles que n appels pour t secondes. Les nouvelles tentatives ne sont pas utiles lorsque le problème est temporaire ou de courte durée, ou lorsque vous avez épuisé un quota basé sur le volume. Pour les conditions temporaires, envisagez de tolérer la défaillance. Pour les problèmes liés aux quotas, envisagez de réduire votre utilisation 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. L'exemple suivant ajoute un intervalle entre les tentatives croissant à un délai minimal de 1 000 ms. Le délai initial est de 2 ms, puis il augmente à 2retry_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 | 20 = 1 | 1001 |
| 1 | 21 = 2 | 1002 |
| 2 | 22 = 4 | 1004 |
| 3 | 23 = 8 | 1008 |
| 4 | 24 = 16 | 1016 |
| ... | ... | ... |
| n | 2n | 1 000 + 2n |
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.