Solucionar problemas del servicio gestionado de Prometheus

En este documento se describen algunos problemas que pueden surgir al usar Google Cloud Managed Service para Prometheus y se proporciona información sobre cómo diagnosticarlos y resolverlos.

Has configurado Managed Service para Prometheus, pero no ves ningún dato de métricas en Grafana ni en la interfaz de usuario de Prometheus. A grandes rasgos, la causa puede ser una de las siguientes:

• Un problema en el lado de la consulta, por lo que no se pueden leer los datos. Los problemas del lado de la consulta suelen deberse a permisos incorrectos en la cuenta de servicio que lee los datos o a una configuración incorrecta de Grafana.

• Un problema en la parte de la ingesta, por lo que no se envían datos. Los problemas del lado de la ingestión pueden deberse a problemas de configuración con las cuentas de servicio, los colectores o la evaluación de reglas.

Para determinar si el problema se produce en la parte de la ingestión o en la de la consulta, prueba a consultar datos mediante la pestaña PromQL del explorador de métricas en la consola de Google Cloud . Se garantiza que esta página no tendrá ningún problema con los permisos de lectura ni con la configuración de Grafana.

Para ver esta página, haga lo siguiente:

1. Usa el Google Cloud selector de proyectos de la consola para seleccionar el proyecto del que no ves datos.

2. En la Google Cloud consola, ve a la página leaderboard Explorador de métricas:

   Ve al explorador de métricas.

   Si usas la barra de búsqueda para encontrar esta página, selecciona el resultado cuya sección sea Monitorización.

3. En la barra de herramientas del panel de creación de consultas, selecciona el botón cuyo nombre sea code MQL o code PromQL.

4. Verifica que PromQL esté seleccionado en el interruptor Idioma. El interruptor de idioma se encuentra en la misma barra de herramientas que te permite dar formato a tu consulta.

5. Introduce la siguiente consulta en el editor y, a continuación, haz clic en Ejecutar consulta:

   up
   

Si consulta la métrica up y ve resultados, significa que el problema está en la consulta. Para obtener información sobre cómo resolver estos problemas, consulta Problemas del lado de la consulta.

Si consulta la métrica up y no ve ningún resultado, el problema está en la ingestión. Para obtener información sobre cómo resolver estos problemas, consulta la sección Problemas del lado de la ingesta.

Un cortafuegos también puede provocar problemas de ingesta y de consultas. Para obtener más información, consulta el artículo Cortafuegos.

La página Gestión de métricas de Cloud Monitoring proporciona información que puede ayudarte a controlar el importe que gastas en métricas facturables sin que esto afecte a la observabilidad. En la página Gestión de métricas se muestra la siguiente información:

• Volúmenes de ingesta para la facturación basada en bytes y en muestras, en todos los dominios de métricas y para métricas concretas.
• Datos sobre las etiquetas y la cardinalidad de las métricas.
• Número de lecturas de cada métrica.
• Uso de métricas en políticas de alertas y paneles de control personalizados.
• Tasa de errores de escritura de métricas.

También puede usar la página Gestión de métricas para excluir las métricas que no necesite y, de esta forma, no incurrir en los costes de ingesta.

Para ver la página Gestión de métricas, haz lo siguiente:

1. En la Google Cloud consola, ve a la página query_stats Gestión de métricas:

   Ve a Gestión de métricas.

   Si usas la barra de búsqueda para encontrar esta página, selecciona el resultado cuya sección sea Monitorización.

2. En la barra de herramientas, selecciona el periodo que quieras. De forma predeterminada, la página Gestión de métricas muestra información sobre las métricas recogidas en el día anterior.

Para obtener más información sobre la página Gestión de métricas, consulta el artículo Ver y gestionar el uso de métricas.

Problemas del lado de la consulta

La mayoría de los problemas del lado de la consulta se deben a uno de los siguientes motivos:

• Permisos o credenciales incorrectos para las cuentas de servicio.
• Una configuración incorrecta de Workload Identity Federation para GKE, si tu clúster tiene esta función habilitada. Para obtener más información, consulta Configurar una cuenta de servicio para Workload Identity Federation en GKE.

Para empezar, haz lo siguiente:

• Comprueba detenidamente tu configuración siguiendo las instrucciones de configuración para las consultas.

• Si usas la federación de identidades de carga de trabajo para GKE, comprueba que tu cuenta de servicio tenga los permisos correctos haciendo lo siguiente:

  1. En la Google Cloud consola, ve a la página Gestión de identidades y accesos:

     Ve a Gestión de identidades y accesos.

     Si usas la barra de búsqueda para encontrar esta página, selecciona el resultado cuyo subtítulo sea IAM y administrador.

  2. Identifica el nombre de la cuenta de servicio en la lista de principales. Verifica que el nombre de la cuenta de servicio esté escrito correctamente. A continuación, haz clic en edit Editar.

  3. Selecciona el campo Rol y, a continuación, haz clic en Usado actualmente y busca el rol Lector de Monitoring. Si la cuenta de servicio no tiene este rol, añádelo ahora.

Si el problema persiste, ten en cuenta las siguientes posibilidades:

Secretos mal configurados o con errores tipográficos

Si ves alguno de los siguientes mensajes, es posible que falte el secreto o que esté mal escrito:

• Uno de estos errores "prohibidos" en Grafana o en la interfaz de usuario de Prometheus:

  • "Advertencia: Estado de respuesta inesperado al obtener la hora del servidor: Forbidden"
  • "Advertencia: Error al obtener la lista de métricas: estado de respuesta inesperado al obtener los nombres de las métricas: Forbidden" ("Prohibido")

• Un mensaje como este en tus registros:
  "cannot read credentials file: open /gmp/key.json: no such file or directory" ("no se puede leer el archivo de credenciales: open /gmp/key.json: no existe el archivo o el directorio")

Si usas el sincronizador de fuentes de datos para autenticar y configurar Grafana, prueba lo siguiente para resolver estos errores:

1. Verifica que has elegido el endpoint de la API de Grafana, el UID de la fuente de datos de Grafana y el token de la API de Grafana correctos. Puedes inspeccionar las variables de CronJob ejecutando el comando kubectl describe cronjob datasource-syncer.

2. Compruebe que el ID de proyecto del sincronizador de fuentes de datos sea el mismo ámbito de métricas o proyecto para el que su cuenta de servicio tenga credenciales.

3. Verifica que tu cuenta de servicio de Grafana tenga el rol "Administrador" y que tu token de API no haya caducado.

4. Verifica que tu cuenta de servicio tenga el rol Lector de Monitoring en el ID de proyecto elegido.

5. Comprueba que no haya errores en los registros del trabajo de sincronización de la fuente de datos ejecutando kubectl logs job.batch/datasource-syncer-init. Este comando se debe ejecutar inmediatamente después de aplicar el archivo datasource-syncer.yaml.

6. Si usas la federación de identidades de cargas de trabajo para GKE, comprueba que no hayas cometido ningún error al escribir la clave o las credenciales de la cuenta y que la hayas vinculado al espacio de nombres correcto.

Si utiliza el proxy de interfaz de usuario frontend antiguo, pruebe lo siguiente para resolver estos errores:

1. Comprueba que el ID de proyecto de la interfaz de usuario frontend sea el mismo ámbito de métricas o proyecto para el que tu cuenta de servicio tenga credenciales.

2. Verifica el ID de proyecto que has especificado para las marcas --query.project-id.

3. Verifica que tu cuenta de servicio tenga el rol Lector de Monitoring en el ID de proyecto elegido.

4. Comprueba que hayas definido el ID de proyecto correcto al desplegar la interfaz de usuario frontend y que no lo hayas dejado con la cadena literal PROJECT_ID.

5. Si usas Workload Identity, comprueba que no hayas escrito mal la clave o las credenciales de la cuenta y que la hayas vinculado al espacio de nombres correcto.

6. Si vas a montar tu propio secreto, asegúrate de que esté presente:

   kubectl get secret gmp-test-sa -o json | jq '.data | keys'
   

7. Verifica que el secreto se haya montado correctamente:

   kubectl get deploy frontend -o json | jq .spec.template.spec.volumes
   
   kubectl get deploy frontend -o json | jq .spec.template.spec.containers[].volumeMounts
   

8. Asegúrate de que el secreto se transfiere correctamente al contenedor:

   kubectl get deploy frontend -o json | jq .spec.template.spec.containers[].args
   

Método HTTP incorrecto para Grafana

Si ves el siguiente error de la API de Grafana, significa que Grafana está configurado para enviar una solicitud POST en lugar de una solicitud GET:

• "{"status":"error","errorType":"bad_data","error":"no match[] parameter provided"}%"

Para solucionar este problema, configura Grafana para que use una solicitud GET siguiendo las instrucciones de Configurar una fuente de datos.

Tiempo de espera agotado en consultas grandes o de larga duración

