Empezar a utilizar colecciones desplegadas automáticamente

En este documento se describe cómo configurar Google Cloud Managed Service para Prometheus con la recogida autodesplegada. Se implementa una aplicación de ejemplo en un clúster de Kubernetes y la monitoriza un servidor de Prometheus que almacena las métricas recogidas en Monarch.

En este documento se explica cómo hacer lo siguiente:

  • Configura tu entorno y tus herramientas de línea de comandos.
  • Configura una cuenta de servicio para la federación de identidades de cargas de trabajo en clústeres habilitados para GKE.
  • Ejecuta el archivo binario de Prometheus en Kubernetes.
  • Controlar qué métricas se ingieren en Managed Service para Prometheus.
  • Integra Managed Service para Prometheus con configuraciones de prometheus-operator.
  • Compila y ejecuta manualmente el archivo binario de Prometheus.

Con la recogida de datos autodesplegada, gestionas tu instalación de Prometheus como siempre. La única diferencia es que ejecutas el binario de sustitución directa de Managed Service para Prometheus, gke.gcr.io/prometheus-engine/prometheus:v2.53.4-gmp.0-gke.1, en lugar del binario de Prometheus upstream.

El archivo binario de inserción proporciona opciones de configuración adicionales con las marcas --export.*. Para obtener más información, consulta el resultado de la opción --help. En este documento se indican las opciones más importantes.

Managed Service for Prometheus no admite la exportación de métricas desde un servidor de federación ni desde un servidor utilizado como receptor de escritura remota. Puede replicar todas las funciones del servidor de federación, como reducir el volumen de ingesta agregando datos antes de enviarlos a Monarch, mediante filtros y agregaciones locales.

El streaming de datos a Managed Service para Prometheus consume recursos adicionales. Si vas a desplegar los colectores por tu cuenta, te recomendamos que multipliques por 5 los límites de CPU y memoria, y que los ajustes en función del uso real.

Para obtener más información sobre la recogida de datos gestionada y autodesplegada, consulta el artículo Recogida de datos con Managed Service para Prometheus.

Antes de empezar

En esta sección se describe la configuración necesaria para las tareas que se indican en este documento.

Configurar proyectos y herramientas

Para usar Google Cloud Managed Service para Prometheus, necesitas los siguientes recursos:

  • Un Google Cloud proyecto con la API de Cloud Monitoring habilitada.

    • Si no tienes ningún Google Cloud proyecto, haz lo siguiente:

      1. En la Google Cloud consola, ve a Nuevo proyecto:

        Crear un proyecto

      2. En el campo Nombre del proyecto, escribe el nombre que quieras darle al proyecto y, a continuación, haz clic en Crear.

      3. Ve a Facturación:

        Ir a Facturación

      4. Selecciona el proyecto que acabas de crear si aún no está seleccionado en la parte superior de la página.

      5. Se te pedirá que elijas un perfil de pagos o que crees uno.

      La API Monitoring está habilitada de forma predeterminada en los proyectos nuevos.

    • Si ya tienes un Google Cloud proyecto, asegúrate de que la API Monitoring esté habilitada:

      1. Vaya a APIs y servicios:

        Ve a APIs y servicios.

      2. Selecciona el proyecto.

      3. Haz clic en Habilitar APIs y servicios.

      4. Busca "Monitorización".

      5. En los resultados de búsqueda, haz clic en "API Cloud Monitoring".

      6. Si no se muestra "API habilitada", haz clic en el botón Habilitar.

  • Un clúster de Kubernetes. Si no tienes un clúster de Kubernetes, sigue las instrucciones de la guía de inicio rápido de GKE.

También necesitas las siguientes herramientas de línea de comandos:

  • gcloud
  • kubectl

Las herramientas gcloud y kubectl forman parte de Google Cloud CLI. Para obtener información sobre cómo instalarlos, consulta Gestionar componentes de Google Cloud CLI. Para ver los componentes de la CLI de gcloud que tienes instalados, ejecuta el siguiente comando:

gcloud components list

Configurar el entorno

Para no tener que introducir repetidamente el ID del proyecto o el nombre del clúster, haz la siguiente configuración:

  • Configura las herramientas de línea de comandos de la siguiente manera:

    • Configura gcloud CLI para que haga referencia al ID de tu proyectoGoogle Cloud :

      gcloud config set project PROJECT_ID

    • Configura la CLI de kubectl para que use tu clúster:

      kubectl config set-cluster CLUSTER_NAME

    Para obtener más información sobre estas herramientas, consulta los siguientes artículos:

Configurar un espacio de nombres

Crea el espacio de nombres de Kubernetes NAMESPACE_NAME para los recursos que crees como parte de la aplicación de ejemplo:

kubectl create ns NAMESPACE_NAME

Verificar las credenciales de la cuenta de servicio

Si tu clúster de Kubernetes tiene habilitada la federación de identidades de carga de trabajo para GKE, puedes saltarte esta sección.

Cuando se ejecuta en GKE, Managed Service para Prometheus obtiene automáticamente las credenciales del entorno en función de la cuenta de servicio predeterminada de Compute Engine. La cuenta de servicio predeterminada tiene los permisos necesarios, monitoring.metricWriter y monitoring.viewer, de forma predeterminada. Si no usas Workload Identity Federation para GKE y has quitado alguno de esos roles de la cuenta de servicio de nodo predeterminada, tendrás que volver a añadir los permisos que faltan antes de continuar.

Configurar una cuenta de servicio para Workload Identity Federation for GKE

Si tu clúster de Kubernetes no tiene habilitada la federación de identidades de carga de trabajo para GKE, puedes saltarte esta sección.

Managed Service para Prometheus captura datos de métricas mediante la API de Cloud Monitoring. Si tu clúster usa la federación de Workload Identity para GKE, debes conceder permiso a tu cuenta de servicio de Kubernetes para usar la API Monitoring. En esta sección se describe lo siguiente:

Crear y vincular la cuenta de servicio

Este paso aparece en varios lugares de la documentación de Managed Service para Prometheus. Si ya has completado este paso en una tarea anterior, no tienes que repetirlo. Vaya a la sección Autorizar la cuenta de servicio.

La siguiente secuencia de comandos crea la cuenta de servicio gmp-test-sa y la vincula a la cuenta de servicio predeterminada de Kubernetes en el espacio de nombres NAMESPACE_NAME:

gcloud config set project PROJECT_ID \
&&
gcloud iam service-accounts create gmp-test-sa \
&&
gcloud iam service-accounts add-iam-policy-binding \
  --role roles/iam.workloadIdentityUser \
  --member "serviceAccount:PROJECT_ID.svc.id.goog[NAMESPACE_NAME/default]" \
  gmp-test-sa@PROJECT_ID.iam.gserviceaccount.com \
&&
kubectl annotate serviceaccount \
  --namespace NAMESPACE_NAME \
  default \
  iam.gke.io/gcp-service-account=gmp-test-sa@PROJECT_ID.iam.gserviceaccount.com

Si usas un espacio de nombres o una cuenta de servicio de GKE diferentes, ajusta los comandos según corresponda.

Autorizar la cuenta de servicio

Los grupos de permisos relacionados se recogen en roles, y tú asignas los roles a una entidad principal, en este ejemplo, la Google Cloudcuenta de servicio. Para obtener más información sobre los roles de Monitoring, consulta Control de acceso.

El siguiente comando concede a la cuenta de servicio Google Cloud , gmp-test-sa, los roles de la API Monitoring que necesita para escribir datos de métricas.

Si ya has concedido un rol específico a la Google Cloud cuenta de servicio como parte de una tarea anterior, no es necesario que lo hagas de nuevo.

gcloud projects add-iam-policy-binding PROJECT_ID\
  --member=serviceAccount:gmp-test-sa@PROJECT_ID.iam.gserviceaccount.com \
  --role=roles/monitoring.metricWriter

Depurar la configuración de Workload Identity Federation para GKE

Si tienes problemas para que funcione Workload Identity Federation para GKE, consulta la documentación sobre cómo verificar la configuración de Workload Identity Federation para GKE y la guía para solucionar problemas de Workload Identity Federation para GKE.

Como las erratas y las acciones de copiar y pegar parciales son las fuentes de errores más habituales al configurar la federación de identidades de carga de trabajo para GKE, te recomendamos encarecidamente que uses las variables editables y los iconos de copiar y pegar en los que se puede hacer clic que se incluyen en los ejemplos de código de estas instrucciones.

Workload Identity Federation para GKE en entornos de producción

En el ejemplo que se describe en este documento, se vincula la Google Cloud cuenta de servicio Google Clouda la cuenta de servicio predeterminada de Kubernetes y se le otorgan todos los permisos necesarios para usar la API Monitoring.

