Evaluación y alertas de reglas administradas

El servicio administrado de Google Cloud 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.8.2/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 las credenciales del entorno de forma automática según 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
```
1. Agrega el texto que se muestra en negrita al recurso:
```
apiVersion: monitoring.googleapis.com/v1
kind: OperatorConfig
metadata:
  namespace: gmp-public
  name: config
rules:
  credentials:
    name: gmp-test-sa
    key: key.json
```
  Asegúrate de agregar estas credenciales a la sección collection para que funcione la recopilación administrada.
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.
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

Vista previa

Esta función está sujeta a las "Condiciones de las Ofertas de Fase Previa a la DG" de la sección Condiciones Generales del Servicio de las Condiciones Específicas del Servicio. Las funciones de fase previa a la DG están disponibles “tal cual” y podrían tener asistencia limitada. Para obtener más información, consulta las descripciones de la etapa de lanzamiento.

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:
1. 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
```
2. Actualiza el archivo con la configuración de Alertmanager deseada y crea un Secret llamado alertmanager en el espacio de nombres gmp-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:
1. 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
```
2. Abre el recurso OperatorConfig para editarlo:
```
kubectl -n gmp-public edit operatorconfig config
```
3. 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.

Alertmanager implementado de forma automática

Para configurar el evaluador de reglas para un Alertmanager de implementación automática, haz lo siguiente:
1. Abre el recurso OperatorConfig para editarlo:
```
kubectl -n gmp-public edit operatorconfig config
```
2. 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.