Solución de problemas de Managed Service para Prometheus

En este documento, se describen algunos problemas que puedes encontrar cuando usas Google Cloud Managed Service para Prometheus y se proporciona información sobre el diagnóstico y la resolución de problemas.

Configuraste Managed Service para Prometheus, pero no ves ningún dato de métricas en Grafana ni en la IU de Prometheus. En un nivel alto, la causa puede ser cualquiera de las siguientes:

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

  • Un problema del lado de la transferencia, de modo que no se envían datos. Los problemas del lado de la transferencia 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 está en el lado de la transferencia o en el de la consulta, intenta consultar los datos con la pestaña PromQL del Explorador de métricas en la consola de Google Cloud. Se garantiza que esta página no tiene problemas con los permisos de lectura ni la configuración de Grafana.

Para ver esta página, haz lo siguiente:

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

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

    Ir al Explorador de métricas

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

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

  4. Verifica que PromQL esté seleccionado en el botón de activación Lenguaje. El botón de activación de lenguaje se encuentra en la misma barra de herramientas que te permite dar formato a tu consulta.

  5. Ingresa la siguiente consulta en el editor y, luego, haz clic en Ejecutar consulta:

    up

Si consultas la métrica up y ves los resultados, el problema es del lado de la consulta. Para obtener información sobre cómo resolver estos problemas, consulta Problemas del lado de las consultas.

Si consultas la métrica up y no ves ningún resultado, el problema es del lado de la transferencia. Para obtener información sobre cómo resolver estos problemas, consulta Problemas del lado de la transferencia.

Un firewall también puede causar problemas de transferencia y consulta. Para obtener más información, consulta Firewalls.

En la página Administración de métricas de Cloud Monitoring, se proporciona información que puede ayudarte a controlar el importe que inviertes en las métricas facturables sin afectar la observabilidad. En la página Administración de métricas, se informa la siguiente información:

  • Los volúmenes de transferencia para la facturación basada en bytes y de muestra, en todos los dominios de métricas y para las métricas individuales.
  • Datos sobre etiquetas y cardinalidad de métricas.
  • Cantidad de lecturas para cada métrica
  • Uso de métricas en políticas de alertas y paneles personalizados.
  • Tasa de errores de escritura de métricas.

También puedes usar la administración de métricas para excluir las métricas innecesarias, lo que elimina el costo de transferirlas.

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

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

    Ir a Administración de métricas

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

  2. En la barra de herramientas, selecciona tu período. De forma predeterminada, la página Administración de métricas muestra información sobre las métricas recopiladas en el día anterior.

Para obtener más información sobre la página Administración de métricas, consulta Visualiza y administra el uso de métricas.

Problemas del lado de la consulta

La causa de la mayoría de los problemas del lado de la consulta es una de las siguientes:

Comienza por lo siguiente:

  • Verifica tu configuración con cuidado con las instrucciones de configuración para consultas.

  • Si usas Workload Identity Federation for GKE, verifica que tu cuenta de servicio tenga los permisos correctos. Para ello, haz lo siguiente:

    1. En la consola de Google Cloud, ve a la página IAM:

      Ir a IAM

      Si usas la barra de búsqueda para encontrar esta página, selecciona el resultado cuyo subtítulo es 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 de forma correcta. Luego, haz clic en Editar.

    3. Selecciona el campo Rol y haz clic en Usadas en este momento y busca el rol del Visualizador de Monitoring. Si la cuenta de servicio no tiene este rol, agrégala ahora.

Si el problema persiste, considera las siguientes posibilidades:

Configuración o escritura incorrecta de Secretos

Si ves alguno de los siguientes elementos, es posible que haya un Secret efaltante o mal escrito:

  • Uno de estos errores “prohibidos” en Grafana o en la IU de Prometheus es el siguiente:

    • “Warning: Unexpected response status when fetching server time: Forbidden”
    • “Advertencia: Error al recuperan las listas de métricas: Estado de respuesta inesperado cuando se recuperan los nombres de las métricas: Prohibido”

  • Un mensaje como este en tus registros:
    “cannot read credentials file: open /gmp/key.json: no such file or directory”

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

  1. Verifica que elegiste el extremo 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 en CronJob si ejecutas el comando kubectl describe cronjob datasource-syncer.

  2. Verifica que configuraste el ID del proyecto del sincronizador de fuentes de datos en el mismo permiso de métricas o el proyecto para el que tu cuenta de servicio tiene credenciales.

  3. Verifica que tu cuenta de servicio de Grafana tenga el rol “Administrador” y que tu token de API no haya vencido.

  4. Verifica que tu cuenta de servicio tenga el rol de Visualizador de Monitoring para el ID del proyecto elegido.

  5. Ejecuta kubectl logs job.batch/datasource-syncer-init para verificar que no haya errores en los registros del trabajo del sincronizador de fuentes de datos. Este comando se debe ejecutar de inmediato después de aplicar el archivo datasource-syncer.yaml.

  6. Si usas Workload Identity Federation for GKE, verifica que no hayas escrito mal la clave o las credenciales de la cuenta y verifica que lo hayas vinculado al espacio de nombres correcto.