Si ves el siguiente error en Grafana, significa que el tiempo de espera de la consulta predeterminado es demasiado bajo:

• "Post "http://frontend.NAMESPACE_NAME.svc:9090/api/v1/query_range": net/http: timeout awaiting response headers" ("Post "http://frontend.NAMESPACE_NAME.svc:9090/api/v1/query_range": net/http: tiempo de espera agotado para los encabezados de respuesta")

Managed Service para Prometheus no agota el tiempo de espera hasta que una consulta supera los 120 segundos, mientras que Grafana agota el tiempo de espera después de 30 segundos de forma predeterminada. Para solucionar este problema, aumenta los tiempos de espera en Grafana a 120 segundos siguiendo las instrucciones que se indican en Configurar una fuente de datos.

Errores de validación de etiquetas

Si ves uno de los siguientes errores en Grafana, es posible que estés usando un endpoint no compatible:

• "Validación: aún no se admiten etiquetas que no sean name"
• "Plantillas [tarea]: Error al actualizar las opciones: aún no se admiten etiquetas que no sean name."

Managed Service para Prometheus solo admite el endpoint /api/v1/$label/values para la etiqueta __name__. Esta limitación provoca que las consultas que usan la variable label_values($label) en Grafana fallen.

En su lugar, utiliza el formulario label_values($metric, $label). Esta consulta se recomienda porque limita los valores de las etiquetas devueltas por métrica, lo que evita que se recuperen valores que no estén relacionados con el contenido del panel de control. Esta consulta llama a un endpoint compatible con Prometheus.

Para obtener más información sobre los endpoints admitidos, consulta Compatibilidad con la API.

Se ha superado la cuota

Si ves el siguiente error, significa que has superado tu cuota de lectura de la API Cloud Monitoring:

• "429: RESOURCE_EXHAUSTED: Se ha superado la cuota de la métrica 'Consultas de serie temporal ' y el límite de 'Consultas de serie temporal por minuto' del servicio 'monitoring.googleapis.com' para el consumidor 'project_number:...'."

Para solucionar este problema, envíe una solicitud para aumentar su cuota de lectura de la API Monitoring. Para obtener ayuda, ponte en contacto con el Google Cloud servicio de asistencia. Para obtener más información sobre las cuotas, consulta la documentación de Cloud Quotas.

Métricas de varios proyectos

Si quieres ver métricas de varios Google Cloud proyectos, no tienes que configurar varios sincronizadores de fuentes de datos ni crear varias fuentes de datos en Grafana.

En su lugar, crea un permiso de métricas de Cloud Monitoring en un proyecto (el proyecto de ámbito) que contenga los proyectos que quieras monitorizar.Google Cloud Cuando configuras la fuente de datos de Grafana con un proyecto de ámbito, obtienes acceso a los datos de todos los proyectos del ámbito de las métricas. Para obtener más información, consulta Ámbitos de consultas y métricas.

No se ha especificado ningún tipo de recurso monitorizado

Si ves el siguiente error, debes especificar un tipo de recurso monitorizado cuando uses PromQL para consultar una Google Cloud métrica del sistema:

• "La métrica se ha configurado para usarse con más de un tipo de recurso monitorizado. El selector de series debe especificar un comparador de etiquetas en el nombre del recurso monitorizado"

Puede especificar un tipo de recurso monitorizado filtrando por la etiqueta monitored_resource. Para obtener más información sobre cómo identificar y elegir un tipo de recurso monitorizado válido, consulta Especificar un tipo de recurso monitorizado.

Los valores sin procesar de los contadores, histogramas y resúmenes no coinciden entre la interfaz de usuario del recopilador y la Google Cloud consola

Es posible que observe una diferencia entre los valores de la interfaz de usuario de Prometheus del recopilador local y los de la consola Google Cloud Google Cloud al consultar el valor sin procesar de las métricas acumulativas de Prometheus, incluidos los contadores, los histogramas y los resúmenes. Este comportamiento es el esperado.

Monarch requiere marcas de tiempo de inicio, pero Prometheus no las tiene. Managed Service para Prometheus genera marcas de tiempo de inicio omitiendo el primer punto ingerido de cualquier serie temporal y convirtiéndolo en una marca de tiempo de inicio. Los puntos posteriores tienen el valor del punto inicial omitido restado de su valor para asegurarse de que las tarifas sean correctas. Esto provoca un déficit persistente en el valor sin procesar de esos puntos.

La diferencia entre el número de la interfaz de usuario del recolector y el número de la consolaGoogle Cloud es igual al primer valor registrado en la interfaz de usuario del recolector, lo cual es lógico, ya que el sistema omite ese valor inicial y lo resta de los puntos posteriores.

Esto es aceptable porque no es necesario ejecutar una consulta para obtener los valores brutos de las métricas acumulativas en producción. Todas las consultas útiles requieren una función rate() o similar, en cuyo caso la diferencia en cualquier periodo es idéntica entre las dos interfaces de usuario. Las métricas acumulativas solo aumentan, por lo que no puedes definir una alerta en una consulta sin procesar, ya que una serie temporal solo alcanza un umbral una vez. Todas las alertas y los gráficos útiles analizan el cambio o la tasa de cambio del valor.

El recolector solo almacena unos 10 minutos de datos de forma local. También pueden producirse discrepancias en los valores acumulados sin procesar si se produce un restablecimiento antes del horizonte de 10 minutos. Para descartar esta posibilidad, prueba a definir un periodo de retrospectiva de consulta de solo 10 minutos al comparar la interfaz de usuario del recolector con la consola de Google Cloud .

Las discrepancias también pueden deberse a que tu aplicación tenga varios hilos de trabajador, cada uno con un endpoint /metrics. Si tu aplicación crea varios subprocesos, debes poner la biblioteca de cliente de Prometheus en modo multiproceso. Para obtener más información, consulta la documentación sobre cómo usar el modo multiproceso en la biblioteca de cliente de Python de Prometheus.

Faltan datos de contador o los histogramas no funcionan

La señal más habitual de este problema es que no se muestren datos o que haya lagunas en los datos al consultar una métrica de contador simple (por ejemplo, una consulta de PromQL de metric_name_foo). Puedes confirmar que se trata de este problema si aparecen datos después de añadir una función rate a tu consulta (por ejemplo, rate(metric_name_foo[5m])).

También puede observar que el número de muestras ingeridas ha aumentado considerablemente sin que haya habido ningún cambio importante en el volumen de raspado o que se estén creando métricas nuevas con los sufijos "unknown" o "unknown:counter" en Cloud Monitoring.

También puede que observes que las operaciones de histograma, como la función quantile(), no funcionan como se espera.

Estos problemas se producen cuando se recoge una métrica sin un tipo de métrica de Prometheus. Como Monarch tiene un tipado fuerte, Managed Service para Prometheus tiene en cuenta las métricas sin tipo añadiéndoles el sufijo "unknown" e ingiriéndolas dos veces, una como un indicador y otra como un contador. A continuación, el motor de consultas elige si debe consultar la métrica de contador o de indicador subyacente en función de las funciones de consulta que utilice.

Aunque esta heurística suele funcionar bastante bien, puede provocar problemas, como resultados extraños al consultar una métrica "unknown:counter" sin procesar. Además, como los histogramas son objetos con un tipo específico en Monarch, si se ingieren las tres métricas de histograma obligatorias como métricas de contador individuales, las funciones de histograma no funcionarán. Como las métricas de tipo "unknown" se ingieren dos veces, si no se define un tipo, se duplicarán las muestras ingeridas.

Estos son algunos de los motivos habituales por los que puede que no se haya definido el tipo:

• Configurar por error un recopilador de Managed Service para Prometheus como servidor de federación. La federación no se admite cuando se usa Managed Service para Prometheus. Como la federación elimina intencionadamente la información de TYPE, al implementarla se generan métricas de tipo "unknown".
• Usar Prometheus Remote Write en cualquier punto de la canalización de ingestión. Este protocolo también elimina intencionadamente la información de TYPE.
• Usar una regla de cambio de etiqueta que modifique el nombre de la métrica. De este modo, la métrica cuyo nombre se ha cambiado se desvincula de la información de TYPE asociada al nombre de la métrica original.
• El exportador no emite un TYPE para cada métrica.
• Un problema transitorio en el que se elimina TYPE cuando el recolector se inicia por primera vez.

Para solucionar este problema, sigue estos pasos:

• Dejar de usar la federación con Managed Service para Prometheus. Si quiere reducir la cardinalidad y los costes agregando datos antes de enviarlos a Monarch, consulte Configurar la agregación local.
• Dejar de usar Prometheus Remote Write en la ruta de recogida.
• Confirma que el campo # TYPE existe en cada métrica visitando el endpoint /metrics.
• Elimina las reglas de cambio de nombre que modifiquen el nombre de una métrica.
• Elimina las métricas en conflicto con el sufijo "unknown" o "unknown:counter" llamando a DeleteMetricDescriptor.
• También puedes consultar siempre los contadores con rate u otra función de procesamiento de contadores.

