Evaluación y alertas de reglas con implementación automática

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 con implementación automática, incluido el componente de evaluador independiente.

Solo debes seguir estas instrucciones si deseas ejecutar reglas y alertas en el almacén de datos global.

Evaluación de reglas para la colección de implementación automática

Después de implementar el servicio administrado para Prometheus, puedes seguir evaluando las reglas de forma local en cada instancia implementada con el campo rule_files del archivo de configuración de Prometheus. Sin embargo, el período máximo de consulta de las reglas está limitado por la cantidad de tiempo que el servidor conserva los datos locales.

La mayoría de las reglas se ejecutan solo durante los últimos minutos de datos, por lo que ejecutar reglas en cada servidor local suele ser una estrategia válida. En ese caso, no se necesita ninguna configuración adicional.

Sin embargo, a veces es útil poder evaluar las reglas en función del backend de la métrica global, por ejemplo, cuando todos los datos de una regla no se encuentran en la misma ubicación en una instancia de Prometheus determinada. En estos casos, el servicio administrado para Prometheus también proporciona un componente de evaluador de reglas.

Antes de comenzar

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

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:
- Descripción general de la CLI de gcloud
- Comandos de kubectl

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 una cuenta de servicio dedicada de Google Cloud, gmp-test-sa.
Vincula la cuenta de servicio de Google Cloud a la cuenta de servicio de Kubernetes predeterminada en un espacio de nombres de prueba, NAMESPACE_NAME.
Otorgar el permiso necesario a la cuenta de servicio de Google Cloud

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 y escribir 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.viewer \
&& \
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.

Implementa el evaluador de reglas independiente

El evaluador de reglas del servicio administrado para Prometheus evalúa las reglas de grabación y alertas de Prometheus con el servicio administrado para la API de HTTP de Prometheus y escribe los resultados en Monarch. Acepta el mismo formato de archivo de configuración y archivo de reglas que Prometheus. Las marcas también son idénticas.

Crea una implementación de ejemplo del evaluador de reglas que está preconfigurado para evaluar una alerta y una regla de grabación:

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

Verifica que los Pods para el evaluador de reglas 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
...
rule-evaluator-64475b696c-95z29   2/2     Running   0          1m
```

Después de verificar que el evaluador de reglas se implementó de forma correcta, puedes realizar ajustes en los manifiestos instalados para hacer lo siguiente:

Agrega tus archivos de reglas personalizadas.
Configurar el evaluador de reglas para enviar alertas a un Alertmanager de Prometheus implementado de forma automática mediante el campo alertmanager_config del archivo de configuración.

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

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 o la configuración de Workload Identity. En clústeres de Kubernetes que no son de GKE, las credenciales deben proporcionarse de forma explícita al evaluador de reglas mediante marcas o la variable de entorno GOOGLE_APPLICATION_CREDENTIALS.

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
```
En este paso, se crea la cuenta de servicio que puedes haber creado ya en las instrucciones de Workload Identity.

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 NAMESPACE_NAME create secret generic gmp-test-sa \
  --from-file=key.json=gmp-test-sa-key.json

Abre el recurso de implementación del evaluador de reglas para editarlo:
```
kubectl -n NAMESPACE_NAME edit deploy rule-evaluator
```
1. Agrega el texto que se muestra en negrita al recurso:
```
apiVersion: apps/v1
kind: Deployment
metadata:
  namespace: NAMESPACE_NAME
  name: rule-evaluator
spec:
  template
    containers:
    - name: evaluator
      args:
      - --query.credentials-file=/gmp/key.json
      - --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.
Evaluación de reglas globales y de varios proyectos

Te recomendamos ejecutar una instancia del evaluador de reglas en cada proyecto y región de Google Cloud, en lugar de ejecutar una instancia que se evalúe con muchos proyectos y regiones. Sin embargo, admitimos la evaluación de reglas de varios proyectos para situaciones que lo requieran.

Cuando se implementa en Google Kubernetes Engine, el evaluador de reglas usa el proyecto de Google Cloud asociado con el clúster, que detecta de forma automática. Para evaluar las reglas que abarcan proyectos, puedes anular el proyecto consultado mediante la marca --query.project-id y especificar un proyecto con un permiso de métricas de varios proyectos. 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.

También debes actualizar los permisos de la cuenta de servicio que usa el evaluador de reglas 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.

Preserva las etiquetas cuando se escriben reglas

Para los datos que el evaluador vuelve a escribir en el servicio administrado de Prometheus, el evaluador admite las mismas marcas --export.* y la configuración basada en external_labels que el objeto binario del servidor de Prometheus. Te recomendamos que escribas reglas a fin de que las etiquetas project_id, location, cluster y namespace se conserven de forma correcta para su nivel de agregación; de lo contrario, el rendimiento de las consultas podría disminuir y podrías alcanzar límites de cardinalidad.

Las etiquetas project_id o location son obligatorias. Si faltan estas etiquetas, los valores en los resultados de la evaluación de reglas se establecen según la configuración del evaluador de reglas. Las etiquetas cluster o namespace faltantes no tienen valores.

Implementaciones de alta disponibilidad

El evaluador de reglas se puede ejecutar en una configuración con alta disponibilidad mediante el mismo enfoque que se documenta para el servidor de Prometheus.

Alertas mediante métricas de Cloud Monitoring

Puedes configurar el evaluador de reglas para alertar sobre las métricas del sistema de Google Cloud con PromQL. Si deseas obtener instrucciones sobre cómo crear una consulta válida, consulta PromQL para las métricas de Cloud Monitoring.