Si usas el proxy de la IU de frontend heredado, intenta lo siguiente para resolver estos errores:

  1. Verifica que hayas configurado el ID del proyecto de la IU de frontend en el mismo proyecto o permiso de métricas para el que tu cuenta de servicio tiene credenciales.

  2. Verifica el ID del proyecto que especificaste para las marcas --query.project-id.

  3. Verifica que tu cuenta de servicio tenga el rol de Visualizador de Monitoring para el ID del proyecto elegido.

  4. Verifica que hayas configurado el ID del proyecto correcto cuando implementaste la IU de frontend y no lo hayas configurado en la string literal PROJECT_ID.

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

  6. Si activas 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 esté activado de forma correcta:

    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 Secret se pase de forma correcta 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 está configurado para enviar una solicitud POST en lugar de una GET:

  • “{“status”:“error”,“errorType”:“bad_data”,“error”:“no coincide[] parámetro proporcionado”}%”

Para resolver este problema, configura Grafana para usar una solicitud GET a través de las instrucciones en Configura una fuente de datos.

Tiempos de espera en consultas grandes o de larga duración

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

  • "Post "http://frontend.NAMESPACE_NAME.svc:9090/api/v1/query_range": net/http: timeout awaiting response headers"

El servicio administrado 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 Configura una fuente de datos.

Errores de validación de etiquetas

Si ves uno de los siguientes errores en Grafana, es posible que uses un extremo no compatible:

  • “Validation: labels other than name are not supported yet”
  • “Templating [job]: Error updating options: labels other than name are not supported yet.”

Managed Service para Prometheus es compatible con el extremo /api/v1/$label/values solo para la etiqueta __name__. Esta limitación hace que las consultas que usan la variable label_values($label) en Grafana fallen.

En su lugar, usa el formulario label_values($metric, $label). Se recomienda esta consulta, ya que restringe los valores de las etiquetas que se muestran por métrica, lo que evita la recuperación de valores no relacionados con el contenido del panel. Esta consulta llama a un extremo compatible con Prometheus.

Para obtener más información sobre los extremos compatibles, consulta Compatibilidad de la API.

Se superó la cuota

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

  • “429: RESOURCE_EXHAUSTED: Quota exceeded for quota metric 'Time series queries ' and limit 'Time series queries per minute' of service 'monitoring.googleapis.com' for consumer 'project_number…'.”

Para resolver este problema, envía una solicitud para aumentar tu cuota de lectura a la API de Monitoring. Para obtener ayuda, comunícate con la Asistencia de Google Cloud. Para obtener más información sobre las cuotas, consulta Trabaja con cuotas.

Métricas de varios proyectos

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

En su lugar, crea un alcance de métricas de Cloud Monitoring en un proyecto de Google Cloud, el proyecto de permisos, que contenga los proyectos que deseas supervisar. Cuando configuras la fuente de datos de Grafana con un proyecto de permiso, obtienes acceso a los datos de todos los proyectos en el permiso de las métricas. Si deseas obtener más información, visita Permisos de consultas y métricas.

No se especificó ningún tipo de recurso supervisado

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

  • “La métrica está configurada para usarse con más de un tipo de recurso supervisado. El selector de series debe especificar un comparador de etiquetas en el nombre de recurso supervisado”.

Para especificar un tipo de recurso supervisado, filtra a través de la etiqueta monitored_resource. Para obtener más información sobre cómo identificar y elegir un tipo de recurso supervisado válido, consulta Especifica un tipo de recurso supervisado.

Los valores sin procesar del contador, el histograma y el resumen no coinciden entre la IU del recopilador y la consola de Google Cloud

Es posible que notes una diferencia entre los valores en la IU del recopilador local de Prometheus y la consola de Google Cloud cuando consultes el valor sin procesar de las métricas de Prometheus acumulativas, incluidos los contadores, los histogramas y los resúmenes. Se espera que esto suceda.

Monarch requiere marcas de tiempo de inicio, pero Prometheus no tiene marcas de tiempo de inicio. El servicio administrado para Prometheus genera marcas de tiempo de omisión del primer punto transferido en cualquier serie temporal y lo convierte en una marca de tiempo de inicio. A los puntos posteriores se les resta el valor del punto inicial que se omitió para garantizar 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 en la IU del recopilador y el número en la consola de Google Cloud es igual al primer valor registrado en la IU del recopilador, lo que se espera porque el sistema omite ese valor inicial y lo resta de los puntos posteriores.

Esto es aceptable debido a que no es necesario ejecutar una consulta para los valores sin procesar para las métricas acumulativas. Todas las consultas útiles requieren una función rate() o similar, en cuyo caso la diferencia en cualquier horizonte temporal es idéntica entre las dos IU. Las métricas acumulativas solo aumentan, por lo que no puedes configurar una alerta en una consulta sin procesar, puesto que una serie temporal solo alcanza un umbral una vez. Todas las alertas y gráficos útiles observan el cambio o la frecuencia de cambio en el valor.

El colector solo conserva alrededor de 10 minutos de datos de forma local. Las discrepancias en los valores acumulativos sin procesar también pueden surgir debido a un restablecimiento que se produce antes del horizonte de 10 minutos. Para descartar esta posibilidad, intenta configurar solo un período de visualización de consultas de 10 minutos cuando compares la IU de colector con la consola de Google Cloud.

