Comienza con la recopilación autoimplementada.

En este documento, se describe cómo configurar el Google Cloud Managed Service para Prometheus con la recopilación autoimplementada. Un ejemplo de aplicación se implementa en un clúster de Kubernetes y se supervisa mediante un servidor de Prometheus que almacena métricas recopiladas en MongoDB.

Este documento te muestra cómo hacer lo siguiente:

  • Configurar el entorno y las herramientas de línea de comandos.
  • Configura una cuenta de servicio para los clústeres habilitados para Workload Identity.
  • Ejecuta el objeto binario directo de Prometheus en Kubernetes.
  • Controla qué métricas se transfieren al servicio administrado para Prometheus.
  • Integra el servicio administrado para Prometheus con las opciones de configuración del operador de Prometheus.
  • Compila y ejecuta manualmente el objeto binario de Prometheus.

Con la recopilación de datos implementada de forma automática, administras tu instalación de Prometheus como siempre. La única diferencia es que ejecutas el servicio administrado para el objeto binario de reemplazo directo de Prometheus, gke.gcr.io/prometheus-engine/prometheus:v2.45.3-gmp.7-gke.0, en lugar del objeto binario de Prometheus ascendente.

El objeto binario directo 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.

El servicio administrado para Prometheus no admite la exportación de métricas desde un servidor de federación o desde un servidor que se usa como receptor de escritura remota. Puedes replicar todas las funciones del servidor de la federación, incluida la reducción del volumen de transferencia si agregas datos antes de enviarlos a Monarch mediante los filtros y las agregaciones locales.

La transmisión de datos a Managed Service para Prometheus consume recursos adicionales. Si autoimplementas colectores, recomendamos aumentar los límites de CPU y memoria 5 veces y ajustarlos en función del uso real.

Para obtener más información sobre la recopilación de datos administrados y autoimplementados, consulta Recopilación de datos con Managed Service for Prometheus.

Antes de comenzar

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

Configura proyectos y herramientas

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

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

    • Si no tienes un proyecto de Google Cloud, haz lo siguiente:

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

        Crear un proyecto nuevo

      2. En el campo Nombre del proyecto, ingresa un nombre para tu proyecto y, luego, 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 solicitará que elijas un perfil de pagos existente o que crees uno nuevo.

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

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

      1. Ve a API y servicios:

        Ir a API y servicios (APIs & Services)

      2. Selecciona tu proyecto.

      3. Haga clic en Habilitar API y servicios.

      4. Busca “Monitoring”.

      5. En los resultados de la búsqueda, haz clic en "API de 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 en la Guía de inicio rápido para GKE.

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

  • gcloud
  • kubectl

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

gcloud components list

Configura tu entorno

Para evitar ingresar repetidamente el ID del proyecto o el nombre del clúster, realiza la siguiente configuración:

  • Configura las herramientas de línea de comandos como se indica a continuación:

    • Configura la CLI de gcloud para hacer referencia al ID del proyecto de Google Cloud:

      gcloud config set project PROJECT_ID

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

      kubectl config set-cluster CLUSTER_NAME

    Para obtener más información sobre estas herramientas, consulta lo siguiente:

Configura un espacio de nombres

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

kubectl create ns NAMESPACE_NAME

Verifica las credenciales de la cuenta de servicio

Puedes omitir esta sección si tu clúster de Kubernetes tiene habilitada Workload Identity.

Cuando se ejecuta en GKE, el servicio administrado para Prometheus recupera credenciales de forma automática 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 y ya quitaste cualquiera de esas funciones de la cuenta de servicio de nodo predeterminada, tendrás que volver a agregar esos permisos faltantes antes de continuar.

Si no ejecutas en GKE, consulta Proporciona credenciales explícitamente.

Configura una cuenta de servicio para Workload Identity

Puedes omitir esta sección si tu clúster de Kubernetes no tiene habilitada Workload Identity.

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

Crea y vincula la cuenta de servicio

Este paso aparece en varios lugares en la documentación del servicio administrado para Prometheus. Si ya realizaste este paso como parte de una tarea anterior, no es necesario que lo repitas. Ve a la sección Autoriza la cuenta de servicio.

