Soluciona problemas de la API de Monitoring

En esta guía, se explican algunos de los problemas que pueden surgir cuando usas 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 depurar

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 completando campos; no requiere que escribas código.

Si tienes problemas con la invocación de un método, usa el widget del Explorador de API (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 su página de referencia. Este error puede significar que hay un error de ortografía, como “project” en lugar de “projects”, o un error de mayúsculas, como “TimeSeries” en lugar de “timeSeries”.

• 401 UNAUTHENTICATED con "El usuario no tiene autorización para acceder al proyecto (o la métrica)": Este código de error, por lo general, indica un problema de autorización, pero 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 Administrador de API y verifica que la API de Monitoring esté habilitada para tu proyecto.

• 400 INVALID_ARGUMENT con “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 "Falta el campo de la solicitud tiempo.endTime": Verás este mensaje cuando falta la hora de finalización o cuando está presente, pero no tiene el formato correcto. Si usas el Explorador de APIs, no cites el valor del campo de tiempo.

  Estos son 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
  

Resultados faltantes

Cuando una llamada a la API muestra 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 coincida con nada. La coincidencia del filtro distingue mayúsculas de minúsculas. Para resolver los problemas relacionados con los filtros, primero especifica un solo componente de filtro, como metric.type, y verifica que obtengas 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 se hayan agotado. 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 hora de finalización. Cuando falta la hora de inicio o tiene errores de formato, la API la establece en la hora de finalización. Para las métricas de 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. Para las métricas CUMULATIVE o DELTA, que miden en intervalos de tiempo, no se detecta ninguna coincidencia de puntos. 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 transitoria o de corta duración.
• 429 RESOURCE_EXHAUSTED: Los reintentos son útiles, después de un retraso, para trabajos en segundo plano de larga duración con 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 agotaste una cuota basada en el volumen. Para condiciones transitorias, considera tolerar la falla. Para problemas relacionados con la cuota, 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 un retraso de 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.