Las discrepancias también se pueden deber a tener varios subprocesos de trabajador en tu aplicación, cada uno con un extremo /metrics. Si tu aplicación inicia varios subprocesos, debes colocar la biblioteca cliente de Prometheus en modo de varios procesos. Si quieres obtener más información, consulta la documentación sobre cómo usar el modo de varios procesos en la biblioteca cliente de Python de Prometheus.

Faltan datos de contador o histogramas rotos

El indicador más común de este problema es no ver datos o espacios de datos cuando se consulta una métrica de contador simple (por ejemplo, una consulta de PromQL de metric_name_foo). Puedes confirmar esto si los datos aparecen después de agregar una función rate a tu consulta (por ejemplo, rate(metric_name_foo[5m])).

También puedes notar que tus muestras transferidas aumentaron de forma considerable sin ningún cambio importante en el volumen de recopilación o que se crean métricas nuevas con los sufijos “unknown” o “unknown:counter” en Cloud Monitoring.

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

Estos problemas se producen cuando una métrica se recopila sin un TYPE de métrica de Prometheus. Debido a que en Monarch se aplican tipos estrictos, el servicio administrado para Prometheus incluye las métricas sin tipo agregándoles el sufijo “unknown" y transfiriéndolas dos veces, una vez como un indicador y una vez como contador. Luego, el motor de consultas elige si quiere consultar el indicador subyacente o la métrica de contador según las funciones de consulta que uses.

Si bien esta heurística suele funcionar bastante bien, puede generar problemas como resultados extraños cuando se consulta una métrica "unknown:counter" sin procesar. Además, como los histogramas son objetos escritos en Monarch, la transferencia de las tres métricas de histogramas obligatorias como métricas de contador individuales causa que las funciones de histogramas no funcionen. Como las métricas de tipo “unkown” se transfieren dos veces, si no se establece un TYPE, se duplican las muestras transferidas.

Entre los motivos comunes por los que no se puede establecer TYPE, se incluyen los siguientes:

  • Configurar por accidente un recopilador del servicio administrado para Prometheus como un servidor de la federación. La federación no es compatible cuando se usa el servicio administrado para Prometheus. A medida que la federación descarta de forma intencional la información de TYPE, la implementación de la federación causa métricas de tipo “unkown”.
  • Usar Prometheus Remote Write en cualquier momento de la canalización de transferencia. Este protocolo también descarta información TYPE de forma intencional.
  • Con una regla de reetiquetado que modifica el nombre de la métrica. Esto hace que la métrica con un nuevo nombre se desasocie de la información de TYPE asociada con el nombre de la métrica original.
  • El exportador no emite un TYPE para cada métrica.
  • Un problema transitorio en el que se descarta TYPE cuando se inicia el recopilador por primera vez.

Para solucionar este problema, haz lo siguiente:

  • Deja de usar la federación con el servicio administrado para Prometheus. Si deseas reducir la cardinalidad y los costos a través del “acumulativo” antes de enviarlos a MongoDB, consulta Configura la agregación local.
  • Deja de usar Prometheus Remote Write en tu ruta de recopilación.
  • Para confirmar que el campo # TYPE existe para cada métrica, visita el extremo /metrics.
  • Borra las reglas de reetiquetado que modifiquen el nombre de una métrica.
  • Borra las métricas en conflicto con el sufijo “unknown” o “unknown:counter” a través de una llamada a DeleteMetricDescriptor.
  • También siempre puedes consultar contadores a través de rate o alguna otra función de procesamiento de contadores.

Los datos de Grafana no se conservan después del reinicio del Pod

Si tus datos parecen desaparecer de Grafana después de reiniciar el Pod, pero se pueden ver en Cloud Monitoring, usa Grafana para consultar la instancia local de Prometheus en lugar del servicio administrado para Prometheus.

Si deseas obtener información sobre cómo configurar Grafana para usar el servicio administrado como una fuente de datos, consulta Grafana.

Importa paneles de Grafana

Para obtener información sobre el uso y la solución de problemas del importador de panel, consulta Importa paneles de Grafana a Cloud Monitoring.

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

Problemas del lado de la transferencia

Los problemas del lado de la transferencia pueden estar relacionados con la recopilación o la evaluación de reglas. Comienza por observar los registros de error de la recopilación administrada. 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 GKE Autopilot, 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 objetivo puede ayudarte a depurar el objetivo de recopilación. Para obtener más información, consulta la información de estado del destino.

Falta el estado del extremo o es demasiado antiguo

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

  • El servicio administrado para Prometheus no pudo acceder a un colector en el mismo nodo que uno de tus extremos.
  • Una o más de tus configuraciones de PodMonitoring o ClusterPodMonitoring no generaron objetivos válidos.

Los problemas similares también pueden hacer que el campo Status.Endpoint Statuses.Last Update Time tenga un valor anterior a unos minutos más tu intervalo de recopilación.

Para resolver este problema, comienza por verificar que los pods de Kubernetes asociados con tu extremo de recopilación estén en ejecución. Si tus pods de Kubernetes están en ejecución, los selectores de etiquetas coinciden y puedes acceder de forma manual a los extremos de recopilación (por lo general, visitas al extremo /metrics). Luego, verifica si el Servicio administrado para los recopiladores de Prometheus que se ejecutan.

La fracción de recopiladores es menor que 1

