Dépanner 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. Elle vous permet d'appeler la méthode en remplissant des champs ; vous n'avez pas besoin pour é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 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 avec URL de la méthode indiquée sur la page de référence de la méthode. Cette erreur peut signifier qu’il y a une faute d’orthographe, tel que "projet" au lieu de "projets", ou une erreur de majuscules/minuscules, tel que "TimeSeries" au lieu de "timeSeries".

  • 401 UNAUTHENTICATED par "L'utilisateur n'est pas autorisé à accéder au projet" (ou métrique)" : ce code d'erreur indique généralement un problème d'autorisation, Toutefois, cela peut signifier que l'ID du projet ou le type de métrique comportent une erreur. son nom. Vérifiez l'orthographe et la casse.

    Si ce n'est pas le cas, essayez APIs Explorer. Lorsque votre API fonctionne dans APIs Explorer, il existe probablement dans l'environnement où vous effectuez l'appel d'API. Accédez au page du gestionnaire d'API pour procéder à la validation que l'API Monitoring est activée pour votre projet.

  • 400 INVALID_ARGUMENT avec le message "Le filtre de champ contenait une valeur non valide" : vérifiez le 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 le message "Request was missing fieldInterval.endTime" : Ce message s'affiche lorsque l'heure de fin n'est pas spécifiée ou si elle est présente, mais n'est pas correctement formaté. Si vous utilisez APIs Explorer, ne mentionnez pas la valeur du temps .

    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, envisagez les éléments suivants:

  • Lorsque l'appel utilise un filtre, celui-ci peut ne pas correspondre n'importe quoi. La correspondance du filtre est sensible à la casse. Pour résoudre le filtre commencez par spécifier un seul composant de filtre, metric.type, puis vérifiez que vous obtenez les résultats. Ajoutez les autres composants de filtre un par un pour créer votre requête.
  • Lorsque vous travaillez avec une métrique personnalisée, vérifiez que le projet définit la métrique.

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 vers 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 l'heure de fin. Si l'heure de début est manquante ou incorrecte, l'API définit le l'heure de début à l'heure de fin. Pour GAUGE métriques, cet intervalle de temps uniquement correspond aux points dont les heures de début et de fin sont exactement l'heure de fin. Pour les métriques CUMULATIVE ou DELTA, qui mesurent 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 en cas de problème de courte durée temporaire.
  • 429 RESOURCE_EXHAUSTED: les nouvelles tentatives sont utiles, après un certain délai, pour tâches d'arrière-plan de longue durée avec un quota temporel tel que n appels par t secondes. Les nouvelles tentatives ne sont pas utiles en cas de problème temporaire, ou lorsque vous avez épuisé un quota basé sur le volume. Pour temporaires, envisagez de tolérer la défaillance. Pour les requêtes liées aux quotas envisagez de réduire votre utilisation du quota ou de demander une augmentation du 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 délai croissant d'intervalle entre les tentatives avec 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.