Solucionar problemas de la API de Monitoring

En esta guía se explican algunos de los problemas que pueden surgir al usar la API Monitoring.

La API Monitoring es una de las APIs de Cloud. Estas APIs comparten un conjunto común de códigos de error. Para ver una lista de los códigos de error definidos por las APIs de Cloud y sugerencias generales sobre cómo gestionar los errores, consulta Gestión de errores.

Usar el Explorador de APIs para depurar

Explorador de APIs es un widget integrado en las páginas de referencia de los métodos de la API. Te permite invocar el método rellenando campos, sin necesidad de escribir código.

Si tienes problemas con la invocación de un método, usa el widget Explorador de APIs (Probar esta API) de la página de referencia de ese método para depurar el problema. Para obtener más información, consulta Explorador de APIs.

Errores generales de la API

Estos son algunos de los errores y mensajes de la API Monitoring que pueden aparecer en las llamadas a la API:

• 404 NOT_FOUND con el mensaje "No se ha encontrado la URL solicitada en este servidor": Alguna parte de la URL no es correcta. Compara la URL con la URL del método que se muestra en la página de referencia del método. Este error puede deberse a un error ortográfico, como "project" en lugar de "projects", o a un error de uso de mayúsculas, como "TimeSeries" en lugar de "timeSeries".

• 401 UNAUTHENTICATED con "User is not authorized to access the project (or metric)": este código de error suele indicar un problema de autorización, pero también puede significar que hay un error en el ID del proyecto o en el nombre del tipo de métrica. Comprueba la ortografía y el uso de mayúsculas.

  Si no usas el Explorador de APIs, prueba a hacerlo. Si tu llamada a la API funciona en el Explorador de APIs, probablemente haya un problema de autorización en el entorno en el que estás haciendo la llamada. Ve a la página del gestor de APIs para comprobar que la API Monitoring está habilitada en tu proyecto.

• 400 INVALID_ARGUMENT con el mensaje "El filtro de campo tenía un valor no válido": comprueba la ortografía y el formato del filtro de monitorización. Para obtener más información, consulta Filtros de monitorización.

• 400 INVALID_ARGUMENT con el mensaje "Request was missing field interval.endTime" (Falta el campo interval.endTime en la solicitud): este mensaje aparece cuando falta la hora de finalización o cuando está presente, pero no tiene el formato correcto. Si usas Explorador de APIs, no incluyas el valor del campo de tiempo entre comillas.

  A continuación se muestran algunos ejemplos de especificaciones de tiempo válidas:

  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
  

Faltan resultados

Cuando una llamada a la API devuelve el código de estado 200 y una respuesta vacía, ten en cuenta lo siguiente:

• Cuando la llamada usa un filtro, es posible que no haya coincidido con nada. El filtro distingue entre mayúsculas y minúsculas. Para resolver problemas con los filtros, empieza especificando solo un componente del filtro, como metric.type, y comprueba que obtienes resultados. Añade los demás componentes del filtro uno a uno para crear tu solicitud.

• Cuando trabaje con una métrica personalizada, compruebe que se haya especificado el proyecto que define la métrica.

Hay varios motivos por los que pueden faltar puntos de datos al usar el método timeSeries.list:

• Es posible que los datos hayan caducado. Para obtener más información, consulta Conservación de datos.

• Es posible que los datos aún no se hayan propagado a Monitoring. Para obtener más información, consulta Latencia de los datos de métricas.

• El intervalo no es válido:

  • Comprueba que la hora de finalización sea correcta.
  • Comprueba que la hora de inicio sea correcta y que sea anterior a la hora de finalización. Si falta la hora de inicio o no tiene el formato correcto, la API asigna la hora de finalización a la hora de inicio. En el caso de las métricas GAUGE, este intervalo de tiempo solo coincide con los puntos cuyas horas de inicio y finalización son exactamente la hora de finalización del intervalo. En el caso de las métricas CUMULATIVE o DELTA, que miden intervalos de tiempo, no se asignan puntos. Para obtener más información, consulta Intervalos de tiempo.

Reintentar errores de la API

Dos de los códigos de error de las APIs de Cloud indican circunstancias en las que puede ser útil volver a intentar la solicitud:

• 503 UNAVAILABLE: los reintentos son útiles cuando el problema es una condición transitoria o de corta duración.
• 429 RESOURCE_EXHAUSTED: los reintentos son útiles, tras un retraso, para los trabajos en segundo plano de larga duración con una cuota basada en el tiempo, como n llamadas por t segundos. Los reintentos no son útiles cuando el problema es una condición transitoria o de corta duración, o cuando has agotado una cuota basada en el volumen. En el caso de las condiciones transitorias, puedes tolerar el fallo. Si tienes problemas relacionados con la cuota, considera la posibilidad de reducir el uso de la cuota o de solicitar un aumento.

Cuando escribas código que pueda reintentar solicitudes, primero asegúrate de que la solicitud se pueda reintentar de forma segura.

¿Es seguro volver a intentar la solicitud?

Si tu solicitud es idempotente, puedes volver a intentarlo sin problemas. Una acción idempotente es aquella en la que cualquier cambio de estado no depende del estado actual. Por ejemplo:

• La lectura de x es idempotente, ya que el valor no cambia.
• Asignar el valor 10 a x es idempotente. Esto puede cambiar el estado si el valor no es 10, pero no importa cuál sea el valor actual. Tampoco importa cuántas veces intentes asignar el valor.
• Incrementar x no es idempotente; el nuevo valor depende del valor actual.

Reintentar con un tiempo de espera exponencial

Cuando implementes código para reintentar solicitudes, no debes enviar nuevas solicitudes rápidamente de forma indefinida. Si un sistema está sobrecargado, este enfoque contribuye al problema.

En su lugar, usa un tiempo de espera exponencial truncado. Cuando las solicitudes fallan debido a sobrecargas transitorias en lugar de a una indisponibilidad real, la solución es reducir la carga. Un tiempo de espera exponencial truncado sigue este patrón general:

• Establece cuánto tiempo quieres esperar mientras se reintenta la operación o cuántos intentos quieres hacer. Cuando se supere este límite, considera que el servicio no está disponible y gestiona esa condición de forma adecuada para tu aplicación. Por eso, el tiempo de espera es truncado: dejas de reintentar en algún momento.

• Vuelve a intentar la solicitud con pausas cada vez más largas para reducir la frecuencia de los reintentos. Vuelve a intentarlo hasta que la solicitud se complete o se alcance el límite establecido.

  El intervalo suele aumentar en función de la potencia del número de reintentos, lo que lo convierte en un tiempo de espera exponencial.

Hay muchas formas de implementar un tiempo de espera exponencial. A continuación, se muestra un ejemplo que añade un retraso de retroadaptación creciente a un retraso mínimo de 1000 ms. El retraso inicial de interrupción es de 2 ms y aumenta a 2^retry_count ms con cada intento.

En la siguiente tabla se muestran los intervalos de reintento con los valores iniciales:

• Retraso mínimo = 1 s = 1000 ms
• Tiempo de espera inicial = 2 ms

Número de reintentos	Retraso adicional (ms)	Reintentar después de (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	1000 + 2^n

Puedes truncar el ciclo de reintentos deteniéndolo después de n intentos o cuando el tiempo transcurrido supere un valor razonable para tu aplicación.

Para obtener más información, consulta el artículo de Wikipedia sobre el tiempo de espera exponencial.