Si habilitaste la función de estado objetivo, obtendrás información de estado sobre los recursos. El valor Status.Endpoint Statuses.Collectors Fraction de tus recursos PodMonitoring o ClusterPodMonitoring representa la fracción de colectores, expresados de 0 a 1, a los que se puede acceder. Por ejemplo, un valor de 0.5 indica que se puedes acceder al 50% de tus recopiladores, mientras que un valor de 1 indica que se puede acceder al 100% de tus recopiladores.

Si el campo Collectors Fraction tiene un valor distinto de 1, es posible que no se pueda acceder a uno o más recopiladores, y que no se puedan recopilar las métricas de ninguno de esos nodos. Asegúrate de que todos los recopiladores 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 colector con el siguiente comando:

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

En los clústeres de GKE Autopilot, este comando se ve un poco diferente:

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

Puedes investigar los pods de colector individuales (por ejemplo, un pod de colector llamado collector-12345) con el siguiente comando:

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

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

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

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

Si los colectores están en buen estado, verifica los registros del operador. Para verificar 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 GKE Autopilot, ejecuta el siguiente comando:

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

Luego, verifica los registros del operador (por ejemplo, un pod del operador llamado gmp-operator-12345) con el siguiente comando:

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

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

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

Objetivos en mal estado

Si habilitaste la función de estado del destino, pero uno o más de tus recursos PodMonitoring o ClusterPodMonitoring tienen el campo Status.Endpoint Statuses.Unhealthy Targets con un valor distinto de 0, entonces. El colector no puede recopilar uno o más de tus objetivos.

Visualiza el campo Sample Groups, que agrupa los destinos por mensaje de error y busca el campo Last Error. El campo Last Error proviene de Prometheus y te indica por qué no se pudo recopilar el destino. Para resolver este problema, usa los objetivos de muestra como referencia y verifica si los extremos de recopilación están en ejecución.

Extremo de recopilación no autorizado

Si ves uno de los siguientes errores y tu objetivo de recopilación requiere autorización, tu recopilador no está configurado para usar el tipo de autorización correcto o usa la carga útil de autorización incorrecta:

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

Para resolver este problema, consulta Configura un extremo de recopilación autorizado.

Se superó la cuota

Si ves el siguiente error, significa que superaste tu cuota de transferencia para la API de Cloud Monitoring:

  • “429: Quota exceeded for quota metric 'Time series ingestion requests' and limit 'Time series ingestion requests per minute' of service 'monitoring.googleapis.com' for consumer 'project_number:PROJECT_NUMBER'., rateLimitExceeded”

Este error se suele ver cuando se abre el servicio administrado por primera vez. La cuota predeterminada se agotará en 100,000 muestras por segundo transferidas.

Para resolver este problema, envía una solicitud para aumentar tu cuota de transferencia a la API de Monitoring. Para obtener ayuda, comunícate con la Asistencia de Google Cloud. Para obtener más información sobre las cuotas, consulta Trabaja con cuotas.

Falta un permiso en la cuenta de servicio predeterminada del nodo

Si ves uno de los siguientes errores, es posible que falten permisos en la cuenta de servicio predeterminada del nodo:

  • “execute query: Error querying Prometheus: client_error: client error: 403”
  • “Readiness probe failed: HTTP probe failed with statuscode: 503”
  • “Error querying Prometheus instance”

La recopilación administrada y el evaluador de reglas administradas en Managed Service para Prometheus usan la cuenta de servicio predeterminada en el nodo. Esta cuenta se crea con todos los permisos necesarios, pero, a veces, los clientes quitan los permisos de Monitoring de forma manual. Esta eliminación hace que la evaluación de la recopilación y la regla falle.

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

  • Identifica el nombre del nodo subyacente de Compute Engine y, luego, ejecuta el siguiente comando:

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

    Busca la string https://www.googleapis.com/auth/monitoring. Si es necesario, agrega Monitoring como se describe en Configuración incorrecta de la cuenta de servicio.

  • Navega a la VM subyacente en el clúster y verifica la configuración de la cuenta de servicio del nodo:

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

      Ir a clústeres de Kubernetes

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

    2. Selecciona Nodos y, luego, haz clic en el nombre del nodo en la tabla Nodos.

    3. Haz clic en Detalles.

    4. Haz clic en el vínculo Instancia de VM.

    5. Ubica el panel de Administración de identidades y API 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 IU de Prometheus estén configurados para buscar el proyecto incorrecto. Si deseas obtener información para verificar que consultas el permiso de las métricas previstas, consulta Cambia el proyecto consultado.

Configuración incorrecta de la cuenta de servicio

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

  • “code = PermissionDenied desc = Permission monitoring.timeSeries.create denied (or the resource may not exist)”
  • “google: could not find default credentials. See https://developers.google.com/accounts/docs/application-default-credentials for more information.”

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

  1. En la consola de Google Cloud, ve a la página IAM:

    Ir a IAM

    Si usas la barra de búsqueda para encontrar esta página, selecciona el resultado cuyo subtítulo es 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 de forma correcta. Luego, haz clic en Editar.

  3. Selecciona el campo Rol y haz clic en Usadas en este momento y busca el rol de Escritor de métricas de Monitoring o Editor de Monitoring. Si la cuenta de servicio no tiene uno de estos roles, otórgale el rol Escritor de métricas de Monitoring (roles/monitoring.metricWriter).