Con la siguiente secuencia de comandos, se crea la cuenta de servicio gmp-test-sa y se la vincula a la cuenta de servicio de Kubernetes predeterminada 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 de forma adecuada.

Autoriza la cuenta de servicio

Los grupos de permisos relacionados se recopilan en funciones y se otorgan las funciones a una principal, en este ejemplo, la cuenta de servicio de Google Cloud. Para obtener más información sobre las funciones de Monitoring, consulta Control de acceso.

Con el siguiente comando, se otorga a la cuenta de servicio de Google Cloud, gmp-test-sa, las funciones de la API de Monitoring que necesita para leer datos de métricas.

Si ya otorgaste a la cuenta de servicio de Google Cloud una función específica como parte de la tarea anterior, no necesitas volver a hacerlo.

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

Depura la configuración de Workload Identity

Si tienes problemas para lograr que Workload Identity funcione, consulta la documentación a fin de verificar la configuración de Workload Identity y la Guía de solución de problemas de Workload Identity.

Como los errores tipográficos y de copia parcial son las fuentes de errores más comunes en la configuración de Workload Identity, recomendamos usar las variables editables y los íconos de copiar y pegar en los que se puede hacer clic incorporados en las muestras de código de estas instrucciones.

Workload Identity en entornos de producción

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

En un entorno de producción, se recomienda usar un enfoque más detallado, con una cuenta de servicio para cada componente, cada una con permisos mínimos. Si deseas obtener más información sobre la configuración de cuentas de servicio para la administración de identidades de cargas de trabajo, consulta Usa Workload Identity.

Configura la colección autoimplementada

En esta sección, se describe cómo configurar y ejecutar una aplicación de ejemplo que usa la colección implementada de forma automática.

Implementa 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 manifiesto para la aplicación define tres réplicas.

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

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

Ejecuta el objeto binario de Prometheus de reemplazo

Para transferir los datos de métrica que emite la aplicación de ejemplo, implementa la versión bifurcada de Google del servidor de Prometheus, que está configurado para recopilar las métricas de la carga de trabajo y su propio extremo de métrica.

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

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

    Este servidor de Prometheus implementado es una bifurcación delgada del objeto binario de Prometheus ascendente. Se comporta como un servidor estándar de Prometheus, pero también transfiere datos al servicio administrado para Prometheus.

    El manifiesto anterior proporciona un ejemplo funcional básico que envía datos al almacén de datos global, Monarch. No se 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 extenderla, consulta la documentación de configuración de Prometheus de código abierto.

    La imagen compilada de manera previa solo funciona en nodos de Linux. Para recopilar los objetivos que se ejecutan en nodos de Windows, implementa el servidor en un nodo de Linux y configúralo para recopilar extremos en los nodos de Windows o compila el objeto binario para Windows.

  2. Verifica que los pods para el servidor de Prometheus y la aplicación de ejemplo se hayan implementado de forma correcta:

    kubectl -n NAMESPACE_NAME get pod

    Si la implementación se realizó de forma correcta, 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 ejecutas en GKE, puedes hacer lo siguiente:

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

Proporciona credenciales de forma explícita

