Evaluación de reglas desplegadas automáticamente y alertas

Google Cloud Managed Service para Prometheus admite la evaluación de reglas y las alertas compatibles con Prometheus. En este documento se describe cómo configurar la evaluación de reglas desplegadas automáticamente, incluido el componente independiente de evaluación de reglas.

Solo tienes que seguir estas instrucciones si quieres ejecutar reglas y alertas en el almacén de datos global.

Evaluación de reglas para la recogida desplegada automáticamente

Una vez que hayas desplegado Managed Service para Prometheus, puedes seguir evaluando las reglas localmente en cada instancia desplegada mediante el campo rule_files de tu archivo de configuración de Prometheus. Sin embargo, la ventana de consulta máxima de las reglas está limitada por el tiempo que el servidor conserva los datos locales.

La mayoría de las reglas solo se ejecutan en los datos de los últimos minutos, por lo que ejecutar reglas en cada servidor local suele ser una estrategia válida. En ese caso, no es necesario hacer nada más.

Sin embargo, a veces es útil poder evaluar las reglas con el backend de métricas global. Por ejemplo, cuando todos los datos de una regla no se encuentran en la misma instancia de Prometheus. En estos casos, Managed Service para Prometheus también proporciona un componente de evaluador de reglas.

Antes de empezar

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

Configurar el entorno

Para no tener que introducir repetidamente el ID del proyecto o el nombre del clúster, haz la siguiente configuración:

• Configura las herramientas de línea de comandos de la siguiente manera:

  • Configura gcloud CLI para que haga referencia al ID de tu proyectoGoogle Cloud :

    gcloud config set project PROJECT_ID
    

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

    kubectl config set-cluster CLUSTER_NAME
    

  Para obtener más información sobre estas herramientas, consulta los siguientes artículos:

  • Información general sobre la CLI de gcloud
  • Comandos de kubectl

Configurar un espacio de nombres

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

kubectl create ns NAMESPACE_NAME

Verificar las credenciales de la cuenta de servicio

Si tu clúster de Kubernetes tiene habilitada la federación de identidades de carga de trabajo para GKE, puedes saltarte esta sección.

Cuando se ejecuta en GKE, Managed Service para Prometheus obtiene automáticamente las credenciales 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 Federation para GKE y has quitado alguno de esos roles de la cuenta de servicio de nodo predeterminada, tendrás que volver a añadir los permisos que faltan antes de continuar.

Configurar una cuenta de servicio para Workload Identity Federation for GKE

Si tu clúster de Kubernetes no tiene habilitada la federación de identidades de carga de trabajo para GKE, puedes saltarte esta sección.

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

• Crear una Google Cloud cuenta de servicio gmp-test-sa.
• Asociar la cuenta de servicio Google Cloud a la cuenta de servicio de Kubernetes predeterminada en un espacio de nombres de prueba. NAMESPACE_NAME
• Conceder el permiso necesario a la cuenta de servicio Google Cloud .

Crear y vincular la cuenta de servicio

Este paso aparece en varios lugares de la documentación de Managed Service para Prometheus. Si ya has completado este paso en una tarea anterior, no tienes que repetirlo. Vaya a la sección Autorizar la cuenta de servicio.

La siguiente secuencia de comandos crea la cuenta de servicio gmp-test-sa y la vincula a la cuenta de servicio predeterminada de Kubernetes 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 según corresponda.

Autorizar la cuenta de servicio

Los grupos de permisos relacionados se recogen en roles, y tú asignas los roles a una entidad principal, en este ejemplo, la Google Cloudcuenta de servicio. Para obtener más información sobre los roles de Monitoring, consulta Control de acceso.

El siguiente comando concede a la Google Cloud cuenta de servicio, gmp-test-sa, los roles de la API Monitoring que necesita para leer y escribir datos de métricas.

Si ya has concedido un rol específico a la Google Cloud cuenta de servicio como parte de una tarea anterior, no es necesario que lo hagas de nuevo.

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

Depurar la configuración de Workload Identity Federation para GKE

Si tienes problemas para que funcione Workload Identity Federation para GKE, consulta la documentación sobre cómo verificar la configuración de Workload Identity Federation para GKE y la guía para solucionar problemas de Workload Identity Federation para GKE.

Como las erratas y las acciones de copiar y pegar parciales son las fuentes de errores más habituales al configurar la federación de identidades de carga de trabajo para GKE, te recomendamos encarecidamente que uses las variables editables y los iconos de copiar y pegar en los que se puede hacer clic que se incluyen en los ejemplos de código de estas instrucciones.

Workload Identity Federation para GKE en entornos de producción

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

En un entorno de producción, puede que quieras usar un enfoque más detallado, con una cuenta de servicio para cada componente, cada una con permisos mínimos. Para obtener más información sobre cómo configurar cuentas de servicio para la gestión de identidades de cargas de trabajo, consulta Usar Workload Identity Federation para GKE.

Desplegar el evaluador de reglas independiente

El evaluador de reglas de Managed Service para Prometheus evalúa las reglas de alertas y grabaciones de Prometheus con la API HTTP de Managed Service para Prometheus y escribe los resultados en Monarch. Acepta el mismo formato de archivo de configuración y de archivo de reglas que Prometheus. Las banderas también son prácticamente idénticas.

1. Crea una implementación de ejemplo del evaluador de reglas que esté preconfigurada para evaluar una regla de alerta y una regla de registro:

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