Si ejecutas en Kubernetes que no es de GKE, debes pasar las credenciales de forma explícita al colector y al evaluador de reglas. Debes repetir las credenciales en las secciones rules y collection. Para obtener más información, consulta Proporciona credenciales de manera explícita (para la recopilación) o Proporciona credenciales de forma explícita (para las reglas).

Las cuentas de servicio suelen tener alcance de un solo proyecto de Google Cloud. Si usas una cuenta de servicio para escribir datos de métricas de varios proyectos (por ejemplo, cuando un evaluador de reglas administradas consulta un permiso de métricas de varios proyectos), este error puede generarse. Si usas la cuenta de servicio predeterminada, considera configurar una cuenta de servicio dedicada para que puedas agregar de manera segura el permiso monitoring.timeSeries.create para varios proyectos. Si no puedes otorgar este permiso, puedes usar el reetiquetado de métricas para reescribir la etiqueta project_id con otro nombre. El ID del proyecto se establece de forma predeterminada en el proyecto de Google Cloud en el que se ejecuta el servidor de Prometheus o el evaluador de reglas.

Configuración de scrape no válida

Si ves el siguiente error, significa que el PodMonitoring o ClusterPodMonitoring no tienen el formato correcto:

  • “Se produjo un error interno: se produjo un error cuando se llamaba al webhook “validate.podmonitorings.gmp-operator.gmp-system.monitoring.googleapis.com”: publicación “https://gmp-operator.gmp-system.svc:443/validate/monitoring.googleapis.com/v1/podmonitorings?timeout=10s": EOF"”

Para resolver esto, asegúrate de que tu recurso personalizado tenga el formato correcto según la especificación.

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

En las versiones del Servicio administrado para Prometheus anteriores a la 0.12, es posible que veas un error similar al siguiente, que se relaciona con la inserció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""

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

Problemas con tiempos de espera e intervalos de recopilación

Cuando usas Managed Service para Prometheus, el tiempo de espera de recopilación no puede ser mayor que el intervalo de recopilación. Para verificar tus registros de este problema, ejecuta el siguiente comando:

kubectl -n gmp-system logs ds/collector prometheus

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

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

Busca este mensaje:

  • “scrape timeout greater than scrape interval for scrape config with job name “PodMonitoring/gmp-system/example-app/go-metrics””

Para resolver este problema, establece el valor del intervalo de recopilación como igual o mayor que el valor del tiempo de espera de recopilación.

Falta TIPO en la métrica

Si ves el siguiente error, significa que a la métrica le falta información de tipo:

  • “no metadata found for metric name “{metric_name}””

Para verificar que la información de tipo faltante no sea el problema, comprueba el resultado /metrics de la aplicación que exporta. Si no hay una línea como la siguiente, falta la información del tipo:

# TYPE {metric_name} <type>

Algunas bibliotecas, como las de VictoriaMetrics anteriores a la versión 1.28.0, descartan de forma intencional la información sobre el 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 colector que intente escribir en la misma serie temporal:

  • “One or more TimeSeries could not be written: One or more points were written more frequently than the maximum sampling period configured for the metric”.
  • “One or more TimeSeries could not be written: Points must be written in order. One or more of the points specified had an older end time than the most recent point.”

A continuación, se detallan las causas y las soluciones más comunes:

  • Usa pares con alta disponibilidad. El servicio administrado para Prometheus no admite la colección tradicional con alta disponibilidad. Usar esta configuración puede crear varios colectores que intenten escribir datos en la misma serie temporal, lo que causa este error.

    Para resolver el problema, inhabilita los colectores duplicados a través de la reducción del recuento de réplicas a 1 o usa el método de alta disponibilidad compatible.

  • Usar reglas de etiquetado nuevo, en particular las que operan en instancias o trabajos. Managed Service para Prometheus identifica de forma parcial una serie temporal única a través de la combinación de etiquetas {project_id, location, cluster, namespace, job y instance}. Usar una regla de reetiquetado para descartar estas etiquetas, en especial las etiquetas job y instance, puede causar colisiones. No se recomienda volver a escribir estas etiquetas.

    Para resolver el problema, borra la regla que lo causa. a menudo, esto se puede hacer a través de la regla metricRelabeling que usa la acción labeldrop. Para identificar la regla problemática, comenta todas las reglas de reetiquetado y, luego, restablécelas, una a la vez, hasta que se repita el error.

Una causa menos común de colisiones de series temporales es usar un intervalo de recopilación menor a 5 segundos. El intervalo de recopilación mínimo que admite el servicio administrado para Prometheus es de 5 segundos.

Supera el límite en la cantidad de etiquetas

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

  • “Una o más TimeSeries no pudieron ser escritas: las nuevas etiquetas podrían provocar que la métrica prometheus.googleapis.com/METRIC_NAME tenga más de PER_PROJECT_LIMIT etiquetas”.

Por lo general, este error ocurre cuando cambias con rapidez la definición de la métrica, de modo que un nombre de métrica tenga varios conjuntos de claves de etiqueta independientes durante toda la vida útil de tu métrica. Cloud Monitoring impone un límite en la cantidad de etiquetas de cada métrica. Para obtener más información, consulta los límites de las métricas definidas por el usuario.