También puede crear una regla de exclusión de métricas en Gestión de métricas para evitar que se ingieran métricas con el sufijo "unknown" mediante la expresión regular prometheus.googleapis.com/.+/unknown.*. Si no solucionas el problema subyacente antes de instalar esta regla, es posible que impidas que se ingieran los datos de métricas que quieras.

Los datos de Grafana no se conservan después de reiniciar el pod

Si tus datos parecen desaparecer de Grafana después de reiniciar un pod, pero están visibles en Cloud Monitoring, significa que estás usando Grafana para consultar la instancia local de Prometheus en lugar de Managed Service para Prometheus.

Para obtener información sobre cómo configurar Grafana para usar el servicio gestionado como fuente de datos, consulta Grafana.

Resultados de consultas o reglas de alertas incoherentes que se corrigen automáticamente

Es posible que observes un patrón en el que las consultas de ventanas recientes, como las consultas ejecutadas por reglas de registro o de alerta, devuelvan picos de datos inexplicables. Si investigas el pico ejecutando la consulta en Grafana o en Explorador de métricas, puede que veas que el pico ha desaparecido y que los datos vuelven a tener un aspecto normal.

Este comportamiento puede ocurrir con más frecuencia si se da alguna de las siguientes circunstancias:

• Ejecutas de forma constante muchas consultas muy similares en paralelo, quizá mediante reglas. Estas consultas solo pueden diferenciarse entre sí por un atributo. Por ejemplo, puede que tengas 50 reglas de registro que solo se diferencien en el VALUE del filtro {foo="VALUE"} o que solo se diferencien en los valores de [duration] de la función rate.
• Estás ejecutando consultas en time=now sin ningún búfer.
• Estás ejecutando consultas instantáneas, como alertas o reglas de grabación. Si usas una regla de registro, puede que observes que el resultado guardado tiene el pico, pero no se puede encontrar al ejecutar una consulta sobre los datos sin procesar.
• Está consultando dos métricas para crear una relación. Los picos son más pronunciados cuando el recuento de series temporales es bajo en la consulta del numerador o del denominador.
• Los datos de métricas se encuentran en Google Cloud regionesus-central1 más grandes, como us-east4.

Hay varios motivos por los que se pueden producir picos temporales en este tipo de consultas:

• (Causa más habitual) Todas tus consultas similares y paralelas solicitan datos del mismo conjunto de nodos de Monarch, lo que consume una gran cantidad de memoria en cada nodo en conjunto. Cuando Monarch tiene suficientes recursos disponibles en una región de Cloud, tus consultas funcionan. Cuando Monarch está sometido a presión de recursos en una región de la nube, cada nodo limita las consultas y prioriza la limitación de los usuarios que consumen más memoria en cada nodo. Cuando Monarch vuelva a tener suficientes recursos, tus consultas volverán a funcionar. Estas consultas pueden ser SLIs que se generan automáticamente a partir de herramientas como Sloth.
• Los datos llegan tarde y las consultas no toleran esta situación. Los datos recién escritos tardan entre 3 y 7 segundos en poder consultarse, sin incluir la latencia de la red ni los retrasos causados por la presión de los recursos en tu entorno. Si tu consulta no incluye un retraso o un desfase para tener en cuenta los datos tardíos, es posible que, sin darte cuenta, consultes un periodo en el que solo tengas datos parciales. Una vez que llegan los datos, los resultados de la consulta tienen un aspecto normal.
• Monarch puede tener una ligera incoherencia al guardar tus datos en diferentes réplicas. El motor de consultas intenta elegir la réplica de "mejor calidad", pero si diferentes consultas eligen réplicas distintas con conjuntos de datos ligeramente diferentes, es posible que los resultados varíen ligeramente entre las consultas. Este es el comportamiento esperado del sistema y tus alertas deberían tolerar estas pequeñas discrepancias.
• Es posible que una región de Monarch completa no esté disponible temporalmente. Si no se puede acceder a una región, el motor de consultas la trata como si nunca hubiera existido. Una vez que la región esté disponible, los resultados de las consultas seguirán devolviendo los datos de esa región.

Para tener en cuenta estas posibles causas principales, debe asegurarse de que sus consultas, reglas y alertas sigan estas prácticas recomendadas:

• Combina reglas y alertas similares en una sola regla que agregue por etiquetas en lugar de tener reglas independientes para cada permutación de valores de etiqueta. Si se trata de reglas de alertas, puedes usar notificaciones basadas en etiquetas para dirigir las alertas de la regla agregada en lugar de configurar reglas de enrutamiento individuales para cada alerta.

  Por ejemplo, si tiene una etiqueta foo con los valores bar, baz y qux, en lugar de tener una regla independiente para cada valor de etiqueta (una con la consulta sum(metric{foo="bar"}), otra con la consulta sum(metric{foo="baz"}) y otra con la consulta sum(metric{foo="qux"})), puede tener una sola regla que agregue los datos de esa etiqueta y, opcionalmente, filtre los valores de etiqueta que le interesen (como sum by (foo) metric{foo=~"bar|baz|qux"}).

  Si tu métrica tiene dos etiquetas y cada etiqueta tiene 50 valores, y tienes una regla independiente para cada combinación de valores de etiqueta, y tus consultas de reglas son una proporción, en cada periodo lanzarás 50 x 50 x 2 = 5000 consultas paralelas de Monarch que se dirigen al mismo conjunto de nodos de Monarch. En conjunto, estas 5000 consultas paralelas consumen una gran cantidad de memoria en cada nodo de Monarch, lo que aumenta el riesgo de que se limite la velocidad cuando una región de Monarch esté sometida a presión de recursos.

  Si, en cambio, usas agregaciones para consolidar estas reglas en una sola regla que sea una proporción, en cada periodo solo lanzarás dos consultas paralelas de Monarch. Estas dos consultas paralelas consumen mucha menos memoria en conjunto que las 5000 consultas paralelas, y el riesgo de que se limite la velocidad es mucho menor.

• Si la regla tiene un periodo retrospectivo de más de un día, ejecútala con una frecuencia inferior a un minuto. Las consultas que acceden a datos de hace más de 25 horas se dirigen al repositorio de datos en disco de Monarch. Estas consultas de repositorio son más lentas y consumen más memoria que las consultas sobre datos más recientes, lo que agrava cualquier problema de consumo de memoria de las reglas de registro paralelas.

  Te recomendamos que ejecutes este tipo de consultas una vez cada hora en lugar de una vez por minuto. Si ejecutas una consulta de un día de duración cada minuto, solo obtendrás un cambio de 1/1440 = 0,07% en el resultado de cada periodo, lo que supone un cambio insignificante. Si ejecutas una consulta de un día cada hora, el resultado cambiará en un 60/1440 = 4% en cada periodo, lo que supone un tamaño de señal más relevante. Si necesitas recibir una alerta si cambian los datos recientes, puedes ejecutar una regla diferente con un periodo retrospectivo más corto (por ejemplo, 5 minutos) una vez por minuto.

• Usa el campo for: en tus reglas para tolerar resultados aberrantes transitorios. El campo for: impide que se active la alerta a menos que se haya cumplido la condición de la alerta durante al menos el periodo configurado. Asigna a este campo el doble de la longitud del intervalo de evaluación de reglas o un valor superior.

  El uso del campo for: es útil porque los problemas transitorios suelen resolverse solos, lo que significa que no se producen en ciclos de alertas consecutivos. Si ves un pico y este se mantiene en varias marcas de tiempo y ciclos de alerta, puedes tener más certeza de que se trata de un pico real y no de un problema transitorio.

• Usa el modificador offset en PromQL para retrasar la evaluación de tu consulta y que no se aplique al periodo de datos más reciente. Consulta el intervalo de muestreo y el intervalo de evaluación de reglas, e identifica el más largo de los dos. Lo ideal es que el desplazamiento de la consulta sea al menos el doble de la longitud del intervalo más largo. Por ejemplo, si envías datos cada 15 segundos y ejecutas reglas cada 30 segundos, desvía tus consultas al menos 1 minuto. Un desfase de 1 minuto hace que tus reglas usen una marca de tiempo final que tenga al menos 60 segundos de antigüedad, lo que crea un margen para que lleguen los datos tardíos antes de ejecutar la regla.

  Esta es una práctica recomendada de Cloud Monitoring (todas las alertas de PromQL gestionadas tienen al menos un desfase de 1 minuto) y una práctica recomendada de Prometheus.

• Agrupa los resultados por la etiqueta location para aislar los posibles problemas de regiones no disponibles. La etiqueta que tiene la Google Cloud regiónzone puede llamarse zone o region en algunas métricas del sistema.

  Si no agrupas por región y una región deja de estar disponible, parecerá que tus resultados se reducen de repente y es posible que también veas que los resultados históricos disminuyen. Si agrupa por región y una región deja de estar disponible, no recibirá ningún resultado de esa región, pero los resultados de otras regiones no se verán afectados.

