Soluciona problemas de la API de Monitoring

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

La API de Monitoring es uno de los conjuntos de API de Cloud. Estas API comparten un conjunto común de códigos de error. Si deseas obtener una lista de los códigos de error definidos por las API de Cloud y sugerencias generales para manejar los errores, consulta Maneja los errores.

Usa el Explorador de APIs para la depuración

El Explorador de API es un widget integrado en las páginas de referencia de los métodos de la API. Te permite invocar el método si completas los campos; no necesitas escribir código.

Si tienes problemas con una invocación de método, usa el widget del Explorador de APIs (Prueba esta API) en la página de referencia de ese método para depurar tu 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 de Monitoring que puedes ver a partir de tus llamadas a la API:

• 404 NOT_FOUND con el mensaje "No se encontró la URL solicitada en este servidor": Parte de la URL es incorrecta. Compara la URL con la URL del método que se muestra en la página de referencia del método. Este error puede significar una falta de ortografía, como "proyecto" en lugar de “proyectos”, o un error de mayúsculas, como "TimeSeries" en lugar de “timeSeries”.

• 401 UNAUTHENTICATED con el mensaje “El usuario no está autorizado para acceder al proyecto (o métrica)”: Por lo general, este código de error indica 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. Verifica la ortografía y el uso de mayúsculas.

  Si no usas el Explorador de APIs, intenta usarlo. Cuando tu llamada a la API funciona en el Explorador de APIs, es probable que haya un problema de autorización en el entorno en el que realizas la llamada a la API. Ve a la página del administrador de la API para verificar que la API de Monitoring esté habilitada para tu proyecto.

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

• 400 INVALID_ARGUMENT con el mensaje “A la solicitud le falta el campo interval.endTime”: Aparecerá este mensaje cuando falta la hora de finalización o si está presente, pero no tiene el formato correcto. Si usas el Explorador de APIs, no cites el valor del tiempo. .

  Estos son algunos ejemplos de especificaciones de hora 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
  

Resultados faltantes

Cuando una llamada a la API muestre 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 este no haya coincidido nada. La coincidencia del filtro distingue mayúsculas de minúsculas. Para resolver el filtro comienza por especificar un solo componente de filtro, como metric.type y verifica que obtienes resultados. Agrega los otros componentes de filtro uno por uno para compilar la solicitud.

• Cuando trabajes con una métrica personalizada, verifica que se especifique el proyecto que define la métrica.

Existen varios motivos por los que pueden faltar datos cuando usas el método timeSeries.list:

• Es posible que los datos hayan caducado. Si deseas obtener más información, consulta Retenció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:

  • Verifica que la hora de finalización sea correcta.
  • Verifica que la hora de inicio sea correcta y que sea anterior a la de finalización. Cuando falta la hora de inicio o tiene errores de formato, la API establece la desde la hora de inicio hasta la hora de finalización. Para las métricas GAUGE, este intervalo de tiempo solo coincide con los puntos cuyas horas de inicio y finalización sean exactamente la hora de finalización del intervalo. En el caso de las métricas CUMULATIVE o DELTA, que se miden en intervalos de tiempo, no se encuentran coincidencias. Para obtener más información, consulta Intervalos de tiempo.

Reintenta errores de API

Dos de los códigos de error de las API de Cloud indican circunstancias en las que podría ser útil para reintentar la solicitud:

• 503 UNAVAILABLE: Los reintentos son útiles cuando el problema es una condición de corta duración o transitoria.
• 429 RESOURCE_EXHAUSTED: Los reintentos son útiles, después de una demora, para 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 de corta duración como una condición transitoria o cuando se agota una cuota basada en volumen. Para para condiciones transitorias, considera tolerar la falla. Para cuotas considera reducir el uso de la cuota o solicitar un aumento de la cuota.

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

¿La solicitud es segura para reintentar?

Si tu solicitud es idempotente, entonces será seguro volver a intentarlo. 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. no hay cambios en el valor.
• Establecer x en 10 es idempotente; esto podría cambiar el estado, si el valor no es 10, pero no importa cuál es el valor actual, y tampoco importa cuántas veces intentes configurar el valor.
• Aumentar x no es idempotente, el valor nuevo depende del valor actual.

Vuelve a intentarlo con una retirada exponencial.

Cuando implementes código para reintentar las solicitudes, no querrás emitir nuevas solicitudes de forma indefinida. Si un sistema está sobrecargado, este enfoque contribuye al problema.

En su lugar, usa un enfoque de retirada exponencial truncada. Cuando las solicitudes fallan debido a sobrecargas transitorias en lugar de una verdadera disponibilidad, la solución reduce la carga. Una retirada exponencial truncada sigue el patrón general:

• Establece el tiempo que estás dispuesto a esperar mientras reintentas o cuántos intentos quieres realizar. Cuando se excede este límite, considera que el servicio no está disponible y maneja esa condición de manera adecuada para la aplicación. Esto es lo que hace que la retirada se trunque, dejas de reintentar en algún momento.

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

  Por lo general, el intervalo aumenta por una función del poder del reintento, lo que lo convierte en una retirada exponencial.

Hay muchas formas de implementar una retirada exponencial. El siguiente es un ejemplo que agrega una demora en la retirada creciente a un retraso mínimo de 1,000 ms. El retraso de retirada inicial es de 2 ms y aumenta a 2^retry_countms con cada intento.

En la siguiente tabla, se muestran los intervalos de reintentos mediante los valores iniciales:

• Retraso mínimo = 1 s = 1,000 ms
• Retirada inicial = 2 ms

Conteo de repeticiones de intento	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 mediante la detención después de n intentos o cuando el tiempo empleado exceda un valor razonable para tu aplicación.

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