Existen tres pasos para resolver este problema:

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

  2. Aborda la fuente del problema, que puede implicar ajustar las reglas de reetiquetado de PodMonitoring, cambiar el exportador o corregir la instrumentación.

  3. Borra el descriptor de métrica para esta métrica (que incurrirá en la pérdida de datos) para que se pueda volver a crear con un conjunto de etiquetas más pequeño y estable. Puedes usar el método metricDescriptors.delete para hacerlo.

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

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

    Para resolver esto, puedes usar una sección metricRelabeling en PodMonitoring para conservar o descartar etiquetas. Algunas aplicaciones y exportadores también permiten la configuración que cambia las métricas exportadas. Por ejemplo, cAdvisor tiene varios parámetros de configuración avanzados del entorno de ejecución que pueden agregar etiquetas de forma dinámica. Cuando uses la recopilación administrada, te recomendamos usar la colección integrada de kubelet automático.

  • Usar reglas de etiquetado nuevo, en particular las que adjuntan nombres de etiquetas de forma dinámica, puede causar un número inesperado de etiquetas.

    Para resolver el problema, borra la entrada de la regla que la causa.

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

Si ves el siguiente error, significa que alcanzaste el límite de frecuencia por minuto para crear métricas nuevas y agregar etiquetas de métricas nuevas a las métricas existentes:

  • "La solicitud está limitada. Alcanzaste el límite por proyecto en la definición de las métricas o los cambios en la definición de las etiquetas por minuto”.

Por lo general, este límite de frecuencia solo se alcanza cuando se integra por primera vez en el servicio administrado para Prometheus, por ejemplo, cuando migras una implementación existente de Prometheus maduro para usar la recopilación autoimplementada. Este no es un límite de frecuencia para la transferencia de datos. Este límite de frecuencia solo se aplica cuando creas métricas nunca antes vistas o cuando agregas etiquetas nuevas a métricas existentes.

Esta cuota es fija, pero cualquier problema debería resolverse de forma automática a medida que se crean nuevas métricas y etiquetas de métricas hasta el límite por minuto.

Límites de la cantidad de descriptores de métricas

Si ves el siguiente error, significa que alcanzaste el límite de cuota para la cantidad de descriptores de métricas dentro de un solo proyecto de Google Cloud:

  • “Se agotó la cuota del descriptor de métricas”.

De forma predeterminada, este límite se establece en 25,000. Aunque esta cuota puede aumentarse por solicitud si las métricas tienen el formato correcto, es mucho más probable que alcances este límite porque transfieres nombres de métricas con formato incorrecto al sistema.

Prometheus tiene un modelo de datos dimensionales en el que la información, como el nombre del clúster o el espacio de nombres, se debe codificar como un valor de etiqueta. Cuando la información dimensional está incorporada en el nombre de la métrica, la cantidad de descriptores de métrica aumenta de forma indefinida. Además, debido a que en este caso las etiquetas no se usan de forma correcta, se vuelve mucho más difícil consultar y agregar datos en clústeres, espacios de nombres o servicios.

Ni Cloud Monitoring ni el servicio administrado para Prometheus admiten métricas no dimensionales, como las que tienen formato StatsD o Graphite. Si bien la mayoría de los exportadores de Prometheus están configurados de forma correcta, algunos exportadores, como el exportador de StatsD, el exportador de Vault o el proxy de Envoy que viene con Istio, deben configurarse de forma explícita para usar etiquetas en lugar de incorporar 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 solucionar este problema, haz lo siguiente:

  1. En la consola de Google Cloud, selecciona el proyecto de Google Cloud que está vinculado al error.

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

    Ir a Administración de métricas

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

  3. Confirma que la suma de las métricas inactivas y activas sea superior a 25,000. En la mayoría de los casos, deberías ver una gran cantidad de métricas inactivas.
  4. Selecciona "Inactivo" en el panel Filtros rápidos, ve a la lista y busca patrones.
  5. Selecciona "Activo" en el panel Filtros rápidos, ordena de forma descendente según el volumen facturable de muestras, ve a la lista y busca patrones.
  6. Ordena de forma ascendente según el volumen facturable de muestras, ve a la lista y busca patrones.

Como alternativa, puedes confirmar este problema mediante el Explorador de métricas:

  1. En la consola de Google Cloud, selecciona el proyecto de Google Cloud que está vinculado al error.

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

    Ir al Explorador de métricas

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

  3. En el compilador de consultas, haz clic en una métrica y, luego, borra la casilla de verificación “Activo”.
  4. Escribe “prometheus” en la barra de búsqueda.
  5. Busca cualquier patrón en los nombres de las métricas.

Una vez que hayas identificado los patrones que indican métricas con formato incorrecto, puedes mitigar el problema si corriges el exportador en la fuente y, luego, borras los descriptores de métricas problemáticos.

Para evitar que vuelva a ocurrir este problema, primero debes configurar el exportador relevante a fin de que ya no emita métricas con formato incorrecto. Te recomendamos que consultes la documentación de tu exportador para obtener ayuda. Para confirmar que corregiste el problema, visita el extremo /metrics de forma manual e inspecciona los nombres de las métricas exportadas.

