Google Cloud Managed Service para Prometheus admite alertas y evaluación de reglas compatibles con Prometheus. En este documento, se describe cómo configurar la evaluación de reglas administradas.
Evaluación de reglas
El servicio administrado para Prometheus proporciona un componente de evaluador de reglas que te permite escribir reglas de forma segura en el contexto de un backend de Prometheus global, lo que te impide interferir en los datos de otros usuarios en organizaciones más grandes. El componente se implementa de forma automática como parte de la recopilación administrada cuando se ejecuta en clústeres de Kubernetes.
Puedes escribir reglas y alertas en el servicio administrado para las métricas de Prometheus y las métricas de Cloud Monitoring. Debes usar el recurso GlobalRules cuando escribas reglas para las métricas de Cloud Monitoring.
Reglas
El evaluador de reglas administrado usa el recurso de reglas para configurar las reglas de grabación y alertas. El siguiente es un recurso de reglas de ejemplo:
apiVersion: monitoring.googleapis.com/v1 kind: Rules metadata: namespace: NAMESPACE_NAME name: example-rules spec: groups: - name: example interval: 30s rules: - record: job:up:sum expr: sum without(instance) (up) - alert: AlwaysFiring expr: vector(1)
El formato del elemento .spec.groups
es idéntico al array rule_group
ascendente de Prometheus. Las reglas de alertas y grabación definidas en Rules
tienen el permiso project_id
, cluster
y namespace
del recurso. Por ejemplo, la regla job:up:sum
en el recurso anterior consulta efectivamente sum without(instance) (up{project_id="test-project", cluster="test-cluster", namespace="NAMESPACE_NAME"})
.
De esta forma se garantiza que las reglas de alerta o grabación no evalúen por accidente las métricas de las aplicaciones que quizás no conoces.
Para aplicar las reglas de ejemplo a tu clúster, ejecuta el siguiente comando:
kubectl apply -n NAMESPACE_NAME -f https://raw.githubusercontent.com/GoogleCloudPlatform/prometheus-engine/v0.12.0/examples/rules.yaml
Después de unos minutos, la métrica job:up:sum
estará disponible.
La alerta AlwaysFiring
también comienza a activarse. Si deseas obtener información para enviar alertas a un administrador de alertas, consulta Configuración del administrador de alertas.
Los recursos ClusterRules y GlobalRules proporcionan la misma interfaz que el recurso Rules
, pero aplican las reglas a permisos más amplios.
ClusterRules selecciona los datos mediante las etiquetas project_id
y cluster
, y GlobalRules selecciona todos los datos en el permiso de las métricas consultadas sin restringir las etiquetas.
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.
Convierte reglas de Prometheus en reglas
El recurso de reglas proporciona una interfaz compatible con las reglas de Prometheus para proporcionar una ruta de migración sin problemas a fin de incorporar reglas existentes en la evaluación de reglas administradas. Puedes incluir tus reglas existentes en un recurso de reglas. Por ejemplo, a continuación se muestra una regla de Prometheus:
groups: - name: example interval: 30s rules: - record: job:up:sum expr: sum without(instance) (up) - alert: AlwaysFiring expr: vector(1)
El recurso de reglas correspondiente con la regla de Prometheus original en negrita es el siguiente:
apiVersion: monitoring.googleapis.com/v1 kind: Rules metadata: namespace: NAMESPACE_NAME name: example-rules spec: groups: - name: example interval: 30s rules: - record: job:up:sum expr: sum without(instance) (up) - alert: AlwaysFiring expr: vector(1)
ClusterRules
Puedes usar el recurso ClusterRules
para configurar las reglas de grabación y
alertas que pueden evaluar todas las series temporales enviadas al
servicio administrado para Prometheus desde todos los espacios de nombres en un clúster específico.
La especificación es idéntica a la de las Rules
. La regla de Prometheus del ejemplo anterior se convierte en el siguiente recurso de ClusterRules
:
apiVersion: monitoring.googleapis.com/v1 kind: ClusterRules metadata: name: example-clusterrules spec: groups: - name: example interval: 30s rules: - record: job:up:sum expr: sum without(instance) (up) - alert: AlwaysFiring expr: vector(1)
Te recomendamos usar los recursos ClusterRules solo en métricas horizontales, como las que produce una malla de servicios. Para las métricas de implementaciones individuales, usa los recursos de reglas a fin de asegurarte de que la evaluación no incluya datos no deseados.
GlobalRules
Puedes usar el recurso GlobalRules
para configurar las reglas de grabación y
alertas que pueden evaluar todas las series temporales enviadas al
Servicio administrado para Prometheus en todos los proyectos dentro de un alcance de métricas..
La especificación es idéntica a la de las Rules
. La regla de Prometheus del ejemplo anterior se convierte en el siguiente recurso de GlobalRules
:
apiVersion: monitoring.googleapis.com/v1 kind: GlobalRules metadata: name: example-globalrules spec: groups: - name: example interval: 30s rules: - record: job:up:sum expr: sum without(instance) (up) - alert: AlwaysFiring expr: vector(1)
Debido a que las métricas de Cloud Monitoring no están sujetas a un espacio de nombres o clúster, debes usar el recurso GlobalRules cuando escribas reglas o alertas para las métricas de Cloud Monitoring. También se requiere el uso de GlobalRules cuando se alertan sobre las métricas del sistema de Google Kubernetes Engine.
Si tu regla no conserva las etiquetas project_id
o location
, estas se ajustan de forma predeterminada a los valores del clúster.
En el caso del servicio administrado para las métricas de Prometheus, recomendamos que uses GlobalRules solo para los casos de uso poco frecuentes en los que una alerta pueda necesitar datos en todos los clústeres a la vez. Para las métricas de implementaciones individuales, usa las reglas o los recursos ClusterRules a fin de lograr una mayor confiabilidad y garantizar que la evaluación no incluya datos no deseados. Recomendamos encarecidamente conservar las etiquetas cluster
y namespace
en los resultados de la evaluación de reglas, a menos que el propósito de la regla sea agregar esas etiquetas. De lo contrario, el rendimiento de las consultas podría disminuir y es posible que te encuentres con límites de cardinalidad. No se recomienda quitar ambas etiquetas.
Evaluación de reglas globales y de varios proyectos
Cuando se implementa en Google Kubernetes Engine, el evaluador de reglas usa el proyecto de Google Cloud asociado con el clúster, que el evaluador de reglas detecta de forma automática. Para evaluar las reglas que abarcan proyectos, debes configurar el evaluador de reglas que ejecuta el recurso GlobalRules a fin de usar un proyecto con un alcance de métricas de varios proyectos. Puedes hacerlo de dos maneras:
- Coloca tu recurso GlobalRules en un proyecto que tenga un alcance de métricas de varios proyectos.
- Establece el campo
queryProjectID
dentro de OperatorConfig para usar un proyecto con un alcance de métricas de varios proyectos.
También debes actualizar los permisos de la cuenta de servicio que usa el evaluador de reglas (que suele ser la cuenta de servicio predeterminada del nodo) para que la cuenta de servicio pueda leer desde el proyecto de alcance y escribir en todos los proyectos supervisados en el alcance de las métricas.
Si tu permiso de métricas contiene todos tus proyectos, las reglas se evalúan a nivel global. Para obtener más información, consulta Permisos de métricas.
Alertas mediante métricas de Cloud Monitoring
Puedes usar el recurso GlobalRules para generar alertas sobre las métricas del sistema de Google Cloud mediante PromQL. Si deseas obtener instrucciones sobre cómo crear una consulta válida, consulta PromQL para las métricas de Cloud Monitoring.
Configura reglas y alertas con Terraform
Puedes automatizar la creación y la administración de recursos de reglas, ClusterRules y GlobalRules mediante eltipo de recurso kubernetes_manifest
de Terraform o el tipo de recurso kubectl_manifest
de Terraform, cualquiera de los cuales te permite especificar recursos personalizados arbitrarios.
Para obtener información general sobre el uso de Google Cloud con Terraform, consulta Terraform con Google Cloud.
Proporciona credenciales de forma explícita
Cuando se ejecuta en GKE, el evaluador de reglas recupera de forma automática las credenciales 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.viewer \ && \ 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 rules: credentials: name: gmp-test-sa key: key.json
collection
para que funcione la recopilación administrada.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.
Evaluación de reglas de escalamiento
El evaluador de reglas se ejecuta como un Deployment de réplica única con solicitudes y límites de recursos fijos. Es posible que notes que la carga de trabajo experimenta interrupciones, como OOMKilled cuando evalúas una gran cantidad de reglas. Para mitigar esto, puedes implementar un
VerticalPodAutoscaler
para escalar la implementación de forma vertical. Primero, asegúrate de que el Ajuste de escala automático vertical de Pods esté habilitado en tu clúster de Kubernetes. Luego, aplica un recursoVerticalPodAutoscaler
como el siguiente:apiVersion: autoscaling.k8s.io/v1 kind: VerticalPodAutoscaler metadata: name: rule-evaluator namespace: gmp-system spec: resourcePolicy: containerPolicies: - containerName: evaluator controlledResources: - memory maxAllowed: memory: 4Gi minAllowed: memory: 16Mi mode: Auto targetRef: apiVersion: apps/v1 kind: Deployment name: rule-evaluator updatePolicy: updateMode: Auto
Para verificar que el escalador automático esté funcionando, verifica su estado:
kubectl get vpa --namespace gmp-system rule-evaluator
Si el escalador automático está funcionando, informa que calculó las recomendaciones de recursos para la carga de trabajo en la columna “PROVIDED”:
NAME MODE CPU MEM PROVIDED AGE rule-evaluator Auto 2m 11534336 True 30m
Comprime las configuraciones
Si tienes muchos recursos de reglas, es posible que te quedes sin espacio de ConfigMap. Para solucionar este problema, 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
Configuración del administrador de alertas
Puedes usar el recurso OperatorConfig para configurar el evaluador de reglas administradas a fin de enviar alertas a un Alertmanager de Prometheus. Puedes enviar alertas al Alertmanager administrado que se implementó de forma automática, además de cualquier Alertmanager que se implemente de forma automática.
Alertmanager administrado
El servicio administrado para Prometheus implementa una instancia administrada de Alertmanager, en la que los evaluadores de reglas se configuran de forma automática para reenviar alertas. De manera predeterminada, esta configuración se establece con un Secret de Kubernetes que tiene un nombre específico y contiene un archivo de configuración de Alertmanager.
Para habilitar y configurar los informes en la instancia de Alertmanager implementada, haz lo siguiente:
Crea un archivo de configuración local que contenga tu configuración de Alertmanager (consulta las plantillas de configuración de muestra):
touch alertmanager.yaml
Actualiza el archivo con la configuración de Alertmanager deseada y crea un Secret llamado
alertmanager
en el espacio de nombresgmp-public
:kubectl create secret generic alertmanager \ -n gmp-public \ --from-file=alertmanager.yaml
Después de unos minutos, el servicio administrado para Prometheus recoge el Secret de configuración nuevo y habilita el Alertmanager administrado con tu configuración.
Personaliza el nombre del Secret de configuración
El Alertmanager administrado también admite nombres de secretos personalizados para cargar la configuración. Esta capacidad es útil cuando tienes varios Secrets de configuración y deseas que tu instancia de Alertmanager cambie entre los archivos de configuración correspondientes. Por ejemplo, es posible que desees cambiar los canales de notificación de alertas según la rotación de los turnos activos o que quieras cambiar una configuración experimental de Alertmanager para probar una ruta de alertas nueva.
Para especificar un nombre de secreto no predeterminado mediante el recurso OperatorConfig, haz lo siguiente:
Crea un Secret desde el archivo de configuración del Alertmanager local:
kubectl create secret generic SECRET_NAME \ -n gmp-public \ --from-file=FILE_NAME
Abre el recurso OperatorConfig para editarlo:
kubectl -n gmp-public edit operatorconfig config
Para habilitar los informes del Alertmanager administrado, edita el recurso mediante la modificación de la sección
managedAlertmanager
, como se muestra en el siguiente texto en negrita:apiVersion: monitoring.googleapis.com/v1 kind: OperatorConfig metadata: namespace: gmp-public name: config managedAlertmanager: configSecret: name: SECRET_NAME key: FILE_NAME
Si necesitas realizar cambios en la configuración de Alertmanager, puedes editar la configuración de esta alerta si actualizas el Secret que creaste antes.
Personaliza la URL externa
Puedes configurar la URL externa para el Alertmanager administrado, de modo que las notificaciones de alerta puedan proporcionar un vínculo de devolución de llamada a tu IU de alertas. Esto equivale a usar la marca
--web.external-url
ascendente de Prometheus Alertmanager.apiVersion: monitoring.googleapis.com/v1 kind: OperatorConfig metadata: namespace: gmp-public name: config managedAlertmanager: externalURL: EXTERNAL_URL
Alertmanager implementado de forma automática
Para configurar el evaluador de reglas para un Alertmanager de implementación automática, haz lo siguiente:
Abre el recurso OperatorConfig para editarlo:
kubectl -n gmp-public edit operatorconfig config
Configura el recurso para enviar alertas a tu servicio de Alertmanager:
apiVersion: monitoring.googleapis.com/v1 kind: OperatorConfig metadata: namespace: gmp-public name: config rules: alerting: alertmanagers: - name: SERVICE_NAME namespace: SERVICE_NAMESPACE port: PORT_NAME
Si tu Alertmanager se encuentra en un clúster diferente al de tu evaluador de reglas, es posible que debas configurar un recurso de Endpoints. Por ejemplo, si OperatorConfig indica que los extremos de Alertmanager se pueden encontrar en el objeto de Endpoints
ns=alertmanager/name=alertmanager
, puedes crear este objeto de forma manual o programática y propagarlo con IP accesibles desde el otro clúster. La sección de configuración de AlertmanagerEndpoints proporciona opciones para la configuración de autorización, si es necesario.