• Si tu proporción es una proporción de éxito (como las respuestas 2xx sobre el total de respuestas), te recomendamos que la conviertas en una proporción de errores (como las respuestas 4xx y 5xx sobre el total de respuestas). Las ratios de error son más tolerantes a los datos incoherentes, ya que un descenso temporal de los datos hace que el resultado de la consulta sea inferior al umbral y, por lo tanto, no se active la alerta.

• Si es posible, desglosa una consulta de ratio o una regla de grabación en consultas de numerador y denominador independientes. Esta es una práctica recomendada de Prometheus. Usar ratios es válido, pero como la consulta del numerador se ejecuta de forma independiente de la consulta del denominador, usar ratios puede magnificar el impacto de los problemas transitorios:

  • Si Monarch limita la consulta del numerador, pero no la del denominador, es posible que obtengas resultados inesperadamente bajos. Si Monarch limita la consulta del denominador, pero no la del numerador, es posible que obtenga resultados inesperadamente altos.
  • Si consultas periodos recientes y tienes datos que llegan tarde, es posible que una consulta de la proporción se ejecute antes de que lleguen los datos y la otra consulta de la proporción se ejecute después de que lleguen los datos.
  • Si cualquiera de los lados de la proporción se compone de relativamente pocas series temporales, los errores se amplifican. Si el numerador y el denominador tienen 100 series temporales cada uno y Monarch no devuelve 1 serie temporal en la consulta del numerador, es probable que notes la diferencia del 1 %. Si el numerador y el denominador tienen 1.000.000 series temporales cada uno y Monarch no devuelve 1 serie temporal en la consulta del numerador, es poco probable que notes la diferencia del 0,0001 %.

• Si sus datos son dispersos, utilice una duración más larga en su consulta. Si tus datos llegan cada 10 minutos y tu consulta usa rate(metric[1m]), la consulta solo buscará datos de hace 1 minuto y, a veces, obtendrás resultados vacíos. Por norma general, configura el [duration] para que sea al menos 4 veces mayor que el intervalo de raspado.

  De forma predeterminada, las consultas de métricas de tipo Gauge buscan datos de los últimos 5 minutos. Para que se remonten más atrás, usa cualquier función x_over_time válida, como last_over_time.

Estas recomendaciones son relevantes sobre todo si observa resultados de consulta incoherentes al consultar datos recientes. Si observas que este problema se produce al consultar datos de hace más de 25 horas, puede que haya un problema técnico con Monarch. Si esto ocurre, ponte en contacto con Cloud Customer Care para que podamos investigar el problema.

Importar paneles de control de Grafana

Para obtener información sobre cómo usar el importador de paneles de control y solucionar problemas relacionados, consulta el artículo Importar paneles de control de Grafana a Cloud Monitoring.

Para obtener información sobre los problemas con la conversión del contenido del panel de control, consulta el archivo README del importador.

Problemas del lado de la ingestión

Los problemas del lado de la ingestión pueden estar relacionados con la recogida o con la evaluación de reglas. Empieza consultando los registros de errores de la recogida gestionada. Puedes ejecutar los siguientes comandos:

kubectl logs -f -n gmp-system -lapp.kubernetes.io/part-of=gmp

kubectl logs -f -n gmp-system -lapp.kubernetes.io/name=collector -c prometheus

En los clústeres de Autopilot de GKE, puedes ejecutar los siguientes comandos:

kubectl logs -f -n gke-gmp-system -lapp.kubernetes.io/part-of=gmp

kubectl logs -f -n gke-gmp-system -lapp.kubernetes.io/name=collector -c prometheus

La función de estado del objetivo puede ayudarte a depurar tu objetivo de raspado. Para obtener más información, consulta la información sobre el estado de los objetivos.

Falta el estado del endpoint o es demasiado antiguo

Si has habilitado la función de estado de destino, pero a uno o varios de tus recursos de PodMonitoring o ClusterPodMonitoring les falta el campo o el valor Status.Endpoint Statuses, es posible que tengas uno de los siguientes problemas:

• Managed Service para Prometheus no ha podido acceder a un recopilador en el mismo nodo que uno de sus endpoints.
• Una o varias de tus configuraciones de PodMonitoring o ClusterPodMonitoring no han dado como resultado ningún objetivo válido.

Problemas similares también pueden provocar que el campo Status.Endpoint Statuses.Last Update Time tenga un valor más antiguo que unos minutos más tu intervalo de raspado.

Para solucionar este problema, empieza por comprobar que los pods de Kubernetes asociados a tu endpoint de raspado se estén ejecutando. Si tus pods de Kubernetes están en ejecución, los selectores de etiquetas coinciden y puedes acceder manualmente a los endpoints de raspado (normalmente, visitando el endpoint /metrics), comprueba si los recopiladores de Managed Service para Prometheus están en ejecución.

La fracción de recolectores es inferior a 1

Si has habilitado la función de estado de destino, obtendrás información sobre el estado de tus recursos. El valor Status.Endpoint Statuses.Collectors Fraction de tus recursos de PodMonitoring o ClusterPodMonitoring representa la fracción de colectores, expresada de 0 a 1, a los que se puede acceder. Por ejemplo, el valor 0.5 indica que se puede contactar con el 50% de tus recolectores, mientras que el valor 1 indica que se puede contactar con el 100 %.

Si el campo Collectors Fraction tiene un valor distinto de 1, significa que no se puede acceder a uno o varios colectores y que es posible que no se estén recogiendo métricas de ninguno de esos nodos. Asegúrate de que todos los recolectores estén en ejecución y se pueda acceder a ellos a través de la red del clúster. Puedes ver el estado de los pods de recopilador con el siguiente comando:

kubectl -n gmp-system get pods --selector="app.kubernetes.io/name=collector"

En los clústeres de Autopilot de GKE, este comando tiene un aspecto ligeramente diferente:

kubectl -n gke-gmp-system get pods --selector="app.kubernetes.io/name=collector"

Puedes investigar pods de recopiladores concretos (por ejemplo, un pod de recopilador llamado collector-12345) con el siguiente comando:

kubectl -n gmp-system describe pods/collector-12345

En los clústeres de Autopilot de GKE, ejecuta el siguiente comando:

kubectl -n gke-gmp-system describe pods/collector-12345

Si los colectores no están en buen estado, consulta la sección Solución de problemas de cargas de trabajo de GKE.

Si los colectores están en buen estado, comprueba los registros del operador. Para consultar los registros del operador, primero ejecuta el siguiente comando para encontrar el nombre del pod del operador:

kubectl -n gmp-system get pods --selector="app.kubernetes.io/name=gmp-collector"

En los clústeres de Autopilot de GKE, ejecuta el siguiente comando:

kubectl -n gke-gmp-system get pods --selector="app.kubernetes.io/name=gmp-collector"

A continuación, comprueba los registros del operador (por ejemplo, un pod de operador llamado gmp-operator-12345) con el siguiente comando:

kubectl -n gmp-system logs pods/gmp-operator-12345

En los clústeres de Autopilot de GKE, ejecuta el siguiente comando:

kubectl -n gke-gmp-system logs pods/gmp-operator-12345

Objetivos en mal estado

Si ha habilitado la función de estado de destino, pero uno o varios de sus recursos PodMonitoring o ClusterPodMonitoring tienen el campo Status.Endpoint Statuses.Unhealthy Targets con un valor distinto de 0, significa que el recopilador no puede obtener datos de uno o varios de sus destinos.

Consulta el campo Sample Groups, que agrupa los destinos por mensaje de error, y busca el campo Last Error. El campo Last Error procede de Prometheus y te indica por qué no se ha podido obtener información del destino. Para solucionar este problema, usa los objetivos de ejemplo como referencia y comprueba si tus endpoints de raspado están en funcionamiento.

Endpoint de raspado no autorizado

Si ve uno de los siguientes errores y su destino de raspado requiere autorización, significa que su recolector no está configurado para usar el tipo de autorización correcto o que está usando la carga útil de autorización incorrecta:

• server returned HTTP status 401 Unauthorized
• x509: certificate signed by unknown authority

Para solucionar este problema, consulte Configurar un endpoint de raspado autorizado.

Se ha superado la cuota

Si ves el siguiente error, significa que has superado tu cuota de ingestión de la API Cloud Monitoring:

• "429: Se ha superado la cuota de la métrica 'Solicitudes de ingestión de series temporales' y el límite 'Solicitudes de ingestión de series temporales por minuto' del servicio 'monitoring.googleapis.com' para el consumidor 'project_number:PROJECT_NUMBER'., rateLimitExceeded"

Este error se produce con más frecuencia cuando se inicia el servicio gestionado por primera vez. La cuota predeterminada se agota al ingerir 100.000 muestras por segundo.