Luego, puedes liberar la cuota si borras las métricas con formato incorrecto mediante el método projects.metricDescriptors.delete. Para iterar con mayor facilidad a través de la lista de métricas con formato incorrecto, proporcionamos una secuencia de comandos de Golang que puedes usar. Esta secuencia de comandos acepta una expresión regular que puede identificar tus métricas con formato incorrecto y borra los descriptores de métricas que coincidan con el patrón. Dado que la eliminación de métricas es irreversible, te recomendamos que primero ejecutes la secuencia de comandos con el modo de ejecución de prueba.

Sin errores ni métricas

Si usas la recopilación administrada, no ves ningún error, pero los datos no aparecen en Cloud Monitoring, la causa más probable es que tus exportadores de métricas o los parámetros de configuración de recopilación no estén configurados de forma correcta. Managed Service para Prometheus no envía ningún dato de series temporales, a menos que primero apliques una configuración de recopilación válida.

Para identificar si esta es la causa, intenta implementar la aplicación de ejemplo y el recurso de PodMonitoring de ejemplo. Si ves la métrica up (puede tardar unos minutos), el problema es con la configuración de recopilación o el exportador.

La causa raíz podría ser cualquier cantidad de elementos. Recomendamos verificar lo siguiente:

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

  • La especificación del Deployment del exportador tiene puertos con nombres correctos.

  • Tus selectores (por lo general, app) coinciden en tus recursos de Deployment y PodMonitoring.

  • Puedes ver los datos en tu extremo y puerto esperados si los visitas de forma manual.

  • Instalaste tu recurso PodMonitoring en el mismo espacio de nombres que la aplicación en la que deseas hacer scraping. No instales ningún recurso o aplicación personalizado en el espacio de nombres gmp-system o gke-gmp-system.

  • Los nombres de tus métricas y etiquetas coinciden con la expresión regular de validación de Prometheus. El servicio administrado para Prometheus no admite nombres de etiquetas que comiencen con el carácter _.

  • No usas un conjunto de filtros que haga que se filtren todos los datos. Ten especial cuidado de no tener filtros en conflicto cuando usas un filtro collection en el recurso OperatorConfig.

  • Si se ejecuta fuera de Google Cloud, project o project-id se configuran como un proyecto válido de Google Cloud y location se configura como una región de Google Cloud válida. No puedes usar global como valor para 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 estos tipos de métricas no son compatibles con Managed Service para Prometheus y se descartan en silencio.

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

Google Cloud Managed Service para Prometheus está implementado y no hay errores de configuración. Sin embargo, 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 durante cuánto tiempo se suele ejecutar el trabajo:

  1. Busca el archivo YAML de implementación del trabajo cron y busca el estado, que aparece al final del archivo. El estado en este ejemplo muestra que el trabajo se ejecutó 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 ejecuta por suficiente tiempo para que los datos de la métrica se recopilen de manera coherente.

    Para resolver esta situación, realiza las siguientes acciones:

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

    • Configura el trabajo para detectar si las métricas se recopilaronantes de salir. Esta función requiere compatibilidad con la biblioteca.

    • Considera crear una métrica con valor de distribución basada en registros en lugar derecopilar datos de métricas. Este enfoque se sugiere cuando los datosse publican a una tasa baja. Para obtener más información, consulta métricas basadas en registros.

  3. Si el tiempo de ejecución dura más de cinco minutos o si es incoherente, consulta la sección Objetivos en mal estado de este documento.

Problemas con la recopilación de exportadores

Si no se transfieren las métricas de un exportador, verifica lo siguiente:

  • Verifica que el exportador funcione y exporte métricas con el comando kubectl port-forward.

    Por ejemplo, para verificar que los Pods con el selector app.kubernetes.io/name=redis en el espacio de nombres test emitan métricas en el extremo /metrics en el puerto 9121, puedes redireccionar los puertos 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 extremo localhost:9121/metrics a través del navegador o curl en otra sesión de la terminal para verificar que el exportador exponga las métricas para recopilarlas.

  • Verifica si puedes consultar las métricas en la consola de Google Cloud, pero no en Grafana. Si es así, el problema es con Grafana, no con la recopilación de las métricas.

  • Verifica que el colector administrado pueda recopilar el exportador a través de la inspección de la interfaz web de Prometheus que expone el colector.

    1. Identifica el colector administrado que se ejecuta en el mismo nodo en el que se ejecuta tu exportador. Por ejemplo, si el exportador se ejecuta en Pods en el espacio de nombres test y los Pods se etiquetan con app.kubernetes.io/name=redis, el siguiente comando identifica el colector administrado 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 colector administrado:

      kubectl port-forward POD_NAME -n gmp-system 19090

    3. Navega a la URL localhost:19090/targets para acceder a la interfaz web. Si el exportador aparece como uno de los destinos, tu recopilador administrado está recopilando el exportador de manera correcta.

Errores de falta de memoria (OOM) del recopilador

Si usas la colección administrada y encuentras errores de falta de memoria (OOM) en tus recopiladores, considera habilitar el ajuste de escala automático vertical de Pods.

El operador tiene errores de memoria insuficiente (OOM)

Si usas la recopilación administrada y encuentras errores de memoria insuficiente (OOM) en tu operador, considera inhabilitar la función de estado objetivo. La función de estado objetivo puede causar problemas de rendimiento del operador en clústeres más grandes.

Firewalls