Cuando se ejecuta en GKE, el servidor de recopilación de Prometheus recupera credenciales de forma automática del entorno según la cuenta de servicio del nodo o la configuración de Workload Identity. En los clústeres de Kubernetes que no son de GKE, las credenciales deben proporcionarse de forma explícita al servidor de Prometheus para recopilar marcas o la variable de entorno GOOGLE_APPLICATION_CREDENTIALS.

  1. Configura el contexto en tu proyecto de destino:

    gcloud config set project PROJECT_ID

  2. Crear una cuenta de servicio:

    gcloud iam service-accounts create gmp-test-sa

    En este paso, se crea la cuenta de servicio que puedes haber creado ya en las instrucciones de Workload Identity.

  3. Otorga permisos obligatorios 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. Agrega el archivo de claves como un secreto a tu clúster que no es 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. Agrega 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. Después de aplicar el cambio, los Pods se vuelven a crear y comienzan a autenticarse en el backend de la métrica con la cuenta de servicio determinada.

    Como alternativa, en lugar de usar las marcas establecidas en este ejemplo, puedes establecer la ruta del archivo de claves mediante la variable de entorno GOOGLE_APPLICATION_CREDENTIALS.

    Temas adicionales para la recopilación autoimplementada

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

    • Filtra los datos que exportas al servicio administrado.
    • Convertir tus opciones de configuración de implementación existentes
    • Ejecuta el objeto binario de Prometheus en modo de alta disponibilidad.
    • Compila y ejecuta el objeto binario de Prometheus de reemplazo.
    • Ejecuta Managed Service para Prometheus fuera de Google Cloud.

    Filtrar métricas exportadas

    Si recopilas muchos datos, es recomendable que evites que algunas series temporales se envíen al servicio administrado para Prometheus a fin de mantener los costos bajos.

    Puedes usar las opciones de configuración de etiquetado de métricas regulares en la configuración de recopilación de Prometheus. Con el reetiquetado de las opciones de configuración, puedes descartar métricas según las coincidencias de etiquetas en el momento de la transferencia.

    A veces, te recomendamos transferir datos de forma local, pero no exportarlos al servicio administrado para Prometheus. Para filtrar las métricas exportadas, puedes usar la marca --export.match.

    La marca especifica uno o más selectores de serie de PromQL y se puede usar varias veces. Se exporta una serie temporal al servicio administrado para Prometheus si cumple con todos los selectores en al menos una de las marcas. Es decir, cuando se determina la elegibilidad, las condiciones dentro de una sola marca se evalúan con AND, mientras que las condiciones en marcas separadas se evalúan con OR. En el siguiente ejemplo, se usan dos instancias de la marca:

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

    Este cambio solo genera métricas para el trabajo “prometheus” y las métricas producidas que generan las reglas de grabación que se agregan a nivel del trabajo (cuando se siguen las prácticas recomendadas de la asignación de nombres) que se exportarán. Se filtran las muestras de todas las demás series temporales. De forma predeterminada, no se especifican selectores y se exportan todas las series temporales.

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

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

    Si usas la biblioteca prometheus-operator, configura cualquier Marcas --export.match con la variable de entorno EXTRA_ARGS del de Docker. Para obtener más información, consulta Uso con operador de Prometheus.

    Puedes combinar marcas de filtro con reglas de grabación ejecutadas de manera local para “consolidar” los datos antes de enviarlos a Monarch, lo que reduce la cardinalidad y el costo. Para obtener más información, consulta Controles de costos y atribución.

    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 cobrables 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.
    • Uso de métricas en políticas de alertas y paneles personalizados.
    • Tasa de errores de escritura de métricas.
    Para obtener más información sobre la página Administración de métricas, consulta Visualiza y administra el uso de métricas.

    Uso con operador de Prometheus

    El servicio administrado para el objeto binario de Prometheus de Prometheus también se puede usar con una implementación de Prometheus de GKE existente administrada por prometheus-operator.

    Para usar el objeto binario del servicio administrado, reemplaza 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.45.3-gmp.7-gke.0
    ...
    replicas: 1
    serviceAccountName: default
    version: v2.35.0
    ...

    Si te encuentras en un clúster de Workload Identity y la cuenta de servicio o espacio de nombres en tu recurso difiere, repite las instrucciones de Workload Identity para el espacio de nombres adicional y el par de la cuenta de servicio de Kubernetes.

    Cuando se ejecuta en un clúster de Kubernetes que no es de GKE, debes proporcionar credenciales de forma manual. Para proporcionar credenciales, haz lo siguiente:

    1. Agrega un archivo de claves de cuenta de servicio adecuado como un secreto, como se describe en Proporciona credenciales de forma explícita.

    2. Modifica el recurso Prometheus para agregar el texto que se muestra en negrita:

        apiVersion: monitoring.coreos.com/v1
  kind: Prometheus
  metadata:
    namespace: gmp-test
    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

    Puedes configurar la variable de entorno EXTRA_ARGS del contenedor para agregar marcas adicionales, como las marcas de filtrado de métricas. Esto se hace a través de una variable de entorno porque el operador de Prometheus administra la sección args de la especificación del contenedor.

    Uso con kube-prometheus

    Puedes configurar las implementaciones creadas con la biblioteca popular kube-prometheus para usar el servicio administrado para Prometheus.

    Kube-prometheus tiene algunas dependencias internas estrictas en sus espacios de nombres y cuentas de servicio predeterminadas, por lo que recomendamos solo cambiar la cantidad mínima de campos necesarios a fin de enviar datos al servicio administrado para Prometheus.

    Dentro de manifests/prometheus-prometheus.yaml, reemplaza la especificación de imagen y desactiva la recopilación de alta disponibilidad mediante la reducción de replicas a 1:

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

    Si ejecutas en GKE y no modificaste la cuenta de servicio predeterminada en el nodo, la aplicación de los manifiestos modificados debe comenzar a enviar datos al servicio administrado para Prometheus de inmediato. De lo contrario, es posible que debas configurar y aplicar una cuenta de servicio. Cuando se ejecuta en GKE y se usa la identidad de carga de trabajo, es posible que debas crear y autorizar la cuenta de servicio prometheus-k8s dentro del espacio de nombres monitoring. Cuando se ejecute en un clúster de Kubernetes que no sea de GKE, sigue las instrucciones en la sección de operador de Prometheus.

    Ten en cuenta que kube-prometheus recopila muchas métricas de forma predeterminada, lo que a menudo no es necesario en un entorno administrado de Kubernetes como GKE. Para ahorrar costos de transferencia, puedes personalizar kube-prometheus de modo que recopile solo las métricas que te interesan y filtre las métricas exportadas de forma agresiva.

    Para obtener más sugerencias, consulta Controles de costos y atribución.

    Implementación de alta disponibilidad

    El objeto binario de Prometheus de reemplazo incluye compatibilidad integrada para la recopilación con alta disponibilidad mediante la elección de líder. Los servidores de Prometheus replicados en modo de alta disponibilidad recopilan 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, incluidas las mismas external_labels. Este requisito difiere de otros sistemas, que dependen de una etiqueta externa especial, como __replica__, para hacer que las réplicas sean diferentes.

    El servidor de la API de Kubernetes es un backend de elección de líder y se puede habilitar si se configuran 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 asignación de tiempo mediante el cual se realiza la elección de 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 de asignación de tiempo correspondiente. Cuando 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

    El servicio administrado para Prometheus usa seis etiquetas reservadas así puede identificar de inequívoca un recurso en Monarch:

    • project_id: El identificador del proyecto de Google Cloud asociado a tu métrica. Obligatorio.
    • location: Es la ubicación física (región de Google Cloud) en la que se almacenan los datos. Este valor suele ser la región de tu clúster de GKE. Si se recopilan datos de una implementación local o de AWS, el valor puede ser la región de Google Cloud más cercana. Obligatorio.
    • cluster: El nombre del clúster de Kubernetes asociado con tu 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 altamente recomendado.
    • namespace: El nombre del espacio de nombres de Kubernetes asociado a tu 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 altamente recomendado.
    • job: La etiqueta de trabajo del destino de Prometheus, si se conoce; puede estar vacía para los resultados de la evaluación de reglas. Obligatorio y, por lo general, lo agrega Prometheus automáticamente.
    • instance: La etiqueta de la instancia del destino de Prometheus, si se conoce; puede estar vacía para los resultados de la evaluación de la regla. Obligatorio y, por lo general, lo agrega Prometheus automáticamente. Si configuras o vuelves a etiquetar de forma manual, no uses valores codificados como localhost, ya que esto provoca colisiones de series temporales.

    Cuando se ejecutan en Google Cloud, project_id, location y cluster se agregan etiquetas automáticamente a cada métrica.

    Si bien no se recomienda cuando se ejecuta en Google Cloud, puedes anular las etiquetas project_id, location, cluster y namespace con la sección global.external_labels de tu Prometheus. configuración. Para obtener más información, consulta Ejecuta la colección con implementación automática fuera de Google Cloud.

    Si usas etiquetas reservadas como etiquetas de métrica, la colección de implementación automática usará la etiqueta de métrica como el valor de la etiqueta reservada. Esto puede proporcionar cierta flexibilidad, pero también puede generar errores si, por ejemplo, usas la etiqueta location para hacer referencia a algo que no sea una región de Google Cloud.

    Implementaciones de objetos binarios

    Si deseas ejecutar en un entorno que no está alojado en contenedores, puedes compilar el objeto binario de Prometheus de reemplazo directamente.

    Compila el código fuente

    Si ya tienes un proceso para compilar Prometheus, puedes sustituir con transparencia nuestro repositorio de GitHub en tu proceso. El servicio administrado para Prometheus tiene su propia extensión de etiqueta de versión con el fin de distinguir sus versiones de actualizaciones ascendentes.

    Para compilar el objeto binario sin formato, la cadena de herramientas de Go y las versiones recientes de NPM/Yarn deben instalarse en la máquina. Para obtener más información, consulta las instrucciones de compilación ascendente.

    1. Clone el repositorio:

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

    2. Revisa la etiqueta de versión deseada:

      git checkout v2.45.3-gmp.7-gke.0

    3. A fin de crear un servicio administrado para el archivo comprimido de Prometheus, ejecuta los siguientes comandos:

      make build && make tarball

    El archivo comprimido y los objetos binarios resultantes son totalmente compatibles con sus variantes ascendentes en términos de estructura y funcionalidad del directorio.

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

    El servicio administrado para Prometheus aplica un límite de frecuencia por minuto a la creación de métricas nuevas y a la adición de etiquetas de métricas nuevas a las métricas existentes. 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.

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

    Ejecuta la colección con implementación automática fuera de Google Cloud

    En entornos de Compute Engine, entornos de GKE o en una máquina en la que ejecutaste gcloud login con una cuenta lo suficientemente autorizada, puedes ejecutar una colección autoimplementada sin configuración adicional. Fuera de Google Cloud, debes proporcionar credenciales de forma explícita, un project_id que contenga las métricas y una location (región de Google Cloud) para almacenar las métricas. También debes configurar las etiquetas cluster y namespace, incluso si se ejecuta en un entorno que no es de Kubernetes.

    Puedes proporcionar una clave de cuenta de servicio mediante la marca --export.credentials-file o la variable de entorno GOOGLE_APPLICATION_CREDENTIALS como se describe en Proporciona credenciales de forma explícita.

    Recomendamos elegir project_id en función de tu modelo de usuario planificado para las lecturas. Elige un proyecto para almacenar métricas en función de cómo planeas organizar las lecturas más tarde con permisos de métricas. Si no te importa, puedes colocar todo en un proyecto.

    Para location, te recomendamos que elijas la región de Google Cloud más cercana a tu implementación. Cuanto más lejos se encuentre la región de Google Cloud elegida de tu implementación, más latencia de escritura tendrás y más te verás afectado por posibles problemas de herramientas de redes. Es posible que desees consultar esta lista de regiones en varias nubes. Si no te importa, puedes colocar todo en una región de Google Cloud. No puedes usar global como tu ubicación.

    Si ejecutas en un entorno de Kubernetes, configura los valores cluster y namespace en el clúster local y el espacio de nombres. Si se ejecuta fuera de Kubernetes, configúralos como valores que tengan sentido de forma jerárquica. Por ejemplo, en un entorno basado en VM que se ejecuta en AWS, configura el valor cluster como __aws__ y el valor namespace como el ID de instancia. Puedes completar el ID de instancia de forma dinámica con una regla de reetiquetado que llame al servidor de metadatos local.

    Para un ejemplo funcional mínimo, puedes ejecutar un objeto binario local de Prometheus con supervisión automática mediante 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 supone que configuraste la variable REGION como un valor como us-central1.

    Sin embargo, te recomendamos que establezcas las etiquetas de destino export para el servicio administrado en la sección global.external_labels de la 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:
  ...

    La ejecución del servicio administrado para Prometheus fuera de Google Cloud genera tarifas por transferencia de datos. Se aplican tarifas por transferir datos a Google Cloud y es posible que se apliquen tarifas por transferir datos fuera de otra nube. Para minimizar este costo, habilita la compresión con la marca --export.compression=gzip.

    Próximos pasos