Para solucionar este problema, envíe una solicitud para aumentar su cuota de ingestión de la API Monitoring. Para obtener ayuda, ponte en contacto con el Google Cloud servicio de asistencia. Para obtener más información sobre las cuotas, consulta la documentación de Cloud Quotas.

Falta un permiso en la cuenta de servicio predeterminada del nodo

Si aparece uno de los siguientes errores, es posible que la cuenta de servicio predeterminada del nodo no tenga los permisos necesarios:

• "execute query: Error querying Prometheus: client_error: client error: 403" ("ejecutar consulta: error al consultar Prometheus: client_error: error de cliente: 403")
• "Readiness probe failed: HTTP probe failed with statuscode: 503" ("La comprobación de disponibilidad ha fallado: la comprobación HTTP ha fallado con el código de estado 503")
• "Error al consultar la instancia de Prometheus"

La recogida gestionada y el evaluador de reglas gestionado de Managed Service para Prometheus usan la cuenta de servicio predeterminada del nodo. Esta cuenta se crea con todos los permisos necesarios, pero a veces los clientes quitan manualmente los permisos de monitorización. Esta eliminación provoca que fallen la recogida y la evaluación de reglas.

Para verificar los permisos de la cuenta de servicio, haz una de las siguientes acciones:

• Identifica el nombre del nodo de Compute Engine subyacente y, a continuación, ejecuta el siguiente comando:

  gcloud compute instances describe NODE_NAME --format="json" | jq .serviceAccounts
  

  Busca la cadena https://www.googleapis.com/auth/monitoring. Si es necesario, añade la monitorización tal como se describe en Cuenta de servicio mal configurada.

• Ve a la VM subyacente del clúster y comprueba la configuración de la cuenta de servicio del nodo:

  1. En la Google Cloud consola, ve a la página Clústeres de Kubernetes:

     Ve a Clústeres de Kubernetes.

     Si usas la barra de búsqueda para encontrar esta página, selecciona el resultado cuyo subtítulo sea Kubernetes Engine.

  2. Selecciona Nodos y, a continuación, haz clic en el nombre del nodo de la tabla Nodos.

  3. Haz clic en Detalles.

  4. Haz clic en el enlace Instancia de VM.

  5. Busca el panel Gestión de APIs e identidades y haz clic en Mostrar detalles.

  6. Busca la API de Stackdriver Monitoring con acceso completo.

También es posible que el sincronizador de fuentes de datos o la interfaz de usuario de Prometheus se hayan configurado para buscar en el proyecto incorrecto. Para obtener información sobre cómo verificar que está consultando el ámbito de métricas previsto, consulte Cambiar el proyecto consultado.

Cuenta de servicio mal configurada

Si ves uno de los siguientes mensajes de error, significa que la cuenta de servicio que usa el recopilador no tiene los permisos correctos:

• "code = PermissionDenied desc = Permission monitoring.timeSeries.create denied (or the resource may not exist)" ("code = PermissionDenied desc = Permiso monitoring.timeSeries.create denegado (o puede que el recurso no exista)")
• "google: no se han encontrado las credenciales predeterminadas. Consulte más información en https://developers.google.com/accounts/docs/application-default-credentials."

Para verificar que tu cuenta de servicio tiene los permisos correctos, haz lo siguiente:

1. En la Google Cloud consola, ve a la página Gestión de identidades y accesos:

   Ve a Gestión de identidades y accesos.

   Si usas la barra de búsqueda para encontrar esta página, selecciona el resultado cuyo subtítulo sea IAM y administrador.

2. Identifica el nombre de la cuenta de servicio en la lista de principales. Verifica que el nombre de la cuenta de servicio esté escrito correctamente. A continuación, haz clic en edit Editar.

3. Selecciona el campo Rol y, a continuación, haz clic en Usado actualmente y busca el rol Escritor de métricas de monitorización o Editor de monitorización. Si la cuenta de servicio no tiene uno de estos roles, concédele el rol Escritor de métricas de Monitoring (roles/monitoring.metricWriter).

Si se ejecuta en Kubernetes que no es de GKE, debe transferir explícitamente las credenciales tanto al recolector como al evaluador de reglas. Debes repetir las credenciales en las secciones rules y collection. Para obtener más información, consulta Proporcionar credenciales explícitamente (para colecciones) o Proporcionar credenciales explícitamente (para reglas).

Las cuentas de servicio suelen limitarse a un solo Google Cloud proyecto. Si se usa una cuenta de servicio para escribir datos de métricas de varios proyectos (por ejemplo, cuando un evaluador de reglas gestionado consulta un ámbito de métricas de varios proyectos), se puede producir este error de permiso. Si usas la cuenta de servicio predeterminada, te recomendamos que configures una cuenta de servicio específica para poder añadir el permiso monitoring.timeSeries.create de forma segura a varios proyectos. Si no puede conceder este permiso, puede usar el cambio de nombre de métricas para cambiar el nombre de la etiqueta project_id. El ID de proyecto se asigna de forma predeterminada al proyecto en el que se ejecuta tu servidor de Prometheus o tu evaluador de reglas. Google Cloud

Configuración de raspado no válida

Si ves el siguiente error, significa que tu PodMonitoring o ClusterPodMonitoring no tiene el formato adecuado:

• "Se ha producido un error interno: no se ha podido llamar al webhook "validate.podmonitorings.gmp-operator.gmp-system.monitoring.googleapis.com": Post "https://gmp-operator.gmp-system.svc:443/validate/monitoring.googleapis.com/v1/podmonitorings?timeout=10s": EOF""

Para solucionar este problema, asegúrate de que el recurso personalizado tenga el formato correcto según la especificación.

El webhook de admisión no puede analizar o la configuración del cliente HTTP no es válida

En versiones de Managed Service para Prometheus anteriores a la 0.12, es posible que veas un error similar al siguiente, que está relacionado con la inyección de secretos en el espacio de nombres no predeterminado:

• "admission webhook "validate.podmonitorings.gmp-operator.gmp-system.monitoring.googleapis.com" denied the request: invalid definition for endpoint with index 0: unable to parse or invalid Prometheus HTTP client config: must use namespace "my-custom-namespace", got: "default"" ("webhook de admisión "validate.podmonitorings.gmp-operator.gmp-system.monitoring.googleapis.com" ha denegado la solicitud: definición no válida para el endpoint con índice 0: no se puede analizar o configuración no válida del cliente HTTP de Prometheus: debe usar el espacio de nombres "my-custom-namespace", se ha obtenido: "default"")

Para solucionar este problema, actualiza a la versión 0.12 o a una posterior.

Problemas con los intervalos de raspado y los tiempos de espera

Cuando se usa Managed Service para Prometheus, el tiempo de espera de extracción no puede ser superior al intervalo de extracción. Para comprobar los registros de este problema, ejecuta el siguiente comando:

kubectl -n gmp-system logs ds/collector prometheus

En los clústeres de Autopilot de GKE, ejecuta el siguiente comando:

kubectl -n gke-gmp-system logs ds/collector prometheus

Busca este mensaje:

• "El tiempo de espera de raspado es superior al intervalo de raspado de la configuración de raspado con nombre de trabajo "PodMonitoring/gmp-system/example-app/go-metrics""

Para solucionar este problema, asigne al valor del intervalo de raspado un valor igual o superior al del tiempo de espera de raspado.

Falta el atributo TYPE en la métrica

Si aparece el siguiente error, significa que falta información sobre el tipo de métrica:

• "no se han encontrado metadatos para el nombre de métrica "{metric_name}""

Para verificar que el problema es la falta de información de tipo, comprueba la /metrics salida de la aplicación de exportación. Si no hay ninguna línea como la siguiente, significa que falta la información del tipo:

# TYPE {metric_name} <type>

Algunas bibliotecas, como las de VictoriaMetrics anteriores a la versión 1.28.0, eliminan intencionadamente la información de tipo. Estas bibliotecas no son compatibles con Managed Service para Prometheus.

Colisiones de series temporales

Si ves uno de los siguientes errores, es posible que tengas más de un recopilador que intente escribir en la misma serie temporal:

• "No se han podido escribir una o varias series temporales: se han escrito uno o varios puntos con una frecuencia superior al periodo de muestreo máximo configurado para la métrica".
• "No se han podido escribir una o varias series temporales: los puntos deben escribirse en orden. Uno o varios de los puntos especificados tenían una hora de finalización anterior a la del punto más reciente."

A continuación se indican las causas y las soluciones más habituales:

• Usar pares de alta disponibilidad. Managed Service para Prometheus no admite la recogida de alta disponibilidad tradicional. Si usa esta configuración, puede crear varios recolectores que intenten escribir datos en la misma serie temporal, lo que provoca este error.

  Para resolver el problema, inhabilita los recolectores duplicados reduciendo el número de réplicas a 1 o usa el método de alta disponibilidad admitido.