Un firewall puede causar problemas de transferencia y de consulta. Tu firewall debe configurarse para permitir las solicitudes POST y GET al servicio de la API de Monitoring, monitoring.googleapis.com, para permitir la transferencia y las consultas.

Error sobre ediciones simultáneas

El mensaje de error “Demasiadas ediciones simultáneas en la configuración del proyecto” suele ser transitorio y se resuelve después de unos minutos. Por lo general, se produce cuando se quita una regla de reetiquetado 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 en tu proyecto. El error desaparece cuando se procesa la cola.

Para obtener más información, consulta Límites en la creación y actualización de métricas y etiquetas.

Consultas bloqueadas y canceladas por Monarch

Si ves el siguiente error, significa que alcanzaste el límite interno de la cantidad de consultas simultáneas que se pueden ejecutar para 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."

Para protegerte contra el abuso, el sistema aplica un límite estricto a la cantidad de consultas de un proyecto que se pueden ejecutar de forma simultánea en Monarch. Con el uso típico de Prometheus, las consultas deben ser rápidas y nunca se debe alcanzar este límite.

Es posible que alcances este límite si emites muchas consultas simultáneas que se ejecutan durante un tiempo más largo de lo esperado. Las consultas que solicitan más de 25 horas de datos suelen ejecutarse más lentamente que las que solicitan menos de 25 horas de datos, y cuanto más largo sea el período de visualización de la consulta, más lenta se espera que sea.

Por lo general, este problema se activa cuando se ejecutan muchas reglas de visualización a largo plazo de manera ineficiente. Por ejemplo, puedes tener muchas reglas que se ejecuten una vez cada minuto y soliciten una tarifa de 4 semanas. Si cada una de estas reglas tarda mucho en ejecutarse, es posible que, con el tiempo, se genere una copia de seguridad de las consultas que esperan ejecutarse para tu proyecto, lo que provocará que Monarch reduzca la velocidad de las consultas.

Para resolver este problema, debes aumentar el intervalo de evaluación de tus reglas de visualización a largo plazo para que no se ejecuten cada 1 minuto. No es necesario ejecutar una consulta para una tasa de 4 semanas cada 1 minuto, ya que hay 40,320 minutos en 4 semanas, por lo que cada minuto no te brinda casi ningún indicador adicional (tus datos cambiarán como máximo en 1/40,320). Usar 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 las consultas ineficientes de larga duración que se ejecutan con demasiada frecuencia, este problema debería resolverse por sí solo.

Tipos de valores incompatibles

Si ves el siguiente error durante la transferencia o consulta, tienes una incompatibilidad de tipo de valores 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”
  • “Una o más TimeSeries no pudieron ser escritas: tipo de valor para la métrica prometheus.googleapis.com/target_info/gauge entra en conflicto con el tipo de valor existente (INT64)”.

Es posible que veas este error durante la transferencia, ya que Monarch no admite escribir datos de tipo DOUBLE en métricas de tipo INT64 ni escribir datos de tipo INT64 en métricas de tipo DOUBLE. También es posible que veas este error cuando realices consultas con un permiso de métricas de varios proyectos, ya que Monarch no puede unir métricas de tipo DOUBLE en un proyecto con métricas de tipo INT64 en otro.

Este error solo ocurre cuando tienes datos de informes de recopiladores de OpenTelemetry, y es más probable que ocurra si tienes datos de informes de OpenTelemetry (con el exportador googlemanagedprometheus) y Prometheus para la misma métrica, como suele ocurrir con la métrica target_info.

Es probable que la causa sea una de las siguientes opciones:

  • Estás recopilando métricas de OTLP y la biblioteca de métricas de OTLP cambió su tipo de valor de DOUBLE a INT64, como ocurrió con las métricas de Java de OpenTelemetry. La versión nueva de la biblioteca de métricas ahora es incompatible con el tipo de valor de métrica que crea la versión anterior de la biblioteca de métricas.
  • Recopilas la métrica target_info con Prometheus y OpenTelemetry. Prometheus recopila esta métrica como un DOUBLE, mientras que OpenTelemetry la recopila como un INT64. Ahora, tus recopiladores escriben dos tipos de valores en la misma métrica del mismo proyecto, y solo el recopilador que creó el descriptor de métrica por primera vez tiene éxito.
  • Recopilas target_info con OpenTelemetry como INT64 en un proyecto y target_info con Prometheus como DOUBLE en otro proyecto. Agregar ambas métricas al mismo permiso de métricas y, luego, consultar esa métrica a través del permiso de métricas genera una unión no válida entre tipos de valores de métricas incompatibles.

Para solucionar este problema, se fuerza todos los tipos de valores de métricas a DOBLE de la siguiente manera:

  1. Para forzar que todas las métricas sean un tipo DOUBLE, vuelve a configurar los recopiladores de OpenTelemetry habilitando la marca exporter.googlemanagedprometheus.intToDouble de la puerta de enlace de funciones.
  2. Borra todos los descriptores de métricas INT64 y deja que se vuelvan a crear como DOUBLE. Puedes usar la secuencia de comandos delete_metric_descriptors.go para automatizar esto.

Si sigues estos pasos, se borrarán todos los datos almacenados como una métrica INT64. No hay alternativa a borrar las métricas INT64 que resuelven este problema por completo.