En un entorno de producción, puede que quieras usar un enfoque más detallado, con una cuenta de servicio para cada componente, cada una con permisos mínimos. Para obtener más información sobre cómo configurar cuentas de servicio para la gestión de identidades de cargas de trabajo, consulta Usar Workload Identity Federation para GKE.

Configurar la recogida con despliegue automático

En esta sección se describe cómo configurar y ejecutar una aplicación de ejemplo que usa la recogida autodesplegada.

Desplegar la aplicación de ejemplo

La aplicación de ejemplo emite la métrica de contador example_requests_total y la métrica de histograma example_random_numbers (entre otras) en su puerto metrics. El archivo de manifiesto de la aplicación define tres réplicas.

Para desplegar la aplicación de ejemplo, ejecuta el siguiente comando:

kubectl -n NAMESPACE_NAME apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/prometheus-engine/v0.15.3/examples/example-app.yaml

Ejecuta el binario de Prometheus de sustitución

Para ingerir los datos de métricas emitidos por la aplicación de ejemplo, debes desplegar la versión bifurcada de Google del servidor de Prometheus, que está configurada para recoger las métricas de la carga de trabajo, así como su propio endpoint de métricas.

  1. Para desplegar el servidor bifurcado, ejecuta el siguiente comando:

    kubectl -n NAMESPACE_NAME apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/prometheus-engine/v0.15.3/examples/prometheus.yaml

    El servidor de Prometheus desplegado es una bifurcación ligera del binario de Prometheus upstream. Se comporta como un servidor de Prometheus estándar, pero también ingiere datos en Managed Service para Prometheus.

    El manifiesto anterior proporciona un ejemplo básico que envía datos al almacén de datos global, Monarch. No almacena de forma persistente una copia local de los datos. Para obtener información sobre cómo funciona esta configuración predefinida y cómo ampliarla, consulta la documentación de configuración de Prometheus de código abierto.

    La imagen precompilada solo funciona en nodos Linux. Para raspar los destinos que se ejecutan en nodos de Windows, puedes desplegar el servidor en un nodo de Linux y configurarlo para que raspe los endpoints de los nodos de Windows o compilar el archivo binario para Windows.

  2. Verifica que los pods del servidor de Prometheus y de la aplicación de ejemplo se hayan desplegado correctamente:

    kubectl -n NAMESPACE_NAME get pod

    Si el despliegue se ha realizado correctamente, verás un resultado similar al siguiente:

    NAME                            READY   STATUS    RESTARTS   AGE
prom-example-84c6f547f5-fglbr   1/1     Running   0          5m
prom-example-84c6f547f5-jnjp4   1/1     Running   0          5m
prom-example-84c6f547f5-sqdww   1/1     Running   0          5m
prometheus-test-0               2/2     Running   1          3m

Si utilizas GKE, puedes hacer lo siguiente:

Si no usas GKE, debes crear una cuenta de servicio y autorizarla para que escriba tus datos de métricas, tal como se describe en la siguiente sección.

Proporcionar credenciales explícitamente

Cuando se ejecuta en GKE, el servidor de Prometheus que recoge datos obtiene automáticamente las credenciales del entorno en función de la cuenta de servicio del nodo o de la configuración de Workload Identity Federation para GKE. En los clústeres de Kubernetes que no son de GKE, las credenciales se deben proporcionar explícitamente al servidor de Prometheus que recoge los datos mediante marcas o la variable de entorno GOOGLE_APPLICATION_CREDENTIALS.

  1. Define el contexto de tu proyecto de destino:

    gcloud config set project PROJECT_ID

  2. Crea una cuenta de servicio:

    gcloud iam service-accounts create gmp-test-sa

    En este paso se crea la cuenta de servicio que puede que ya hayas creado en las instrucciones de Workload Identity Federation para GKE.

  3. Concede los permisos necesarios a la cuenta de servicio:

    gcloud projects add-iam-policy-binding PROJECT_ID\
  --member=serviceAccount:gmp-test-sa@PROJECT_ID.iam.gserviceaccount.com \
  --role=roles/monitoring.metricWriter

  4. Crea y descarga una clave para la cuenta de servicio:

    gcloud iam service-accounts keys create gmp-test-sa-key.json \
  --iam-account=gmp-test-sa@PROJECT_ID.iam.gserviceaccount.com

  5. Añade el archivo de claves como secreto a tu clúster que no sea de GKE:

    kubectl -n NAMESPACE_NAME create secret generic gmp-test-sa \
  --from-file=key.json=gmp-test-sa-key.json

  6. Abre el recurso StatefulSet de Prometheus para editarlo:

    kubectl -n NAMESPACE_NAME edit statefulset prometheus-test

    1. Añade el texto que se muestra en negrita al recurso:

      apiVersion: apps/v1
