En este documento, se describe cómo configurar Google Cloud Managed Service para Prometheus con la recopilación administrada. La configuración es un ejemplo mínimo de transferencia de trabajo, mediante una implementación de Prometheus que supervisa una aplicación de ejemplo y almacena métricas recopiladas en Monarch.
Este documento te muestra cómo hacer lo siguiente:
- Configurar el entorno y las herramientas de línea de comandos.
- Configurar la recopilación administrada para tu clúster.
- Configurar un recurso para la recopilación de destino y la transferencia de métricas.
- Migrar los recursos personalizados de operadores de Prometheus existentes.
Te recomendamos que uses la recopilación administrada. Reduce la complejidad de implementar, escalar, fragmentar, configurar y mantener los colectores. La recopilación administrada es compatible con GKE y todos los demás entornos de Kubernetes.
La colección administrada ejecuta colectores basados en Prometheus como un Daemonset y garantiza la escalabilidad mediante la recopilación de objetivos solo en los nodos ubicados. Configura los recopiladores con recursos personalizados básicos para recopilar exportadores mediante la colección de extracción y, luego, los recopiladores envían los datos extraídos al almacén central de datos de Monarch. Google Cloud nunca accede directamente a tu clúster para extraer o recopilar datos de métricas. Los recopiladores envían datos a Google Cloud. Para obtener más información sobre la recopilación de datos administrados y autoimplementados, consulta Recopilación de datos con el servicio administrado para Prometheus y Transferencia y consultas con colección administrada y autoimplementada.
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:
En la consola de Google Cloud, ve a Proyecto Nuevo:
En el campo Nombre del proyecto, ingresa un nombre para tu proyecto y, luego, haz clic en Crear.
Ve a facturación:
Selecciona el proyecto que acabas de crear si aún no está seleccionado en la parte superior de la página.
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:
Ve a API y servicios:
Selecciona tu proyecto.
Haga clic en Habilitar API y servicios.
Busca “Monitoring”.
En los resultados de la búsqueda, haz clic en "API de Cloud Monitoring".
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
Configura la recopilación administrada
Puedes usar la colección administrada en clústeres de Kubernetes que sean de GKE y que no sean de GKE.
Después de habilitar la recopilación administrada, los componentes en el clúster se ejecutarán, pero aún no se generarán métricas. Estos componentes necesitan recursos de PodMonitoring o ClusterPodMonitoring para recopilar correctamente los extremos de las métricas. Debes implementar estos recursos con extremos de métricas válidos o habilitar uno de los paquetes de métricas administrados, por ejemplo, las métricas de estado de Kube, integradas en GKE. Para obtener información sobre la solución de problemas, consulta Problemas del lado de la transferencia.
Cuando habilitas la recopilación administrada, se instalan los siguientes componentes en tu clúster:
- La implementación
gmp-operator
, que implementa el operador de Kubernetes para el servicio administrado para Prometheus. - La implementación
rule-evaluator
, que se usa para configurar y ejecutar alertas y reglas de grabación. - El DaemonSet
collector
, que escala horizontalmente la colección mediante la recopilación de métricas solo de los Pods que se ejecutan en el mismo nodo que cada colector. - El StatefulSet de
alertmanager
, que está configurado para enviar alertas activadas a tus canales de notificaciones preferidos.
Para obtener documentación de referencia sobre el operador de servicio administrado para Prometheus, consulta la página de manifiestos.
Habilita la colección administrada: GKE
La recopilación administrada está habilitada de forma predeterminada para los siguientes elementos:
Clústeres de GKE Autopilot que ejecutan la versión 1.25 o superior de GKE.
Clústeres de GKE Standard que ejecutan la versión 1.27 o superior de GKE. Puedes anular este valor predeterminado cuando creas el clúster; Consulta Inhabilita la recopilación administrada.
Si ejecutas en un entorno de GKE que no habilita la recopilación administrada de forma predeterminada, puedes habilitar la recopilación administrada de forma manual.
La recopilación administrada en GKE se actualiza de forma automática cuando se lanzan nuevas versiones de componentes en el clúster.
La recopilación administrada en GKE usa los permisos otorgados a la cuenta de servicio predeterminada de Compute Engine. Si tienes una política que modifica los permisos estándar en la cuenta de servicio de nodo predeterminada, es posible que debas agregar el rol Monitoring Metric Writer
para continuar.
Habilita la recopilación administrada de forma manual
Si ejecutas en un entorno de GKE que no habilita la recopilación administrada de forma predeterminada, puedes habilitar la recopilación administrada con el siguiente comando:
- El panel Clústeres de GKE en Cloud Monitoring.
- La página de Kubernetes Engine en la consola de Google Cloud
- Google Cloud CLI. Para usar la CLI de gcloud, debes ejecutar la versión 1.21.4-gke.300 o posterior de GKE.
Terraform para Google Kubernetes Engine. Si quieres usar Terraform a fin de habilitar el servicio administrado para Prometheus, debes ejecutar la versión 1.21.4-gke.300 de GKE o una más reciente.
Panel de clústeres de GKE
Puedes hacer lo siguiente con el panel Clústeres de GKE en Cloud Monitoring.
- Determina si el servicio administrado para Prometheus está habilitado en tus clústeres y si usas la recopilación administrada o autoimplementada.
- Habilita la recopilación administrada en los clústeres de tu proyecto.
- Consulta otra información sobre tus clústeres.
Para ver el panel Clústeres de GKE (GKE Clusters), haz lo siguiente:
-
En la consola de Google Cloud, ve a la página Paneles.
Si usas la barra de búsqueda para encontrar esta página, selecciona el resultado cuyo subtítulo es Monitoring.
Selecciona la categoría del panel de GCP y, luego, Clústeres de GKE.
Para habilitar la recopilación administrada en uno o más clústeres de GKE con el panel de clústeres de GKE, haz lo siguiente:
Selecciona la casilla de verificación de cada clúster de GKE en el que deseas habilitar la recopilación administrada.
Selecciona Habilitar seleccionado.
IU de Kubernetes Engine
Puedes hacer lo siguiente con la consola de Google Cloud:
- Habilita la recopilación administrada en un clúster de GKE existente.
- Crea un clúster de GKE nuevo con la recopilación administrada habilitada.
Para actualizar un clúster existente, haz lo siguiente:
-
En la consola de Google Cloud, ve a la página 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.
Haz clic en el nombre del clúster.
En la lista Funciones, busca la opción Managed Service para Prometheus. Si aparece como inhabilitado, haz clic en edit Editar y, luego, selecciona Habilitar Managed Service para Prometheus.
Haga clic en Guardar cambios.
Para crear un clúster con la recopilación administrada habilitada, haz lo siguiente:
-
En la consola de Google Cloud, ve a la página 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.
Haz clic en Crear.
Haz clic en Configurar en la opción Estándar.
En el panel de navegación, haz clic en Funciones.
En la sección Operaciones, selecciona Habilitar Managed Service para Prometheus.
Haz clic en Guardar.
gcloud CLI
Puedes hacer lo siguiente con la CLI de gcloud:
- Habilita la recopilación administrada en un clúster de GKE existente.
- Crea un clúster de GKE nuevo con la recopilación administrada habilitada.
Estos comandos pueden tardar hasta 5 minutos en completarse.
Primero, configura tu proyecto:
gcloud config set project PROJECT_ID
Para actualizar un clúster existente, ejecuta uno de los siguientes comandos update
en función de si el clúster es zonal o regional:
gcloud container clusters update CLUSTER_NAME --enable-managed-prometheus --zone ZONE
gcloud container clusters update CLUSTER_NAME --enable-managed-prometheus --region REGION
Para crear un clúster con la recopilación administrada habilitada, ejecuta el siguiente comando:
gcloud container clusters create CLUSTER_NAME --zone ZONE --enable-managed-prometheus
GKE Autopilot
La colección administrada está activada de forma predeterminada en los clústeres de Autopilot de GKE que ejecutan la versión 1.25 de GKE o una versión posterior. No puedes desactivar la recopilación administrada.
Si tu clúster no puede habilitar la recopilación administrada de forma automática cuando actualizas a la versión 1.25, puedes habilitarla de forma manual mediante la ejecución del comando de actualización en la sección de la CLI de gcloud.
Terraform
A fin de obtener instrucciones para configurar la recopilación administrada mediante Terraform, consulta el registro de Terraform para google_container_cluster
.
Para obtener información general sobre el uso de Google Cloud con Terraform, consulta Terraform con Google Cloud.
Inhabilita la recopilación administrada
Si deseas inhabilitar la recopilación administrada en tus clústeres, puedes usar uno de los siguientes métodos:
IU de Kubernetes Engine
Puedes hacer lo siguiente con la consola de Google Cloud:
- Inhabilita la recopilación administrada en un clúster de GKE existente.
- Anula la habilitación automática de la recopilación administrada cuando crees un clúster de GKE Standard nuevo que ejecute la versión 1.27 o superior de GKE.
Para actualizar un clúster existente, haz lo siguiente:
-
En la consola de Google Cloud, ve a la página 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.
Haz clic en el nombre del clúster.
En la sección Funciones, busca la opción Servicio administrado para Prometheus. Haz clic en edit Editar y borra Habilitar Servicio administrado para Prometheus.
Haga clic en Guardar cambios.
Para anular la habilitación automática de la recopilación administrada cuando se crea un clúster de GKE Standard nuevo (versión 1.27 o superior), haz lo siguiente:
-
En la consola de Google Cloud, ve a la página 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.
Haz clic en Crear.
Haz clic en Configurar en la opción Estándar.
En el panel de navegación, haz clic en Funciones.
En la sección Operaciones, borra Habilitar Servicio administrado para Prometheus.
Haz clic en Guardar.
gcloud CLI
Puedes hacer lo siguiente con la CLI de gcloud:
- Inhabilita la recopilación administrada en un clúster de GKE existente.
- Anula la habilitación automática de la recopilación administrada cuando crees un clúster de GKE Standard nuevo que ejecute la versión 1.27 o superior de GKE.
Estos comandos pueden tardar hasta 5 minutos en completarse.
Primero, configura tu proyecto:
gcloud config set project PROJECT_ID
Para inhabilitar la recopilación administrada en un clúster existente, ejecuta uno de los siguientes comandos deupdate
en función de si el clúster es zonal o regional:
gcloud container clusters update CLUSTER_NAME --disable-managed-prometheus --zone ZONE
gcloud container clusters update CLUSTER_NAME --disable-managed-prometheus --region REGION
Para anular la habilitación automática de la recopilación administrada cuando se crea un clúster de GKE Standard (versión 1.27 o superior), ejecuta el siguiente comando:
gcloud container clusters create CLUSTER_NAME --zone ZONE --no-enable-managed-prometheus
GKE Autopilot
No puedes desactivar la recopilación administrada en clústeres de GKE Autopilot que ejecutan la versión 1.25 de GKE o una posterior.
Terraform
Para inhabilitar la recopilación administrada, establece el atributo enabled
en el bloque de configuración de managed_prometheus
para false
. Para obtener más información sobre este bloque de configuración, consulta la
Terraform Registry para google_container_cluster
.
Para obtener información general sobre el uso de Google Cloud con Terraform, consulta Terraform con Google Cloud.
Habilita la recopilación administrada: Kubernetes que no es de GKE
Si ejecutas en un entorno que no es de GKE, puedes habilitar la recopilación administrada mediante lo siguiente:
- La CLI de
kubectl
. La solución incluida en las implementaciones de GKE Enterprise que ejecutan la versión 1.12 o posterior.
kubectl
CLI
Para instalar colectores administrados cuando usas un clúster de Kubernetes que no es de GKE, ejecuta los siguientes comandos para instalar los manifiestos de configuración y operador:
kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/prometheus-engine/v0.13.0/manifests/setup.yaml kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/prometheus-engine/v0.13.0/manifests/operator.yaml
GKE Enterprise
Si deseas obtener información sobre la configuración de la recopilación administrada para clústeres de GKE Enterprise, consulta la documentación de tu distribución:
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.13.0/examples/example-app.yaml
Configura un recurso PodMonitoring
Para transferir los datos de métrica que emite la aplicación de ejemplo, Servicio administrado para Prometheus usa la recopilación de objetivos. La recopilación de objetivos y la transferencia de métricas se configuran mediante los recursos personalizados de Kubernetes. El servicio administrado usa recursos personalizados (CR) de PodMonitoring.
Un CR de PodMonitoring recopila objetivos solo en el espacio de nombres en el que se implementa el CR.
Para recopilar objetivos en varios espacios de nombres, implementa el mismo CR de PodMonitoring en cada espacio de nombres. Para verificar que el recurso PodMonitoring esté instalado en el espacio de nombres deseado, ejecuta kubectl get podmonitoring -A
.
Para consultar la documentación sobre todas las CR del Servicio administrado para Prometheus, consulta la referencia de prometheus-engine/doc/api.
El siguiente manifiesto define un recurso PodMonitoring, prom-example
, en el espacio de nombres NAMESPACE_NAME
. El recurso usa un selector de etiquetas de Kubernetes para buscar todos los pods en el espacio de nombres que tienen la etiqueta app.kubernetes.io/name
con el valor prom-example
.
Los pods coincidentes se copian en un puerto llamado metrics
, cada 30 segundos, en la ruta HTTP /metrics
.
apiVersion: monitoring.googleapis.com/v1 kind: PodMonitoring metadata: name: prom-example spec: selector: matchLabels: app.kubernetes.io/name: prom-example endpoints: - port: metrics interval: 30s
Para aplicar este recurso, ejecuta el siguiente comando:
kubectl -n NAMESPACE_NAME apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/prometheus-engine/v0.13.0/examples/pod-monitoring.yaml
El colector administrado ahora recopila los Pods coincidentes. Para ver el estado del objetivo de recopilación, habilita la función de estado objetivo.
Para configurar la recopilación horizontal que se aplica a un rango de pods en todos los espacios de nombres, usa el recurso ClusterPodMonitoring. El recurso ClusterPodMonitoring proporciona la misma interfaz que el recurso de PodMonitoring, pero no limita los pods detectados en un espacio de nombres determinado.
Si ejecutas en GKE, puedes hacer lo siguiente:
- Para consultar las métricas transferidas por la aplicación de ejemplo mediante PromQL en Cloud Monitoring, visita Consulta con Cloud Monitoring.
- Para consultar las métricas transferidas por la aplicación de ejemplo con Grafana, consulta Consulta con Grafana o cualquier consumidor de la API de Prometheus.
- Si deseas obtener información para filtrar las métricas exportadas y adaptar tus recursos de operador de promoción, consulta Temas adicionales para la recopilación administrada.
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 automáticamente del entorno en función de la cuenta de servicio del nodo. En los clústeres de Kubernetes que no sean de GKE, las credenciales deben proporcionarse de manera explícita a través del recurso OperatorConfig en el espacio de nombres gmp-public.
Configura el contexto en tu proyecto de destino:
gcloud config set project PROJECT_ID
Crear una cuenta de servicio:
gcloud iam service-accounts create gmp-test-sa
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
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
Agrega el archivo de claves como un secreto a tu clúster que no es de GKE:
kubectl -n gmp-public create secret generic gmp-test-sa \ --from-file=key.json=gmp-test-sa-key.json
Abre el recurso OperatorConfig para editarlo:
kubectl -n gmp-public edit operatorconfig config
Agrega el texto que se muestra en negrita al recurso:
Asegúrate de agregar estas credenciales a la secciónapiVersion: monitoring.googleapis.com/v1 kind: OperatorConfig metadata: namespace: gmp-public name: config collection: credentials: name: gmp-test-sa key: key.json
rules
para que la evaluación de la regla administrada funcione.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.
Temas adicionales para la recopilación administrada
En esta sección, se describe cómo hacer lo siguiente:
- Habilita la función de estado objetivo para facilitar la depuración.
- Configura la recopilación de destino con Terraform.
- Filtra los datos que exportas al servicio administrado.
- Recopila métricas de Kubelet y cAdvisor.
- Convierte tus recursos del operador de promesa existentes para usarlos con el servicio administrado.
- Ejecuta una colección administrada fuera de GKE.
Habilita la función de estado del destino
Puedes verificar el estado de los destinos en los recursos PodMonitoring o ClusterPodMonitoring si configuras el valor
features.targetStatus.enabled
dentro del recurso OperatorConfig entrue
, como se muestra a continuación:apiVersion: monitoring.googleapis.com/v1 kind: OperatorConfig metadata: namespace: gmp-public name: config features: targetStatus: enabled: true
Después de unos segundos, el campo
Status.Endpoint Statuses
aparecerá en cada recurso válido de PodMonitoring o ClusterPodMonitoring, cuando se configure.Si tienes un recurso de PodMonitoring con el nombre
prom-example
en el espacio de nombresNAMESPACE_NAME
, puedes verificar el estado mediante la ejecución del siguiente comando:kubectl -n NAMESPACE_NAME describe podmonitorings/prom-example
El resultado luce de la siguiente manera:
API Version: monitoring.googleapis.com/v1 Kind: PodMonitoring ... Status: Conditions: ... Status: True Type: ConfigurationCreateSuccess Endpoint Statuses: Active Targets: 3 Collectors Fraction: 1 Last Update Time: 2023-08-02T12:24:26Z Name: PodMonitoring/custom/prom-example/metrics Sample Groups: Count: 3 Sample Targets: Health: up Labels: Cluster: CLUSTER_NAME Container: prom-example Instance: prom-example-589ddf7f7f-hcnpt:metrics Job: prom-example Location: REGION Namespace: NAMESPACE_NAME Pod: prom-example-589ddf7f7f-hcnpt project_id: PROJECT_ID Last Scrape Duration Seconds: 0.020206416 Health: up Labels: ... Last Scrape Duration Seconds: 0.054189485 Health: up Labels: ... Last Scrape Duration Seconds: 0.006224887
El resultado incluye los siguientes campos de estado:
Status.Conditions.Status
es verdadero cuando el Servicio administrado para Prometheus reconoce y procesa el PodMonitoring o ClusterPodMonitoring.Status.Endpoint Statuses.Active Targets
muestra la cantidad de objetivos de recopilación que el Servicio administrado para Prometheus cuenta en todos los recopiladores para este recurso de PodMonitoring. En la aplicación de ejemplo, la implementación deprom-example
tiene tres réplicas con un solo objetivo de métrica, por lo que el valor es3
. Si hay objetivos en mal estado, aparecerá el campoStatus.Endpoint Statuses.Unhealthy Targets
.Status.Endpoint Statuses.Collectors Fraction
muestra un valor de1
(que significa 100%) si se puede acceder a todos los colectores administrados para el Servicio administrado para Prometheus.Status.Endpoint Statuses.Last Update Time
muestra la hora de la última actualización. Cuando la última hora de actualización es mucho más larga que el tiempo de intervalo de recopilación deseado, la diferencia puede indicar problemas con el objetivo o el clúster.- En el campo
Status.Endpoint Statuses.Sample Groups
, se muestran objetivos de muestra agrupados por etiquetas de destino comunes que inserta el colector. Este valor es útil para depurar situaciones en las que no se descubren tus destinos. Si todos los destinos están en buen estado y se recopilan, el valor esperado para el campoHealth
esup
, y el valor del campoLast Scrape Duration Seconds
es la duración habitual para un objetivo típico.
Si deseas obtener más información sobre estos campos, consulta el documento de la API del Servicio administrado para Prometheus.
Cualquiera de los siguientes puede indicar un problema con la configuración:
- No hay un campo
Status.Endpoint Statuses
en tu recurso PodMonitoring. - El valor del campo
Last Scrape Duration Seconds
es demasiado antiguo. - Ves muy pocos objetivos.
- El valor del campo
Health
indica que el objetivo esdown
.
Para obtener más información sobre la depuración de problemas de descubrimiento de objetivos, consulta Problemas del lado de la transferencia en la documentación de solución de problemas.
Configura un extremo de recopilación autorizado
Si tu destino de recopilación requiere autorización, puedes configurar el recopilador para usar el tipo de autorización correcto y proporcionar los secretos relevantes.
Google Cloud Managed Service para Prometheus admite los siguientes tipos de autorización:
mTLS
Por lo general, mTLS se configura en entornos de confianza cero, como la malla de servicios de Istio o Cloud Service Mesh.
Para habilitar los extremos de recopilación protegidos con mTLS, establece el campo
Spec.Endpoints[].Scheme
en tu recurso PodMonitoring enhttps
. Si bien no se recomienda, puedes configurar el campoSpec.Endpoints[].insecureSkipVerify
en tu recurso PodMonitoring comotrue
para omitir la verificación de la autoridad certificadora. Como alternativa, puedes configurar el servicio administrado para Prometheus a fin de cargar certificados y claves de recursos secretos.Por ejemplo, el siguiente recurso Secret contiene claves para los certificados de cliente (
cert
), clave privada (key
) y autoridad certificadora (ca
):kind: Secret metadata: name: secret-example stringData: cert: ******** key: ******** ca: ********
Otorga al servicio administrado para el colector de Prometheus permiso para acceder a ese recurso secreto:
apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: name: secret-example-read rules: - resources: - secrets apiGroups: [""] verbs: ["get", "list", "watch"] resourceNames: ["secret-example"] --- apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: gmp-system:collector:secret-example-read namespace: default roleRef: name: secret-example-read kind: Role apiGroup: rbac.authorization.k8s.io subjects: - name: collector namespace: gmp-system kind: ServiceAccount
En los clústeres de GKE Autopilot, se ve de la siguiente manera:
apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: name: secret-example-read rules: - resources: - secrets apiGroups: [""] verbs: ["get", "list", "watch"] resourceNames: ["secret-example"] --- apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: gmp-system:collector:secret-example-read namespace: default roleRef: name: secret-example-read kind: Role apiGroup: rbac.authorization.k8s.io subjects: - name: collector namespace: gke-gmp-system kind: ServiceAccount
Para configurar un recurso PodMonitoring que use el recurso Secret anterior, modifica tu recurso a fin de agregar una sección
scheme
ytls
:apiVersion: monitoring.googleapis.com/v1 kind: PodMonitoring metadata: name: prom-example spec: selector: matchLabels: app.kubernetes.io/name: prom-example endpoints: - port: metrics interval: 30s scheme: https tls: ca: secret: name: secret-example key: ca cert: secret: name: secret-example key: cert key: secret: name: secret-example key: key
Para obtener documentación de referencia sobre todas las opciones de mTLS del servicio administrado para Prometheus, consulta la documentación de referencia de la API.
BasicAuth
Para habilitar los extremos de recopilación protegidos con BasicAuth, establece el campo
Spec.Endpoints[].BasicAuth
en tu recurso de PodMonitoring con tu nombre de usuario y contraseña. Para otros tipos de encabezados de autorización HTTP, consulta Encabezado de autorización HTTP.Por ejemplo, el siguiente recurso Secret contiene una clave para almacenar la contraseña:
kind: Secret metadata: name: secret-example stringData: password: ********
Otorga al servicio administrado para el colector de Prometheus permiso para acceder a ese recurso secreto:
apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: name: secret-example-read rules: - resources: - secrets apiGroups: [""] verbs: ["get", "list", "watch"] resourceNames: ["secret-example"] --- apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: gmp-system:collector:secret-example-read namespace: default roleRef: name: secret-example-read kind: Role apiGroup: rbac.authorization.k8s.io subjects: - name: collector namespace: gmp-system kind: ServiceAccount
En los clústeres de GKE Autopilot, se ve de la siguiente manera:
apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: name: secret-example-read rules: - resources: - secrets apiGroups: [""] verbs: ["get", "list", "watch"] resourceNames: ["secret-example"] --- apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: gmp-system:collector:secret-example-read namespace: default roleRef: name: secret-example-read kind: Role apiGroup: rbac.authorization.k8s.io subjects: - name: collector namespace: gke-gmp-system kind: ServiceAccount
Para configurar un recurso PodMonitoring que use el recurso Secret anterior y un nombre de usuario de
foo
, modifica tu recurso para agregar una secciónbasicAuth
:apiVersion: monitoring.googleapis.com/v1 kind: PodMonitoring metadata: name: prom-example spec: selector: matchLabels: app.kubernetes.io/name: prom-example endpoints: - port: metrics interval: 30s basicAuth: username: foo password: secret: name: secret-example key: password
Para obtener documentación de referencia sobre todas las opciones de BasicAuth de Managed Service para Prometheus, consulta la documentación de referencia de la API.
Encabezado de autorización HTTP
Para habilitar extremos de recopilación protegidos con encabezados de autorización HTTP, configura el campo
Spec.Endpoints[].Authorization
en tu recurso PodMonitoring con el tipo y las credenciales. Para los extremos de BasicAuth, usa la configuración de BasicAuth.Por ejemplo, el siguiente recurso Secret contiene una clave para almacenar las credenciales:
kind: Secret metadata: name: secret-example stringData: credentials: ********
Otorga al servicio administrado para el colector de Prometheus permiso para acceder a ese recurso secreto:
apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: name: secret-example-read rules: - resources: - secrets apiGroups: [""] verbs: ["get", "list", "watch"] resourceNames: ["secret-example"] --- apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: gmp-system:collector:secret-example-read namespace: default roleRef: name: secret-example-read kind: Role apiGroup: rbac.authorization.k8s.io subjects: - name: collector namespace: gmp-system kind: ServiceAccount
En los clústeres de GKE Autopilot, se ve de la siguiente manera:
apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: name: secret-example-read rules: - resources: - secrets apiGroups: [""] verbs: ["get", "list", "watch"] resourceNames: ["secret-example"] --- apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: gmp-system:collector:secret-example-read namespace: default roleRef: name: secret-example-read kind: Role apiGroup: rbac.authorization.k8s.io subjects: - name: collector namespace: gke-gmp-system kind: ServiceAccount
Para configurar un recurso de PodMonitoring que use el recurso Secret anterior y un tipo de
Bearer
, modifica tu recurso para agregar una secciónauthorization
:apiVersion: monitoring.googleapis.com/v1 kind: PodMonitoring metadata: name: prom-example spec: selector: matchLabels: app.kubernetes.io/name: prom-example endpoints: - port: metrics interval: 30s authorization: type: Bearer credentials: secret: name: secret-example key: credentials
Para obtener documentación de referencia sobre todas las opciones del encabezado de autorización HTTP del servicio administrado para Prometheus, consulta la documentación de referencia de la API.
OAuth 2
Para habilitar los extremos de recopilación protegidos con OAuth 2, debes configurar el campo
Spec.Endpoints[].OAuth2
en tu recurso PodMonitoring.Por ejemplo, el siguiente recurso Secret contiene una clave para almacenar el secreto del cliente:
kind: Secret metadata: name: secret-example stringData: clientSecret: ********
Otorga al servicio administrado para el colector de Prometheus permiso para acceder a ese recurso secreto:
apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: name: secret-example-read rules: - resources: - secrets apiGroups: [""] verbs: ["get", "list", "watch"] resourceNames: ["secret-example"] --- apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: gmp-system:collector:secret-example-read namespace: default roleRef: name: secret-example-read kind: Role apiGroup: rbac.authorization.k8s.io subjects: - name: collector namespace: gmp-system kind: ServiceAccount
En los clústeres de GKE Autopilot, se ve de la siguiente manera:
apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: name: secret-example-read rules: - resources: - secrets apiGroups: [""] verbs: ["get", "list", "watch"] resourceNames: ["secret-example"] --- apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: gmp-system:collector:secret-example-read namespace: default roleRef: name: secret-example-read kind: Role apiGroup: rbac.authorization.k8s.io subjects: - name: collector namespace: gke-gmp-system kind: ServiceAccount
Para configurar un recurso de PodMonitoring que use el recurso Secret anterior con un ID de cliente de
foo
y la URL de token deexample.com/token
, modifica tu recurso para agregar una secciónoauth2
:apiVersion: monitoring.googleapis.com/v1 kind: PodMonitoring metadata: name: prom-example spec: selector: matchLabels: app.kubernetes.io/name: prom-example endpoints: - port: metrics interval: 30s oauth2: clientID: foo clientSecret: secret: name: secret-example key: password tokenURL: example.com/token
Si deseas obtener documentación de referencia sobre todas las opciones del servicio administrado para Prometheus de OAuth 2, consulta la documentación de referencia de la API.
Configura el scraping de destino con Terraform
Puedes automatizar la creación y la administración de los recursos de PodMonitoring y ClusterPodMonitoring mediante el tipo de recurso de Terraform
kubernetes_manifest
o el tipo de recurso de Terraformkubectl_manifest
.Cualquiera te permite especificar recursos personalizados de forma arbitraria.Para obtener información general sobre el uso de Google Cloud con Terraform, consulta Terraform con 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 hacerlo con las reglas de reetiquetado de Prometheus con una acción
keep
para una lista de anunciantes permitidos o una accióndrop
para una lista de bloqueo. Para la recopilación administrada, esta regla va a la secciónmetricRelabeling
de tu recurso de PodMonitoring o ClusterPodMonitoring.Por ejemplo, la siguiente regla de reetiquetado de métricas filtrará cualquier métrica que comience con
foo_bar_
,foo_baz_
ofoo_qux_
:metricRelabeling: - action: drop regex: foo_(bar|baz|qux)_.+ sourceLabels: [__name__]
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 obtener más información de la página Administración de métricas, consulta Visualiza y administra el uso de métricas.
Para obtener sugerencias adicionales sobre cómo reducir los costos, consulta Controles de costos y atribución.
Recopila métricas de Kubelet y cAdvisor
Kubelet expone las métricas sobre sí mismo y las de cAdvisor sobre contenedores que se ejecutan en su nodo. Puedes configurar la recopilación administrada para recopilar las métricas de Kubelet y cAdvisor si editas el recurso OperatorConfig. Para obtener instrucciones, consulta la documentación del exportador para Kubelet y cAdvisor.
Convierte recursos de operador de Prometheus existentes
Por lo general, puedes convertir los recursos existentes del operador de Prometheus en los servicios administrados de los recursos PodMonitoring y ClusterPodMonitoring de la colección administrada de Prometheus.
Por ejemplo, el recurso ServiceMonitor define la supervisión para un conjunto de servicios. El recurso PodMonitoring entrega un subconjunto de los campos que entrega el recurso ServiceMonitor. Puedes convertir un CR de ServiceMonitor en un CR de PodMonitoring si asignas los campos como se describe en la siguiente tabla:
monitoring.coreos.com/v1
ServiceMonitorCompatibilidad
monitoring.googleapis.com/v1
PodMonitoring.ServiceMonitorSpec.Selector
Idénticos .PodMonitoringSpec.Selector
.ServiceMonitorSpec.Endpoints[]
.TargetPort
se asigna a.Port
.Path
: compatible
.Interval
: compatible
.Timeout
: compatible.PodMonitoringSpec.Endpoints[]
.ServiceMonitorSpec.TargetLabels
El PodMonitor debe especificar lo siguiente:
.FromPod[].From
etiqueta del pod
.FromPod[].To
etiqueta del objetivo.PodMonitoringSpec.TargetLabels
El siguiente es un CR de ServiceMonitor de muestra. El contenido en negrita se reemplaza en la conversión y el contenido en cursiva se asigna directamente:
apiVersion: monitoring.coreos.com/v1 kind: ServiceMonitor metadata: name: example-app spec: selector: matchLabels: app: example-app endpoints: - targetPort: web path: /stats interval: 30s targetLabels: - foo
La siguiente es la CR de PodMonitoring analógica, si tu servicio y sus Pods están etiquetados con
app=example-app
. Si esta suposición no se aplica, debes usar los selectores de etiquetas del recurso de servicio subyacente.El contenido en negrita se reemplazó en la conversión:
apiVersion: monitoring.googleapis.com/v1 kind: PodMonitoring metadata: name: example-app spec: selector: matchLabels: app: example-app endpoints: - port: web path: /stats interval: 30s targetLabels: fromPod: - from: foo # pod label from example-app Service pods. to: foo
Siempre puedes seguir usando los recursos existentes del operador de Prometheus y las configuraciones de implementación si usas colectores autoimplementados en lugar de colectores administrados. Puedes consultar las métricas enviadas desde ambos tipos de colectores, por lo que podrías usar colectores autoimplementados para tus implementaciones existentes de Prometheus mientras usas colectores administrados para implementaciones nuevas de Prometheus.
Etiquetas reservadas
Managed Service para Prometheus agrega automáticamente las siguientes etiquetas a todas las métricas recopiladas: Estas etiquetas se usan para identificar de forma inequívoca un recurso en Monarch:
project_id
: El identificador del proyecto de Google Cloud asociado a tu métrica.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.cluster
: El nombre del clúster de Kubernetes asociado con tu métrica.namespace
: El nombre del espacio de nombres de Kubernetes asociado a tu métrica.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.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.
Si bien no se recomienda cuando se ejecuta en Google Kubernetes Engine, puedes anular las etiquetas
project_id
,location
ycluster
. Para ello, agrégalos comoargs
al recurso Deployment enoperator.yaml
. Si usas etiquetas reservadas como etiquetas de métrica, Managed Service para Prometheus las vuelve a etiquetar de forma automática con el prefijoexported_
. Este comportamiento coincide con la forma en que Prometheus ascendente maneja los conflictos con etiquetas reservadas.Comprime las configuraciones
Si tienes muchos recursos de PodMonitoring, es posible que te quedes sin espacio de ConfigMap. Para solucionarlo, habilita la compresión
gzip
en el recurso OperatorConfig:apiVersion: monitoring.googleapis.com/v1 kind: OperatorConfig metadata: namespace: gmp-public name: config features: config: compression: gzip
Habilita el ajuste de escala automático vertical de Pods (VPA) para la recopilación administrada
Si encuentras errores de falta de memoria (OOM) para los pods de recopilador en tu clúster o si los límites y las solicitudes de recursos predeterminados para los recopiladores de otra manera no satisfacen tus necesidades, puedes usar el ajuste de escala automático vertical de Pods para asignar recursos de forma dinámica.
Cuando configuras el campo
scaling.vpa.enabled: true
en el recurso OperatorConfig, el operador implementa un manifiesto de VerticalPodAutoscaling en el clúster que permite que los límites y solicitudes de recursos de los pods de recopilador se configuren automáticamente según el uso.Para habilitar el VPA para los pods de recopiladores en el servicio administrado de Prometheus, ejecuta el siguiente comando:
kubectl -n gmp-public patch operatorconfig/config -p '{"scaling":{"vpa":{"enabled":true}}}' --type=merge
Si el comando se completa correctamente, el operador configura el ajuste de escala automático vertical de los pods de recopiladores. Los errores por falta de memoria generan un aumento inmediato de los límites de recursos. Si no hay errores de OOM, el primer ajuste a las solicitudes y los límites de recursos de los pods de recopiladores suele ocurrir en un plazo de 24 horas.
Es posible que recibas este error cuando intentes habilitar el VPA:
vertical pod autoscaling is not available - install vpa support and restart the operator
Para resolver este error, primero debes habilitar el ajuste de escala automático vertical de Pods a nivel del clúster:
Ve a la página Clústeres de Kubernetes Engine en la consola de Google Cloud.
En la consola de Google Cloud, ve a la página 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.
Selecciona el clúster que deseas modificar.
En la sección Automatización, edita el valor de la opción Ajuste de escala automático vertical de Pods.
Selecciona la casilla de verificación Habilitar el ajuste de escala automático vertical de Pods y, luego, haz clic en Guardar cambios. Este cambio reinicia tu clúster. El operador se reinicia como parte de este proceso.
Vuelve a ejecutar el siguiente comando:
kubectl -n gmp-public patch operatorconfig/config -p '{"scaling":{"vpa":{"enabled":true}}}' --type=merge
para habilitar el VPA para el servicio administrado de Prometheus.
Para confirmar que el recurso OperatorConfig se editó correctamente, ábrelo con el comando
kubectl -n gmp-public edit operatorconfig config
. Si se realiza correctamente, tu OperatorConfig incluirá la siguiente sección en negrita:apiVersion: monitoring.googleapis.com/v1 kind: OperatorConfig metadata: namespace: gmp-public name: config scaling: vpa: enabled: true
El ajuste de escala automático vertical de Pods funciona mejor cuando se transfieren cantidades constantes de muestras, divididas por igual entre los nodos. Si la carga de métricas es irregular o tiene picos, o si varía mucho entre los nodos, es posible que el VPA no sea una solución eficiente.
Para obtener más información, consulta Ajuste de escala automático vertical de Pods en GKE.
Eliminación
Para inhabilitar la recopilación administrada que se implementó mediante
gcloud
o la IU de GKE, puedes realizar una de las siguientes acciones:Ejecuta el siguiente comando:
gcloud container clusters update CLUSTER_NAME --disable-managed-prometheus
Usa la IU de GKE:
Selecciona Kubernetes Engine en la consola de Google Cloud y, luego, Clústeres.
Ubica el clúster para el que deseas inhabilitar la recopilación administrada y haz clic en su nombre.
En la pestaña Detalles, desplázate hacia abajo hasta Funciones y cambia el estado a Inhabilitada mediante el botón de edición.
Para inhabilitar la recopilación administrada implementada mediante Terraform, especifica
enabled = false
en la secciónmanaged_prometheus
del recursogoogle_container_cluster
.Para inhabilitar la recopilación administrada que se implementó mediante
kubectl
, ejecuta el siguiente comando:kubectl delete -f https://raw.githubusercontent.com/GoogleCloudPlatform/prometheus-engine/v0.13.0/manifests/operator.yaml
Si inhabilitas la recopilación administrada, el clúster dejará de enviar datos nuevos al servicio administrado para Prometheus. Si realizas esta acción, no se borrarán los datos de métricas existentes que ya estén almacenados en el sistema.
Si inhabilitas la recopilación administrada, también se borrará el espacio de nombres
gmp-public
y cualquier recurso que contenga, incluidos los exportadores instalados en ese espacio de nombres.Ejecuta una colección administrada fuera de GKE
En entornos de GKE, puedes ejecutar colecciones administradas sin ninguna configuración adicional. En otros entornos de Kubernetes, debes proporcionar de forma explícita credenciales, un valor
project-id
para contener las métricas, un valorlocation
(región de Google Cloud) en el que se almacenarán las métricas. y un valorcluster
para guardar el nombre del clúster en el que se ejecuta el colector.Como
gcloud
no funciona fuera de los entornos de Google Cloud, debes implementar mediante kubectl. A diferencia degcloud
, la implementación de la colección administrada mediantekubectl
no actualiza de forma automática el clúster cuando hay una versión nueva disponible. Recuerda mirar la página de versiones para conocer las versiones nuevas y actualizarla de forma manual si vuelves a ejecutar los comandos dekubectl
con la versión nueva.Puedes proporcionar una clave de cuenta de servicio si modificas el recurso OperatorConfig dentro de
operator.yaml
como se describe en Proporciona credenciales de forma explícita. Puedes proporcionar valores deproject-id
,location
ycluster
si los agregas comoargs
al recurso de implementación enoperator.yaml
.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 usarglobal
como tu ubicación.Para
cluster
, recomendamos elegir el nombre del clúster en el que se implementa el operador.Cuando se configura correctamente, tu OperatorConfig debería verse así:
apiVersion: monitoring.googleapis.com/v1 kind: OperatorConfig metadata: namespace: gmp-public name: config collection: credentials: name: gmp-test-sa key: key.json rules: credentials: name: gmp-test-sa key: key.json
Y tu recurso de implementación debería verse así:
apiVersion: apps/v1 kind: Deployment ... spec: ... template: ... spec: ... containers: - name: operator ... args: - ... - "--project-id=PROJECT_ID" - "--cluster=CLUSTER_NAME" - "--location=REGION"
En este ejemplo, se supone que configuraste la variable
REGION
como un valor comous-central1
.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. Puedes minimizar estos costos si habilitas la compresión gzip por cable a través de OperatorConfig. Agrega el texto que se muestra en negrita al recurso:
apiVersion: monitoring.googleapis.com/v1 kind: OperatorConfig metadata: namespace: gmp-public name: config collection: compression: gzip ...
Lecturas adicionales de recursos personalizados de la colección administrada
Para ver la documentación de referencia sobre todos los servicios personalizados de los servicios administrados de Prometheus, consulta la referencia de prometheus-engine/doc/api.
¿Qué sigue?