• Usar reglas de cambio de etiqueta, sobre todo las que se aplican a trabajos o instancias. Managed Service para Prometheus identifica parcialmente una serie temporal única mediante la combinación de las etiquetas {project_id, location, cluster, namespace, job, instance}. Si usa una regla de cambio de etiqueta para eliminar estas etiquetas, especialmente las etiquetas job y instance, se pueden producir colisiones con frecuencia. No se recomienda reescribir estas etiquetas.

  Para resolver el problema, elimina la regla que lo provoca. Para ello, a menudo puedes usar la metricRelabeling regla que utiliza la acción labeldrop. Para identificar la regla que da problemas, puedes comentar todas las reglas de cambio de etiqueta y, a continuación, volver a añadirlas una a una hasta que se produzca el error.

Una causa menos habitual de las colisiones de series temporales es usar un intervalo de raspado inferior a 5 segundos. El intervalo de raspado mínimo admitido por el servicio gestionado de Prometheus es de 5 segundos.

Superar el límite de etiquetas

Si ves el siguiente error, es posible que hayas definido demasiadas etiquetas para una de tus métricas:

• "No se han podido escribir una o varias series temporales: las nuevas etiquetas harían que la métrica prometheus.googleapis.com/METRIC_NAME tuviera más de PER_PROJECT_LIMIT etiquetas".

Este error suele producirse cuando cambias rápidamente la definición de la métrica, de modo que un nombre de métrica tiene varios conjuntos independientes de claves de etiqueta durante toda la vida útil de la métrica. Cloud Monitoring impone un límite en el número de etiquetas de cada métrica. Para obtener más información, consulta los límites de las métricas definidas por el usuario.

Para resolver este problema, sigue estos tres pasos:

1. Identificar por qué una métrica determinada tiene demasiadas etiquetas o etiquetas que cambian con frecuencia.

   • Puedes usar el widget Explorador de APIs en la página metricDescriptors.list para llamar al método. Para obtener más información, consulta el Explorador de APIs. Para ver ejemplos, consulta List metric and resource types (Listar métricas y tipos de recursos).

2. Aborda la causa del problema, lo que puede implicar ajustar las reglas de cambio de etiqueta de PodMonitoring, cambiar el exportador o corregir la instrumentación.

3. Elimina el descriptor de métrica de esta métrica (lo que conlleva la pérdida de datos) para que se pueda volver a crear con un conjunto de etiquetas más pequeño y estable. Para ello, puedes usar el método metricDescriptors.delete.

Las fuentes más habituales del problema son las siguientes:

• Recoger métricas de exportadores o aplicaciones que adjuntan etiquetas dinámicas a las métricas. Por ejemplo, cAdvisor autodesplegado con etiquetas de contenedor y variables de entorno adicionales o el agente de DataDog, que inserta anotaciones dinámicas.

  Para solucionar este problema, puedes usar una sección metricRelabeling en PodMonitoring para conservar o eliminar etiquetas. Algunas aplicaciones y exportadores también permiten configurar los cambios en las métricas exportadas. Por ejemplo, cAdvisor tiene varios ajustes avanzados de tiempo de ejecución que pueden añadir etiquetas de forma dinámica. Cuando se usa la recogida gestionada, recomendamos usar la recogida kubelet automática integrada.

• Usar reglas de cambio de etiqueta, sobre todo las que asignan nombres de etiqueta de forma dinámica, lo que puede provocar que haya un número inesperado de etiquetas.

  Para solucionar el problema, elimine la entrada de la regla que lo provoca.

Límites de frecuencia para crear y actualizar métricas y etiquetas

Si ve el siguiente error, significa que ha alcanzado el límite de frecuencia por minuto para crear métricas y añadir etiquetas de métricas a métricas ya creadas:

• "Solicitud limitada. Has alcanzado el límite por proyecto de cambios en la definición de métricas o de etiquetas por minuto."

Este límite de frecuencia solo se suele alcanzar cuando se integra por primera vez con Managed Service para Prometheus. Por ejemplo, cuando migras una implementación de Prometheus antigua a la recogida autodesplegada. No se trata de un límite de frecuencia para ingerir puntos de datos. Este límite de frecuencia solo se aplica cuando se crean métricas que no se han visto nunca o cuando se añaden etiquetas nuevas a métricas ya creadas.

Esta cuota es fija, pero los problemas deberían resolverse automáticamente a medida que se creen nuevas métricas y etiquetas de métricas hasta alcanzar el límite por minuto.

Límites en el número de descriptores de métricas

Si ves el siguiente error, significa que has alcanzado el límite de cuota del número de descriptores de métricas de un soloGoogle Cloud proyecto:

• "Se ha agotado la cuota de descriptores de métricas".

De forma predeterminada, este límite es de 25.000. Aunque esta cuota se puede aumentar si tus métricas están bien formadas, es mucho más probable que alcances este límite porque estás ingiriendo nombres de métricas mal formados en el sistema.

Prometheus tiene un modelo de datos dimensional en el que la información, como el nombre del clúster o del espacio de nombres, debe codificarse como un valor de etiqueta. Si la información dimensional se inserta en el nombre de la métrica, el número de descriptores de métricas aumenta indefinidamente. Además, como en este caso las etiquetas no se usan correctamente, resulta mucho más difícil consultar y agregar datos en clústeres, espacios de nombres o servicios.

Ni Cloud Monitoring ni Managed Service para Prometheus admiten métricas no dimensionales, como las que tienen el formato de StatsD o Graphite. Aunque la mayoría de los exportadores de Prometheus están configurados correctamente de forma predeterminada, algunos exportadores, como el exportador de StatsD, el exportador de Vault o el proxy de Envoy que viene con Istio, deben configurarse explícitamente para usar etiquetas en lugar de insertar información en el nombre de la métrica. Estos son algunos ejemplos de nombres de métricas con formato incorrecto:

• request_path_____path_to_a_resource____istio_request_duration_milliseconds
• envoy_cluster_grpc_method_name_failure
• envoy_cluster_clustername_upstream_cx_connect_ms_bucket
• vault_rollback_attempt_path_name_1700683024
• service__________________________________________latency_bucket

Para confirmar este problema, sigue estos pasos:

1. En la Google Cloud consola, selecciona el Google Cloud proyecto vinculado al error.

2. En la Google Cloud consola, ve a la página query_stats Gestión de métricas:

   Ve a Gestión de métricas.

   Si usas la barra de búsqueda para encontrar esta página, selecciona el resultado cuya sección sea Monitorización.

3. Confirme que la suma de las métricas Activas e Inactivas es superior a 25.000. En la mayoría de los casos, deberías ver un gran número de métricas Inactivas.
4. Selecciona "Inactivo" en el panel Filtros rápidos, desplázate por la lista y busca patrones.
5. Seleccione "Activo" en el panel Filtros rápidos, ordene la lista por Volumen facturable de muestras de forma descendente, desplácese por la lista y busque patrones.
6. Ordena la lista por Volumen facturable de muestras de forma ascendente, desplázate por ella y busca patrones.

También puede confirmar este problema con el explorador de métricas:

1. En la Google Cloud consola, selecciona el Google Cloud proyecto vinculado al error.

2. En la Google Cloud consola, ve a la página leaderboard Explorador de métricas:

   Ve al explorador de métricas.

   Si usas la barra de búsqueda para encontrar esta página, selecciona el resultado cuya sección sea Monitorización.

3. En el creador de consultas, haga clic en Seleccionar una métrica y, a continuación, desmarque la casilla "Activa".
4. Escribe "prometheus" en la barra de búsqueda.
5. Busca patrones en los nombres de las métricas.

Una vez que haya identificado los patrones que indican que las métricas están mal formadas, puede mitigar el problema corrigiendo el exportador en la fuente y, a continuación, eliminando los descriptores de métricas incorrectos.

Para evitar que vuelva a ocurrir, primero debe configurar el exportador correspondiente para que deje de emitir métricas con formato incorrecto. Te recomendamos que consultes la documentación de tu exportador para obtener ayuda. Para confirmar que has solucionado el problema, visita manualmente el endpoint /metrics e inspecciona los nombres de las métricas exportadas.

A continuación, puedes liberar tu cuota eliminando las métricas con formato incorrecto mediante el projects.metricDescriptors.delete método. Para iterar más fácilmente en la lista de métricas con formato incorrecto, te proporcionamos una secuencia de comandos de Golang que puedes usar. Esta secuencia de comandos acepta una expresión regular que puede identificar las métricas con formato incorrecto y elimina los descriptores de métricas que coincidan con el patrón. Como la eliminación de métricas es irreversible, le recomendamos que ejecute primero la secuencia de comandos en el modo de prueba.

Faltan algunas métricas de los objetivos de corta duración

Google Cloud Managed Service para Prometheus se ha implementado y no hay errores de configuración, pero faltan algunas métricas.

Determina la implementación que genera las métricas que faltan parcialmente. Si la implementación es un CronJob de Google Kubernetes Engine, determina cuánto tiempo suele ejecutarse el trabajo:

1. Busca el archivo YAML de implementación del trabajo cron y el estado, que es list al final del archivo. El estado de este ejemplo muestra que la tarea se ha ejecutado durante un minuto:

     status:
       lastScheduleTime: "2024-04-03T16:20:00Z"
       lastSuccessfulTime: "2024-04-03T16:21:07Z"
   

2. Si el tiempo de ejecución es inferior a cinco minutos, el trabajo no se está ejecutando el tiempo suficiente para que los datos de las métricas se recojan de forma coherente.

   Para solucionar este problema, prueba lo siguiente:

   • Configura el trabajo para que no finalice hasta que hayan transcurrido al menos cinco minutos desde que se inició.

   • Configura el trabajo para detectar si se han recogido métricas antes de salir. Esta función requiere compatibilidad con bibliotecas.

   • Te recomendamos que crees una métrica basada en registros con valores de distribución en lugar de recoger datos de métricas. Este enfoque se recomienda cuando los datos se publican a una frecuencia baja. Para obtener más información, consulta el artículo sobre métricas basadas en registros.

3. Si el tiempo de ejecución es superior a cinco minutos o no es constante, consulta la sección Objetivos no saludables de este documento.

Problemas con la recogida de exportadores

Si no se están ingiriendo las métricas de un exportador, comprueba lo siguiente:

• Comprueba que el exportador funciona y exporta métricas mediante el comando kubectl port-forward.

  Por ejemplo, para comprobar que los pods con el selector app.kubernetes.io/name=redis en el espacio de nombres test emiten métricas en el endpoint /metrics en el puerto 9121, puede reenviar el puerto de la siguiente manera:

  kubectl port-forward "$(kubectl get pods -l app.kubernetes.io/name=redis -n test -o jsonpath='{.items[0].metadata.name}')" 9121
  

  Accede al endpoint localhost:9121/metrics mediante el navegador o curl en otra sesión de terminal para verificar que el exportador expone las métricas para el raspado.

• Comprueba si puedes consultar las métricas en la Google Cloud consola, pero no en Grafana. Si es así, el problema es de Grafana, no de la recogida de métricas.

• Verifica que el recolector gestionado pueda raspar el exportador inspeccionando la interfaz web de Prometheus que expone el recolector.

  1. Identifica el recolector gestionado que se ejecuta en el mismo nodo en el que se ejecuta tu exportador. Por ejemplo, si el exportador se ejecuta en pods del espacio de nombres test y los pods tienen la etiqueta app.kubernetes.io/name=redis, el siguiente comando identifica el recolector gestionado que se ejecuta en el mismo nodo:

     kubectl get pods -l app=managed-prometheus-collector --field-selector="spec.nodeName=$(kubectl get pods -l app.kubernetes.io/name=redis -n test -o jsonpath='{.items[0].spec.nodeName}')" -n gmp-system -o jsonpath='{.items[0].metadata.name}'
     

  2. Configura la redirección de puertos desde el puerto 19090 del recolector gestionado:

     kubectl port-forward POD_NAME -n gmp-system 19090
     

  3. Ve a la URL localhost:19090/targets para acceder a la interfaz web. Si el exportador aparece en la lista de destinos, significa que tu recopilador gestionado está obteniendo datos del exportador correctamente.

Errores de falta de memoria (OOM) del recopilador

Si utilizas la recogida gestionada y se producen errores de falta de memoria (OOM) en tus recopiladores, te recomendamos que habilites el autoescalado vertical de pods.

Errores de falta de memoria del operador

Si usas la colección gestionada y se producen errores de falta de memoria en tu operador, te recomendamos que inhabilites la función de estado de destino. La función de estado de destino puede provocar problemas de rendimiento del operador en clústeres más grandes.

Demasiadas series temporales o un aumento de las respuestas 503 y de los errores de tiempo de espera agotado del contexto, sobre todo durante los picos de carga

También es posible que tengas este problema si ves el siguiente mensaje de error:

• "El recurso monitorizado (abcdefg) tiene demasiadas series temporales (métricas de Prometheus)"

"Context deadline exceeded" es un error 503 genérico que devuelve Monarch cuando se produce un problema en el lado de la ingestión que no tiene una causa específica. Es normal que se produzca un número muy reducido de errores "context deadline exceeded" (se ha superado el plazo del contexto) al usar el sistema con normalidad.

Sin embargo, puede que observes un patrón en el que los errores "context deadline exceeded" aumenten y afecten significativamente a la ingesta de datos. Una posible causa principal es que puede que estés configurando las etiquetas de destino de forma incorrecta. Es más probable que esto ocurra si se cumplen las siguientes condiciones:

• Los errores "Context deadline exceeded" siguen un patrón cíclico, ya que aumentan durante los periodos de carga elevada para ti o para la región especificada en la etiqueta location. Google Cloud
• Verás más errores a medida que incorpores más volumen de métricas al servicio.
• Estás usando el statsd_exporter para Prometheus, Envoy para Istio, el exportador SNMP, Prometheus Pushgateway o kube-state-metrics, o bien tienes un exportador similar que intermedia y genera informes de métricas en nombre de otros recursos que se ejecutan en tu entorno. El problema solo se produce en las métricas emitidas por este tipo de exportador.
• Observa que las métricas afectadas suelen tener la cadena localhost en el valor de la etiqueta instance o que hay muy pocos valores para la etiqueta instance.
• Si tienes acceso a la interfaz de usuario de consulta del recopilador de Prometheus en el clúster, puedes ver que las métricas se están recogiendo correctamente.

Si se cumplen estos puntos, es probable que el exportador haya configurado incorrectamente las etiquetas de recursos de forma que entren en conflicto con los requisitos de Monarch.

Monarch se escala almacenando los datos relacionados en un destino. Un destino de Managed Service for Prometheus se define mediante el tipo de recurso prometheus_target y las etiquetas project_id, location, cluster, namespace, job y instance. Para obtener más información sobre estas etiquetas y el comportamiento predeterminado, consulte Etiquetas reservadas en la colección gestionada o Etiquetas reservadas en la colección autodesplegada.

De estas etiquetas, instance es el campo de destino de nivel más bajo y, por lo tanto, es el más importante. Para almacenar y consultar métricas de forma eficiente en Monarch, se necesitan objetivos relativamente pequeños y diversos, idealmente del tamaño de una máquina virtual o un contenedor típicos. Cuando se ejecuta Managed Service para Prometheus en situaciones típicas, el comportamiento predeterminado de código abierto integrado en el recolector suele elegir valores adecuados para las etiquetas job y instance, por lo que este tema no se trata en otras partes de la documentación.

Sin embargo, la lógica predeterminada puede fallar cuando ejecutas un exportador que informa de métricas en nombre de otros recursos de tu clúster, como statsd_exporter. En lugar de asignar a instance el valor IP:puerto del recurso que emite la métrica, se le asigna el valor IP:puerto del propio statsd_exporter.instance El problema puede agravarse con la etiqueta job, ya que, en lugar de estar relacionada con el paquete o el servicio de métricas, también carece de diversidad al estar definida como statsd-exporter.

Cuando esto ocurre, todas las métricas que proceden de este exportador en un clúster y un espacio de nombres determinados se escriben en el mismo destino de Monarch. A medida que este objetivo aumenta, las escrituras empiezan a fallar y se producen más errores 503 "Context deadline exceeded" (Se ha superado el plazo del contexto).

Para verificar que esto te está ocurriendo, ponte en contacto con el servicio de atención al cliente de Cloud y pídele que consulte los registros de hospitalización de Monarch Quarantiner. Incluye los valores que conozcas de las seis etiquetas reservadas en tu entrada. Asegúrese de informar del Google Cloud proyecto que envía los datos, no del Google Cloud proyecto de su ámbito de métricas.

Para solucionar este problema, debe cambiar su canalización de recogida para usar etiquetas de destino más diversas. Estas son algunas estrategias posibles, ordenadas de mayor a menor eficacia:

• En lugar de ejecutar un exportador central que informe de las métricas en nombre de todas las VMs o nodos, ejecuta un exportador independiente para cada VM como agente de nodo o implementando el exportador como un DaemonSet de Kubernetes. Para evitar que se asigne la etiqueta instance a localhost, no ejecutes el exportador en el mismo nodo que el recopilador.
  • Si, después de fragmentar el exportador, sigues necesitando más diversidad de destino, ejecuta varios exportadores en cada VM y asigna lógicamente diferentes conjuntos de métricas a cada exportador. Después, en lugar de detectar el trabajo con el nombre estático statsd-exporter, usa un nombre de trabajo diferente para cada conjunto lógico de métricas. Las instancias con valores diferentes de job se asignan a diferentes objetivos en Monarch.
  • Si usas kube-state-metrics, utiliza el shard horizontal integrado para crear más diversidad de destinos. Otros exportadores pueden tener funciones similares.