kind: StatefulSet
metadata:
  namespace: NAMESPACE_NAME
  name: example
spec:
  template
    containers:
    - name: prometheus
      args:
      - --export.credentials-file=/gmp/key.json
...
      volumeMounts:
      - name: gmp-sa
        mountPath: /gmp
        readOnly: true
...
    volumes:
    - name: gmp-sa
      secret:
        secretName: gmp-test-sa
...

    2. Guarda el archivo y cierra el editor. Una vez aplicado el cambio, los pods se vuelven a crear y empiezan a autenticarse en el backend de métricas con la cuenta de servicio proporcionada.

    También puedes definir la ruta del archivo de claves mediante la variable de entorno GOOGLE_APPLICATION_CREDENTIALS en lugar de usar las marcas definidas en este ejemplo.

    Temas adicionales sobre la recogida con despliegue automático

    En esta sección se describe cómo hacer lo siguiente:

    • Filtra los datos que exportas al servicio gestionado.
    • Convierte tus configuraciones de implementación.
    • Ejecuta el archivo binario de Prometheus en modo de alta disponibilidad.
    • Compila y ejecuta el binario de Prometheus de sustitución.
    • Ejecuta Managed Service para Prometheus fuera de Google Cloud.

    Filtrar métricas exportadas

    Si recoges muchos datos, puede que quieras evitar que se envíen algunas series temporales a Managed Service para Prometheus para reducir los costes.

    Puedes usar configuraciones de reetiquetado de métricas normales en tu configuración de extracción de Prometheus. Con las configuraciones de reetiquetado, puedes eliminar métricas en función de las coincidencias de etiquetas en el momento de la ingestión.

    En ocasiones, puede que quieras ingerir datos de forma local, pero no exportarlos a Managed Service para Prometheus. Para filtrar las métricas exportadas, puede usar la marca --export.match.

    La marca especifica uno o varios selectores de series de PromQL y se puede usar varias veces. Una serie temporal se exporta a Managed Service para Prometheus si cumple todos los selectores de al menos una de las marcas. Es decir, a la hora de determinar si cumple los requisitos, las condiciones de una misma marca se combinan con el operador lógico AND, mientras que las condiciones de marcas diferentes se combinan con el operador lógico OR. En el siguiente ejemplo se usan dos instancias de la marca:

    ./prometheus \
  --export.match='{job="prometheus"}' \
  --export.match='{__name__=~"job:.+"}' \
  ...

    Con este cambio, solo se exportarán las métricas del trabajo "prometheus", así como las métricas producidas por las reglas de registro que se agregan a nivel de trabajo (si se siguen las prácticas recomendadas de nomenclatura). Se excluyen las muestras de todas las demás series. De forma predeterminada, no se especifica ningún selector y se exportan todas las series temporales.

    La marca --export.match tiene la misma semántica que el parámetro match[] en la federación de Prometheus. Por lo tanto, puedes migrar configuraciones de federación a Managed Service para Prometheus usando los selectores de tu servidor de federación directamente como marcas en los servidores de Prometheus recogidos por tu servidor de federación de Prometheus. No se admite la exportación de métricas de un servidor de federación al servicio gestionado.

    Para incluir métricas de tipo histogram en un filtro, debe especificar las métricas _count, _sum y _bucket. También puedes hacerlo con un buscador de comodines, como el selector {__name__=~"histogram_metric_.+"}.

    Si usas la biblioteca prometheus-operator, define las marcas --export.match con la variable de entorno EXTRA_ARGS del contenedor. Para obtener más información, consulta Usar con prometheus-operator.

    Puedes combinar marcas de filtro con reglas de registro ejecutadas localmente para agregar datos antes de enviarlos a Monarch, lo que reduce la cardinalidad y los costes. Para obtener más información, consulta Controles de costes y atribución.

    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 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.

    Usar con prometheus-operator

    El binario de Prometheus de Managed Service para Prometheus también se puede usar con un despliegue de Prometheus de GKE gestionado por prometheus-operator.

    Para usar el archivo binario del servicio gestionado, sustituye la especificación de la imagen en el recurso de Prometheus:

      apiVersion: monitoring.coreos.com/v1
  kind: Prometheus
  metadata:
    name: NAMESPACE_NAME
    namespace: gmp-system
  spec:
    image: gke.gcr.io/prometheus-engine/prometheus:v2.53.4-gmp.0-gke.1
    ...
    replicas: 1
    serviceAccountName: default
    version: v2.35.0
    ...

    Si estás en un clúster de Workload Identity Federation para GKE y el espacio de nombres o la cuenta de servicio de tu recurso son diferentes, repite las instrucciones de Workload Identity Federation para GKE para el espacio de nombres y la cuenta de servicio de Kubernetes adicionales.

    Si se ejecuta en un clúster de Kubernetes que no sea de GKE, debes proporcionar las credenciales manualmente. Para proporcionar las credenciales, sigue estos pasos:

    1. Añade un archivo de clave de cuenta de servicio adecuado como secreto, tal como se describe en Proporcionar credenciales explícitamente.

    2. Modifica el recurso de Prometheus para añadir el texto que se muestra en negrita:

        apiVersion: monitoring.coreos.com/v1
  kind: Prometheus
  metadata:
    namespace: NAMESPACE_NAME
    name: example
  spec:
    ...
    secrets:
    - gmp-test-sa
    containers:
    - name: prometheus
      env:
      - name: GOOGLE_APPLICATION_CREDENTIALS
        value: /gmp/key.json
      volumeMounts:
      - name: secret-gmp-test-sa
        mountPath: /gmp
        readOnly: true

    Puede definir la variable de entorno EXTRA_ARGS del contenedor para añadir marcas adicionales, como las marcas de filtrado de métricas. Esto se hace a través de una variable de entorno porque la sección args de la especificación del contenedor la gestiona Prometheus Operator.

    Usar con kube-prometheus

    Puedes configurar las implementaciones creadas con la popular biblioteca kube-prometheus para que usen Managed Service para Prometheus.

    Kube-prometheus tiene algunas dependencias internas estrictas en sus espacios de nombres y cuentas de servicio predeterminados, por lo que te recomendamos que solo cambies el número mínimo de campos necesario para enviar datos a Managed Service para Prometheus.

    En manifests/prometheus-prometheus.yaml, sustituye la especificación de la imagen y desactiva la recogida de alta disponibilidad reduciendo replicas a 1:

        apiVersion: monitoring.coreos.com/v1
    kind: Prometheus
    ...
    spec:
      image: gke.gcr.io/prometheus-engine/prometheus:v2.53.4-gmp.0-gke.1
      ...
      replicas: 1
      version: v2.35.0
      ...

    Si se ejecuta en GKE y no ha modificado la cuenta de servicio predeterminada del nodo, al aplicar los manifiestos modificados, se debería empezar a enviar datos a Managed Service para Prometheus inmediatamente. De lo contrario, es posible que tengas que configurar y aplicar una cuenta de servicio. Cuando se ejecuta en GKE y se usa Workload Identity, es posible que tengas que crear y autorizar la cuenta de servicio prometheus-k8s en el espacio de nombres monitoring. Si se ejecuta en un clúster de Kubernetes que no sea de GKE, siga las instrucciones de la sección prometheus-operator.

    Ten en cuenta que kube-prometheus recoge muchas métricas de forma predeterminada, la mayoría de las cuales no suelen ser necesarias en un entorno de Kubernetes gestionado como GKE. Para ahorrar costes de ingesta, puedes personalizar kube-prometheus para que solo recoja las métricas que te interesen y filtre las métricas exportadas de forma agresiva.

    Para ver más sugerencias, consulta Controles de costes y atribución.

    Implementación de alta disponibilidad

    El binario de Prometheus de sustitución incluye compatibilidad integrada con la recopilación de alta disponibilidad mediante la elección de líder. Los servidores de Prometheus replicados en modo de alta disponibilidad recogen métricas y evalúan reglas como de costumbre, pero solo uno de ellos envía datos a Google Cloud Managed Service para Prometheus.

    Las réplicas del mismo servidor de Prometheus siempre deben tener configuraciones idénticas, incluido el mismo external_labels. Este requisito es diferente al de otros sistemas, que se basan en una etiqueta externa especial, como __replica__, para que las réplicas sean explícitamente diferentes.

    El servidor de la API de Kubernetes es un backend de elección de líder compatible y se puede habilitar configurando las siguientes marcas:

    ./prometheus
  ...
  --export.ha.backend=kube \
  --export.ha.kube.namespace=LEASE_NAMESPACE \
  --export.ha.kube.name=LEASE_NAME

    Los valores LEASE_NAMESPACE y LEASE_NAME identifican el recurso de concesión a través del cual se lleva a cabo la elección del líder. Todos los servidores de Prometheus que apuntan al mismo recurso pertenecen al mismo conjunto de réplicas. La cuenta de servicio de Kubernetes de la implementación de Prometheus necesita permiso para leer y escribir el recurso Lease correspondiente. Si ejecutas el servidor de Prometheus fuera de un clúster de Kubernetes, puedes proporcionar una configuración explícita mediante la marca --export.ha.kube.config.

    Después de hacerlo, puedes aumentar el valor de replicas a 2 o más.

    Etiquetas reservadas

    Managed Service para Prometheus usa seis etiquetas reservadas para identificar de forma única un recurso en Monarch:

    • project_id: identificador del Google Cloud proyecto asociado a tu métrica. Obligatorio.
    • location: la ubicación física (Google Cloud región) donde se almacenan los datos. Este valor suele ser la región de tu clúster de GKE. Si los datos se recogen de una implementación de AWS o local, el valor puede ser la región de Google Cloud más cercana. Obligatorio.
    • cluster: nombre del clúster de Kubernetes asociado a la métrica. Si no se ejecuta en Kubernetes, se puede usar como un nivel de jerarquía arbitrario, como un grupo de instancias. Es opcional, pero muy recomendable.
    • namespace: nombre del espacio de nombres de Kubernetes asociado a la métrica. Si no se ejecuta en Kubernetes, se puede usar como un nivel de jerarquía arbitrario, como un subgrupo de instancias. Es opcional, pero muy recomendable.
    • job: la etiqueta de trabajo del destino de Prometheus, si se conoce. Puede estar vacía en los resultados de la evaluación de reglas. Obligatorio y, por lo general, añadido automáticamente por Prometheus.
    • instance: etiqueta de instancia del destino de Prometheus, si se conoce. Puede estar vacía en los resultados de la evaluación de reglas. Obligatorio y, por lo general, añadido automáticamente por Prometheus. Si se definen o se vuelven a etiquetar manualmente, no uses valores codificados, como localhost, ya que esto provoca colisiones de series temporales.

    Cuando se ejecuta en Google Cloud, las etiquetas project_id, location y cluster se añaden automáticamente a todas las métricas.

    Aunque no se recomienda cuando se ejecuta en Google Cloud, puedes anular las etiquetas project_id, location, cluster y namespace mediante la sección global.external_labels de tu configuración de Prometheus. Para obtener más información, consulta Ejecutar la recogida autodesplegada fuera deGoogle Cloud.

    Si usa alguna etiqueta reservada como etiqueta de métrica, la recogida autodesplegada usará la etiqueta de métrica como valor de la etiqueta reservada. Esto puede ofrecer cierta flexibilidad, pero también puede provocar errores si, por ejemplo, usas la etiqueta location para hacer referencia a algo que no sea unaGoogle Cloud región.

    Configurar statsd_exporter y otros exportadores que registren métricas de forma centralizada

    Si usas statsd_exporter para Prometheus, Envoy para Istio, SNMP exporter, Prometheus Pushgateway o kube-state-metrics, o bien tienes otro exportador similar que intermedia y registra métricas en nombre de otros recursos que se ejecutan en tu entorno, debes hacer algunos cambios pequeños para que tu exportador funcione con Managed Service para Prometheus.

    Para obtener instrucciones sobre cómo configurar estos exportadores, consulta esta nota de la sección Solución de problemas.

    Implementaciones binarias

    Si quieres ejecutarlo en un entorno no contenedorizado, puedes compilar el archivo binario de Prometheus de sustitución directamente.

    Compilar el código fuente

    Si ya tienes un proceso para compilar Prometheus, puedes sustituir de forma transparente nuestro repositorio de GitHub en tu proceso. Managed Service para Prometheus tiene su propia extensión de etiqueta de versión para distinguir sus lanzamientos de los lanzamientos de la versión upstream.

    Para compilar el archivo binario sin formato, se deben instalar en el equipo la cadena de herramientas de Go y versiones recientes de NPM o Yarn. Para obtener más información, consulta las instrucciones de compilación upstream.

    1. Clona el repositorio:

      git clone https://github.com/GoogleCloudPlatform/prometheus &&
