Solucionar problemas de errores de respuesta

En esta página se describe cómo solucionar los errores que recibes en una respuesta de una solicitud a tu API.

Upstream backend unavailable

Si recibes el código de error 14 y el mensaje upstream backend unavailable, esto indica que el proxy de servicio extensible (ESP) no puede acceder al backend del servicio. Comprueba lo siguiente:

• Asegúrate de que el servicio de backend se esté ejecutando. La forma de hacerlo depende del backend.
  • Para obtener más información sobre Compute Engine, consulta el artículo Solucionar problemas de Cloud Endpoints en Compute Engine.
  • En GKE, debes usar SSH para acceder al pod y usar curl. Para obtener más información, consulta la sección Solución de problemas de Endpoints en Google Kubernetes Engine.

• Se ha especificado el puerto de dirección IP correcto del servicio backend:
  • En GKE, comprueba el valor de la marca --backend de ESP (la opción abreviada es -a) en el archivo de manifiesto de tu implementación (a menudo se llama deployment.yaml).
  • En Compute Engine, comprueba el valor de la marca ESP --backend (la opción abreviada es -a) en el comando docker run.

reset reason: connection failure

Si recibes el código HTTP 503 o el código gRPC 14 y el mensaje upstream connect error or disconnect/reset before headers. reset reason: connection failure, significa que ESPv2 no puede acceder al backend del servicio.

Para solucionar el problema, comprueba los elementos que se indican a continuación.

Dirección de backend

ESPv2 debe configurarse con la dirección de backend correcta. Entre los más habituales se encuentran los siguientes:

• El esquema de la dirección del backend debe coincidir con el tipo de aplicación del backend. Los back-ends de OpenAPI deben ser http:// y los de gRPC, grpc://.
• En el caso de ESPv2 implementado en Cloud Run, el esquema de la dirección del backend debe ser https:// o grpcs://. El s indica a ESPv2 que configure TLS con el backend.

Petición de DNS

De forma predeterminada, ESPv2 intenta resolver los nombres de dominio en direcciones IPv6. Si la resolución de IPv6 falla, ESPv2 vuelve a las direcciones IPv4.

En algunas redes, es posible que el mecanismo de respaldo no funcione correctamente. En su lugar, puede forzar a ESPv2 a usar direcciones IPv4 mediante la marca --backend_dns_lookup_family.

Este error es habitual si configura un conector de VPC sin servidor para ESPv2 implementado en Cloud Run. Las VPCs no admiten tráfico IPv6.

API is not enabled for the project

Si has enviado una clave de API en la solicitud, un mensaje de error como "API my-api.endpoints.example-project-12345.cloud.goog is not enabled for the project" indica que la clave de API se ha creado en un proyecto de Google Cloud distinto al de la API. Para solucionar este problema, puedes crear la clave de API en el mismo proyecto Google Cloud al que está asociada la API o habilitar la API en el proyecto Google Cloud en el que se creó la clave de API.

Service control request failed with HTTP response code 403

Si recibes el código de error 14 y el mensaje Service control request failed with HTTP response code 403, significa que la API Service Control (servicecontrol.googleapis.com) no está habilitada en el proyecto.

1. Consulta la sección Comprobar los servicios necesarios para asegurarte de que todos los servicios que requieren Endpoints y ESP estén habilitados en tu proyecto.

2. Consulta la sección Comprobar los permisos necesarios para asegurarte de que la cuenta de servicio asociada a la instancia que ejecuta ESP tiene todos los permisos necesarios.

Method doesn't allow unregistered callers

El ESP responde con el error Method doesn't allow unregistered callers cuando has especificado allow_unregistered_calls: false en tu archivo de configuración de la API gRPC, pero la solicitud a tu API no tiene ninguna clave de API asignada a un parámetro de consulta llamado key.

Si necesitas generar una clave de API para hacer llamadas a tu API, consulta Crear una clave de API.

Method does not exist

La respuesta Method does not exist significa que no se ha encontrado el método HTTP (GET, POST u otro) en la ruta de URL especificada. Para solucionar problemas, compara la configuración del servicio que has implementado para asegurarte de que el nombre del método y la ruta de URL que envías en la solicitud coincidan:

1. En la Google Cloud consola, ve a la página Servicios de endpoints de tu proyecto.

   Ir a la página Servicios de Endpoints

2. Si tienes más de una API, selecciona la API a la que has enviado la solicitud.

3. Haz clic en la pestaña Historial de implementaciones.

4. Selecciona la implementación más reciente para ver la configuración del servicio.

Transport is closing

Si recibes el código de error 13 y el mensaje transport is closing, significa que no se puede acceder al ESP.

Consulta los registros de errores del ESP. La forma de hacerlo depende del backend. Consulta las siguientes secciones para obtener más información:

• Ver registros en Compute Engine
• Acceder a los registros de ESP en GKE

Respuestas inesperadas

Si la respuesta HTTP parece binaria, puede indicar que la solicitud está llegando a la API mediante el puerto HTTP2 cuando querías usar el puerto HTTP1.

Comprueba las opciones de configuración de puertos de ESP. Como las marcas de formato corto, -p (para HTTP1) y -P (para HTTP2), son similares, te recomendamos que uses las marcas de formato largo: --http_port para HTTP1 y --http2_port para HTTP2.

Una configuración incorrecta del backend de ESP también puede provocar respuestas inesperadas. Comprueba que la marca de backend (-a o --backend) esté definida en una URL de gRPC, como --backend=grpc://127.0.0.1:8081.

Para obtener más información sobre las marcas de ESP, consulta las opciones de inicio de ESP.

Consultar los registros de Cloud Logging

Para usar los registros de Cloud Logging y solucionar problemas de errores de respuesta, sigue estos pasos:

1. En la Google Cloud consola, ve a la página Registro.

   Ir a la página Explorador de registros

2. En la parte superior de la página, selecciona el Google Cloud proyecto.

3. En el menú desplegable de la izquierda, selecciona API producida > [YOUR_SERVICE_NAME].

4. Ajusta el intervalo de tiempo hasta que veas una fila que muestre el error de respuesta.

5. Expande la carga útil de JSON y busca error_cause.

   • Si error_cause tiene el valor application, significa que hay un problema en tu código.

   • Si el error cause es otro valor y no puedes solucionar el problema, exporta el registro e inclúyelo en cualquier comunicación que tengas con Google.

Consulta las siguientes secciones para obtener más información:

• Para obtener información sobre la estructura de los registros del Explorador de registros, consulta la referencia de registros de endpoints.

• Empieza a usar el Explorador de registros.

• Usa consultas de registros avanzadas para aplicar filtros avanzados, como obtener todas las solicitudes con una latencia superior a 300 milisegundos.