• Si usas OpenTelemetry o una recopilación autodesplegada, usa una regla de reetiquetado para cambiar el valor de instance del nombre o la IP:puerto del exportador al nombre único o la IP:puerto del recurso que genera las métricas. Es muy probable que ya estés registrando la IP:puerto o el nombre del recurso de origen como etiqueta de métrica. También debes definir el campo honor_labels como true en tu configuración de Prometheus u OpenTelemetry.
• Si usas OpenTelemetry o una colección autodesplegada, utiliza una regla de reetiquetado con una función hashmod para ejecutar varios trabajos de raspado en el mismo exportador y asegúrate de que se elija una etiqueta de instancia diferente para cada configuración de raspado.

No hay errores ni métricas

Si utiliza la recogida gestionada y no ve ningún error, pero los datos no aparecen en Cloud Monitoring, lo más probable es que los exportadores de métricas o las configuraciones de raspado no estén configurados correctamente. Managed Service para Prometheus no envía ningún dato de serie temporal a menos que apliques primero una configuración de recogida válida.

Para determinar si esta es la causa, prueba a desplegar la aplicación de ejemplo y el recurso PodMonitoring de ejemplo. Si ahora ves la métrica up (puede tardar unos minutos), el problema está en la configuración de extracción o en el exportador.

La causa raíz puede ser cualquiera. Te recomendamos que compruebes lo siguiente:

• Tu PodMonitoring hace referencia a un puerto válido.

• La especificación de implementación de tu exportador tiene puertos con nombres adecuados.

• Los selectores (normalmente app) coinciden con los recursos Deployment y PodMonitoring.

• Puede ver los datos en el endpoint y el puerto esperados visitándolos manualmente.

• Has instalado el recurso PodMonitoring en el mismo espacio de nombres que la aplicación que quieres monitorizar. No instales recursos personalizados ni aplicaciones en los espacios de nombres gmp-system o gke-gmp-system.

• Los nombres de las métricas y las etiquetas coinciden con la expresión regular válida de Prometheus. Managed Service para Prometheus no admite nombres de etiquetas que empiecen por el carácter _.

• No está usando un conjunto de filtros que provoque que se filtren todos los datos. Ten mucho cuidado de no tener filtros contradictorios al usar un filtro collection en el recurso OperatorConfig.

• Si se ejecuta fuera de Google Cloud, project o project-id se asigna a un proyecto Google Cloud válido y location se asigna a una región Google Cloud válida. No puedes usar global como valor de location.

• Tu métrica es uno de los cuatro tipos de métricas de Prometheus. Algunas bibliotecas, como Kube State Metrics, exponen tipos de métricas de OpenMetrics, como Info, Stateset y GaugeHistogram, pero Managed Service para Prometheus no admite estos tipos de métricas, por lo que se descartan de forma silenciosa.

Cortafuegos

Un cortafuegos puede provocar problemas tanto de ingestión como de consulta. Tu firewall debe configurarse para permitir las solicitudes POST y GET al servicio de la API Monitoring, monitoring.googleapis.com, para permitir la ingestión y las consultas.

Error sobre las ediciones simultáneas

El mensaje de error "Demasiadas ediciones simultáneas en la configuración del proyecto" suele ser temporal y se resuelve al cabo de unos minutos. Normalmente, se debe a la eliminación de una regla de cambio de etiqueta que afecta a muchas métricas diferentes. La eliminación provoca la formación de una cola de actualizaciones de los descriptores de métricas de tu proyecto. El error desaparece cuando se procesa la cola.

Para obtener más información, consulta Límites para crear y actualizar métricas y etiquetas.

Consultas bloqueadas y canceladas por Monarch

Si aparece el siguiente error, significa que has alcanzado el límite interno del número de consultas simultáneas que se pueden ejecutar en un proyecto determinado:

• "internal: expanding series: generic::aborted: invalid status monarch::220: Cancelled due to the number of queries whose evaluation is blocked waiting for memory is 501, which is equal to or greater than the limit of 500." ("internal: expanding series: generic::aborted: invalid status monarch::220: Cancelled due to the number of queries whose evaluation is blocked waiting for memory is 501, which is equal to or greater than the limit of 500.")

Para evitar abusos, el sistema aplica un límite estricto al número de consultas de un proyecto que se pueden ejecutar simultáneamente en Monarch. Con un uso típico de Prometheus, las consultas deberían ser rápidas y este límite nunca debería alcanzarse.

Es posible que alcances este límite si envías muchas consultas simultáneas que se ejecutan durante más tiempo del esperado. Las consultas que solicitan más de 25 horas de datos suelen tardar más en ejecutarse que las que solicitan menos de 25 horas de datos. Además, cuanto mayor sea el periodo de retrospectiva de la consulta, más tiempo tardará en ejecutarse.

Normalmente, este problema se produce cuando se ejecutan muchas reglas de retrospectiva larga de forma ineficiente. Por ejemplo, puede tener muchas reglas que se ejecuten una vez por minuto y soliciten una tarifa de 4 semanas. Si cada una de estas reglas tarda mucho en ejecutarse, es posible que se acumulen consultas en espera de ejecutarse en tu proyecto, lo que provocará que Monarch limite las consultas.

Para solucionar este problema, debe aumentar el intervalo de evaluación de sus reglas de retrospectiva larga para que no se ejecuten cada minuto. No es necesario ejecutar una consulta para obtener la tasa de las últimas cuatro semanas cada minuto. Hay 40.320 minutos en cuatro semanas, por lo que cada minuto apenas te aporta información adicional (tus datos cambian como máximo en 1/40.320). Un intervalo de evaluación de 1 hora debería ser suficiente para una consulta que solicite una tarifa de 4 semanas.

Una vez que resuelvas el cuello de botella causado por consultas largas ineficientes que se ejecutan con demasiada frecuencia, este problema debería solucionarse solo.

Tipos de valores incompatibles

Si ves el siguiente error al ingerir datos o al hacer una consulta, significa que hay una incompatibilidad de tipo de valor en tus métricas:

• "El tipo de valor de la métrica prometheus.googleapis.com/metric_name/gauge debe ser INT64, pero es DOUBLE"
• "El tipo de valor de la métrica prometheus.googleapis.com/metric_name/gauge debe ser DOUBLE, pero es INT64"
• "No se han podido escribir una o varias series temporales: el tipo de valor de la métrica prometheus.googleapis.com/target_info/gauge está en conflicto con el tipo de valor existente (INT64)"

Es posible que veas este error durante la ingestión, ya que Monarch no admite la escritura de datos de tipo DOUBLE en métricas de tipo INT64 ni la escritura de datos de tipo INT64 en métricas de tipo DOUBLE. También puede aparecer este error al consultar con un ámbito de métricas de varios proyectos, ya que Monarch no puede combinar métricas de tipo DOUBLE de un proyecto con métricas de tipo INT64 de otro proyecto.

Este error solo se produce cuando hay colectores de OpenTelemetry que envían datos y es más probable que se produzca si tiene tanto OpenTelemetry (con el exportador googlemanagedprometheus) como Prometheus enviando datos de la misma métrica, como suele ocurrir con la métrica target_info.

Lo más probable es que se deba a uno de los siguientes motivos:

• Está recogiendo métricas de OTLP y la biblioteca de métricas de OTLP ha cambiado su tipo de valor de DOUBLE a INT64, como ha ocurrido con las métricas de Java de OpenTelemetry. La nueva versión de la biblioteca de métricas ahora es incompatible con el tipo de valor de métrica creado por la versión antigua de la biblioteca de métricas.
• Estás recogiendo la métrica target_info con Prometheus y OpenTelemetry. Prometheus recoge esta métrica como DOUBLE, mientras que OpenTelemetry lo hace como INT64. Ahora, tus colectores escriben dos tipos de valores en la misma métrica del mismo proyecto y solo el colector que creó el descriptor de métrica en primer lugar tiene éxito.
• Estás recogiendo target_info con OpenTelemetry como INT64 en un proyecto y target_info con Prometheus como DOUBLE en otro proyecto. Si se añaden ambas métricas al mismo ámbito de métricas y, a continuación, se consulta esa métrica a través del ámbito de métricas, se produce una unión no válida entre tipos de valores de métricas incompatibles.

Este problema se puede solucionar forzando que todos los tipos de valores de métricas sean DOUBLE. Para ello, haz lo siguiente:

1. Vuelve a configurar tus colectores de OpenTelemetry para que todas las métricas sean DOUBLE. Para ello, habilita la opción exporter.googlemanagedprometheus.intToDouble feature-gate.
2. Elimina todos los descriptores de métricas INT64 y deja que se vuelvan a crear como DOUBLE. Puedes usar la delete_metric_descriptors.go secuencia de comandos para automatizar este proceso.

Si sigues estos pasos, se eliminarán todos los datos almacenados como métrica INT64. No hay ninguna alternativa a la eliminación de las métricas INT64 que resuelva por completo este problema.