Cette page explique comment résoudre les erreurs que vous recevez en réponse à une requête adressée à votre API.
Upstream backend unavailable
Si vous recevez un code d'erreur 14
avec le message upstream backend unavailable
, cela signifie que le proxy ESP ne peut pas atteindre le backend du service. Vérifiez les éléments suivants :
- Assurez-vous que le service de backend est en cours d'exécution. La manière de procéder dépend du backend.
- Pour Compute Engine, consultez la section Résoudre les problèmes liés à Cloud Endpoints sur Compute Engine pour en savoir plus.
-
Pour GKE, vous devez utiliser SSH pour accéder au pod et utiliser
curl
. Pour en savoir plus, consultez la page Résoudre les problèmes liés à Cloud Endpoints sur Google Kubernetes Engine.
- La paire adresse IP/port du service de backend est correctement spécifiée :
- Pour GKE, vérifiez la valeur de l'option ESP
--backend
(l'option abrégée est-a
) dans votre fichier manifeste de déploiement (généralement appelédeployment.yaml
). - Pour Compute Engine, vérifiez la valeur de l'option ESP
--backend
(l'option abrégée est-a
) dans la commandedocker run
.
- Pour GKE, vérifiez la valeur de l'option ESP
reset reason: connection failure
Si vous recevez le code HTTP 503
ou le code gRPC 14
et le message upstream connect error or disconnect/reset before headers. reset reason: connection failure
, cela signifie qu'ESPv2 ne peut pas atteindre le backend du service.
Pour résoudre le problème, vérifiez les éléments ci-dessous.
Adresse du backend
Vous devez configurer ESPv2 avec l'adresse de backend appropriée. Problèmes courants :
- Le schéma de l'adresse de backend doit correspondre au type d'application backend.
Les backends OpenAPI doivent être
http://
et les backends gRPC doivent êtregrpc://
. - Pour ESPv2 déployé sur Cloud Run, le schéma de l'adresse de backend doit être
https://
ougrpcs://
. Les
indique à ESPv2 de configurer TLS avec le backend.
Résolution DNS
Par défaut, ESPv2 tente de résoudre les noms de domaine en adresses IPv6. Si la résolution IPv6 échoue, ESPv2 revient aux adresses IPv4.
Pour certains réseaux, le mécanisme de remplacement peut ne pas fonctionner comme prévu.
À la place, vous pouvez forcer ESPv2 à utiliser des adresses IPv4 via l'option --backend_dns_lookup_family
.
Cette erreur est courante si vous configurez un connecteur VPC sans serveur pour ESPv2 déployé sur Cloud Run. Les VPC ne sont pas compatibles avec le trafic IPv6.
API is not enabled for the project
Si vous avez envoyé une clé API dans la requête, un message d'erreur de type "API my-api.endpoints.example-project-12345.cloud.goog is not enabled for the project" (l'API my-api.endpoints.example-project-12345.cloud.goog n'est pas activée pour le projet) indique que la clé API a été créée dans un autre projet Google Cloud que celui hébergeant l'API. Pour résoudre ce problème, vous pouvez soit créer la clé API dans le projet Google Cloud auquel l'API est associée, soit activer l'API dans le projet Google Cloud dans lequel la clé API a été créée.
Service control request failed with HTTP response code 403
Si vous recevez le code d'erreur 14
et le message Service control request failed
with HTTP response code 403
, cela signifie que l'API Service Control (servicecontrol.googleapis.com
) n'est pas activée pour le projet.
Consultez la section Vérifier les services requis pour vous assurer que tous les services requis par Cloud Endpoints et ESP sont activés pour le projet.
Consultez la section Vérifier les autorisations requises pour vous assurer que toutes les autorisations requises pour le compte de service associé à l'instance exécutant ESP sont ajoutées.
Method doesn't allow unregistered callers
ESP répond avec l'erreur Method doesn't allow unregistered callers
lorsque vous avez spécifié allow_unregistered_calls: false
dans votre fichier de configuration d'API gRPC, mais que la requête adressée à l'API ne comporte pas de clé API attribuée à un paramètre de requête nommé key
.
Si vous devez générer une clé API pour effectuer des appels vers l'API, consultez la section Créer une clé API.
Method does not exist
La réponse Method does not exist
signifie que la méthode HTTP (GET
, POST
ou autre) du chemin d'URL spécifié est introuvable. Pour résoudre ce problème, comparez la configuration de service que vous avez déployée pour vous assurer qu'il y a bien correspondance entre le nom de la méthode et le chemin d'URL que vous envoyez dans la requête :
Dans la console Google Cloud, accédez à la page Services Endpoints de votre projet.
Si vous avez plusieurs API, sélectionnez celle à laquelle vous avez envoyé la requête.
Cliquez sur l'onglet Historique des déploiements.
Sélectionnez le dernier déploiement pour voir la configuration du service.
Transport is closing
Si vous recevez le code d'erreur 13
et le message transport is closing
, cela signifie qu'ESP est inaccessible.
Vérifiez les journaux d'erreur ESP. La manière de procéder dépend du backend. Pour en savoir plus, lisez les informations ci-après.
Réponses inattendues
Si la réponse HTTP semble être binaire, cela peut indiquer que la requête appelle l'API via le port HTTP2
alors que vous comptiez utiliser le port HTTP1
.
Vérifiez vos options de configuration de port pour ESP. Comme les options courtes -p
(pour HTTP1
) et -P
(pour HTTP2
) sont similaires, nous vous recommandons d'utiliser leur forme longue : --http_port
pour HTTP1
et --http2_port
pour HTTP2
.
Une mauvaise configuration du backend ESP peut également entraîner des réponses inattendues. Assurez-vous que l'option backend (-a
ou --backend
) est définie sur une URL gRPC telle que --backend=grpc://127.0.0.1:8081
.
Pour en savoir plus sur les options ESP, consultez la page Options de démarrage ESP.
Vérifier les journaux Cloud Logging
Pour utiliser les journaux Cloud Logging afin de résoudre les erreurs de réponse, suivez les étapes suivantes :
Dans la console Google Cloud, accédez à la page Logging.
En haut de la page, sélectionnez le projet Google Cloud.
À l'aide du menu déroulant situé à gauche, sélectionnez API produite > [NOM_DE_VOTRE_SERVICE].
Ajustez la période jusqu'à voir une ligne indiquant votre erreur de réponse.
Développez la charge utile JSON et recherchez
error_cause
.Si
error_cause
est défini surapplication
, cela indique un problème dans votre code.Si
error cause
indique un autre problème et que vous ne parvenez pas à le résoudre, exportez le journal et joignez-le aux échanges que vous allez établir à ce sujet avec Google.
Pour en savoir plus, lisez les informations ci-après.
Pour en savoir plus sur la structure des journaux dans l'explorateur de journaux, consultez la documentation de référence des journaux Endpoints.
Commencez à utiliser l'explorateur de journaux.
Utilisez les requêtes de journaux avancées pour effectuer un filtrage plus poussé et obtenir, par exemple, toutes les requêtes dont la latence dépasse 300 millisecondes.