cd prometheus

    2. Elige la etiqueta de la versión que te interesa:

      git checkout v2.53.4-gmp.0

    3. Para crear un archivo tar de Managed Service para Prometheus, ejecuta los siguientes comandos:

      make build && make tarball

    El archivo tar.gz y los archivos binarios resultantes son totalmente compatibles con sus variantes upstream en cuanto a estructura de directorios y funcionalidad.

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

    Managed Service para Prometheus aplica un límite de frecuencia por minuto a la hora de crear métricas y de añadir etiquetas de métricas a métricas ya creadas. 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.

    Para obtener más información, consulta Solución de problemas.

    Ejecutar la recogida autodesplegada fuera de Google Cloud

    En entornos de Compute Engine, entornos de GKE o en una máquina en la que hayas ejecutado gcloud login con una cuenta suficientemente autorizada, puedes ejecutar la recogida autodesplegada sin necesidad de realizar más configuraciones. Fuera de Google Cloud, debes proporcionar explícitamente credenciales, un project_id que contenga tus métricas y un location (regiónGoogle Cloud ) para almacenar tus métricas. También debes definir las etiquetas cluster y namespace, aunque se ejecute en un entorno que no sea de Kubernetes.

    Puedes proporcionar una clave de cuenta de servicio mediante la marca --export.credentials-file o la variable de entorno GOOGLE_APPLICATION_CREDENTIALS, tal como se describe en la sección Proporcionar credenciales explícitamente.

    Te recomendamos que elijas project_id en función del modelo de tenencia que tengas previsto para las lecturas. Elige un proyecto en el que almacenar las métricas en función de cómo quieras organizar las lecturas más adelante con los ámbitos de métricas. Si no te importa, puedes ponerlo todo en un proyecto.

    En el caso de location, te recomendamos que elijas la región Google Cloud más cercana a tu implementación. Cuanto más lejos esté la región elegida de tu implementación, mayor será la latencia de escritura y más te afectarán los posibles problemas de red. Google Cloud Puede consultar esta lista de regiones de varias nubes. Si no te importa, puedes ponerlo todo en una Google Cloud región. No puedes usar global como tu ubicación.

    Si se ejecuta en un entorno de Kubernetes, define los valores cluster y namespace en el clúster y el espacio de nombres locales. Si se ejecuta fuera de Kubernetes, asígnales valores que tengan sentido jerárquicamente. Por ejemplo, en un entorno basado en máquinas virtuales que se ejecute en AWS, defina el valor de cluster en __aws__ y el valor de namespace en el ID de la instancia. Puedes rellenar dinámicamente el ID de instancia mediante una regla de reetiquetado que llame al servidor de metadatos local.

    Para ver un ejemplo de funcionamiento mínimo, puedes ejecutar un archivo binario de Prometheus local y de automonitorización con el siguiente comando:

    ./prometheus \
  --config.file=documentation/examples/prometheus.yaml \
  --export.label.project-id=PROJECT_ID \
  --export.label.location=REGION \
  --export.label.cluster=CLUSTER_NAME \

    En este ejemplo, se presupone que ha asignado a la variable REGION un valor como us-central1.

    Sin embargo, te recomendamos que definas las etiquetas de destino export del servicio gestionado en la sección global.external_labels de tu configuración de Prometheus. Por ejemplo, en entornos de Kubernetes, puedes usar la siguiente configuración:

    global:
  external_labels:
    project_id: PROJECT_ID
    location: REGION
    cluster: CLUSTER_NAME
    namespace: local-testing

scrape_configs:
  ...

    Si ejecutas el servicio gestionado de Prometheus fuera de Google Cloud , se te cobrarán tarifas por transferencia de datos. Se aplican tarifas por transferir datos a Google Cloud, y es posible que se te cobren tarifas por transferir datos desde otra nube. Puedes minimizar este coste habilitando la compresión con la marca --export.compression=gzip.

    Siguientes pasos