2. Comprueba que los pods del evaluador de reglas se hayan desplegado correctamente:

   kubectl -n NAMESPACE_NAME get pod
   

   Si el despliegue se ha realizado correctamente, verás un resultado similar al siguiente:

   NAME                              READY   STATUS    RESTARTS   AGE
   ...
   rule-evaluator-64475b696c-95z29   2/2     Running   0          1m
   

Una vez que haya verificado que el evaluador de reglas se ha implementado correctamente, puede hacer ajustes en los manifiestos instalados para hacer lo siguiente:

• Añade tus archivos de reglas personalizadas.
• Configura el evaluador de reglas para que envíe alertas a un Alertmanager de Prometheus autodesplegado 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, puede que tengas que configurar un recurso Endpoints. Por ejemplo, si tu OperatorConfig especifica que los endpoints de Alertmanager se pueden encontrar en el objeto Endpoints ns=alertmanager/name=alertmanager, puedes crear este objeto de forma manual o programática y rellenarlo con IPs accesibles del otro clúster.

Proporcionar credenciales explícitamente

Cuando se ejecuta en GKE, el evaluador de reglas obtiene automáticamente las credenciales del entorno en función de la cuenta de servicio del nodo o de la configuración de Workload Identity Federation for GKE. En los clústeres de Kubernetes que no son de GKE, las credenciales se deben proporcionar explícitamente al evaluador de reglas mediante marcas o la variable de entorno GOOGLE_APPLICATION_CREDENTIALS.

1. Define el contexto de tu proyecto de destino:

   gcloud config set project PROJECT_ID
   

2. Crea una cuenta de servicio:

   gcloud iam service-accounts create gmp-test-sa
   

   En este paso se crea la cuenta de servicio que puede que ya hayas creado en las instrucciones de Workload Identity Federation para GKE.

3. Concede los permisos necesarios 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
   

4. Crea y descarga una clave para la cuenta de servicio:

   gcloud iam service-accounts keys create gmp-test-sa-key.json \
     --iam-account=gmp-test-sa@PROJECT_ID.iam.gserviceaccount.com
   

5. Añade el archivo de claves como secreto a tu clúster que no sea de GKE:

   kubectl -n NAMESPACE_NAME create secret generic gmp-test-sa \
     --from-file=key.json=gmp-test-sa-key.json
   

6. Abre el recurso de implementación rule-evaluator para editarlo:

   kubectl -n NAMESPACE_NAME edit deploy rule-evaluator
   

   1. Añade 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. Una vez aplicado el cambio, los pods se vuelven a crear y empiezan a autenticarse en el backend de métricas con la cuenta de servicio proporcionada.

   También puedes definir la ruta del archivo de claves mediante la variable de entorno GOOGLE_APPLICATION_CREDENTIALS en lugar de usar las marcas definidas en este ejemplo.

   Evaluación de reglas globales y de varios proyectos

   Te recomendamos que ejecutes una instancia del evaluador de reglas en cada proyecto y región, en lugar de ejecutar una instancia que evalúe muchos proyectos y regiones. Google Cloud Sin embargo, admitimos la evaluación de reglas de varios proyectos en los casos en los que sea necesario.

   Cuando se implementa en Google Kubernetes Engine, el evaluador de reglas usa elGoogle Cloud proyecto asociado al clúster, que detecta automáticamente. Para evaluar reglas que abarcan proyectos, puede anular el proyecto consultado mediante la marca --query.project-id y especificar un proyecto con un ámbito de métricas de varios proyectos. Si tu ámbito de métricas contiene todos tus proyectos, tus reglas se evalúan de forma global. Para obtener más información, consulta Ámbitos de las métricas.

   También debe actualizar los permisos de la cuenta de servicio que usa el evaluador de reglas para que la cuenta de servicio pueda leer el proyecto de ámbito y escribir en todos los proyectos monitorizados del ámbito de las métricas.

   Mantener las etiquetas al escribir reglas

   En el caso de los datos que el evaluador escribe en Managed Service para Prometheus, el evaluador admite las mismas marcas --export.* y la misma configuración basada en external_labels que el archivo binario del servidor de Managed Service para Prometheus. Te recomendamos que escribas reglas para que las etiquetas project_id, location, cluster y namespace se conserven correctamente en su nivel de agregación. De lo contrario, el rendimiento de las consultas podría disminuir y podrías alcanzar los límites de cardinalidad.

   Las etiquetas project_id o location son obligatorias. Si faltan estas etiquetas, los valores de los resultados de la evaluación de reglas se definen en función de la configuración del evaluador de reglas. Las etiquetas cluster o namespace que faltan no tienen valores asignados.

   Autobservabilidad

   El evaluador de reglas emite métricas de Prometheus en un puerto configurable mediante la marca --web.listen-address.

   Por ejemplo, si el pod rule-evaluator-64475b696c-95z29 expone estas métricas en el puerto 9092, las métricas se pueden ver manualmente mediante kubectl:

   # Port forward the metrics endpoint.
   kubectl port-forward rule-evaluator-64475b696c-95z29 9092
   # Then query in a separate terminal.
   curl localhost:9092/metrics
   

   Puede configurar su pila de Prometheus para recogerlos y así tener visibilidad del rendimiento del evaluador de reglas.

   Implementaciones de alta disponibilidad

   El evaluador de reglas se puede ejecutar en una configuración de alta disponibilidad siguiendo el mismo enfoque que se describe en la documentación del servidor de Prometheus.

   Alertas mediante métricas de Cloud Monitoring

   Puedes configurar el evaluador de reglas para que te avise sobre las Google Cloud métricas del sistema mediante PromQL. Para obtener instrucciones sobre cómo crear una consulta válida, consulta PromQL para métricas de Cloud Monitoring.