Evaluación y alertas de reglas gestionadas

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

Evaluación de reglas

Managed Service 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 evita que interfieras con los datos de otros usuarios en organizaciones más grandes. El componente se despliega automáticamente como parte de la recogida gestionada cuando se ejecuta en clústeres de Kubernetes.

Puedes escribir reglas y alertas tanto en las métricas de Managed Service para Prometheus como en las métricas de Cloud Monitoring. Debes usar el recurso GlobalRules al escribir reglas para las métricas de Cloud Monitoring.

Reglas

El evaluador de reglas gestionado usa el recurso Rules para configurar reglas de registro y alertas. A continuación, se muestra un ejemplo de recurso Rules:

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 de la matriz rule_group de Prometheus. Las reglas de alertas y grabaciones definidas en Rules se aplican a project_id, cluster y namespace del recurso. Por ejemplo, la regla job:up:sum del recurso anterior consulta de forma eficaz sum without(instance) (up{project_id="test-project", cluster="test-cluster", namespace="NAMESPACE_NAME"}). Esta garantía asegura que las reglas de alertas o de registro no evalúen por error métricas de aplicaciones que ni siquiera conozcas.

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.15.3/examples/rules.yaml

Al cabo de unos minutos, estará disponible la métrica job:up:sum. La alerta AlwaysFiring también empieza a activarse. Para obtener información sobre cómo enviar alertas a Alertmanager, consulta la sección Configuración de Alertmanager.

Los recursos ClusterRules y GlobalRules proporcionan la misma interfaz que el recurso Rules, pero aplican las reglas a ámbitos más amplios. ClusterRules selecciona datos mediante las etiquetas project_id y cluster, mientras que GlobalRules selecciona todos los datos del ámbito de las métricas consultadas sin restringir las etiquetas.

Para consultar la documentación de referencia sobre todos los recursos personalizados de Managed Service for Prometheus, consulta la referencia de la API de prometheus-engine/doc.

Convertir reglas de Prometheus en reglas

El recurso Rules proporciona una interfaz compatible con las reglas de Prometheus para ofrecer una ruta de migración fluida que permita incorporar reglas a la evaluación de reglas gestionadas. Puedes incluir tus reglas en un recurso Rules. Por ejemplo, la siguiente es una regla de Prometheus:

groups:
- name: example
  interval: 30s
  rules:
  - record: job:up:sum
    expr: sum without(instance) (up)
  - alert: AlwaysFiring
    expr: vector(1)

A continuación, se muestra el recurso Rules correspondiente, con la regla de Prometheus original en negrita:

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 reglas de registro y de alertas que puedan evaluar todas las series temporales enviadas a Managed Service para Prometheus desde todos los espacios de nombres de un clúster concreto. La especificación es idéntica a la de Rules. La regla de Prometheus de ejemplo anterior se convierte en el siguiente recurso 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 que utilices los recursos ClusterRules solo en métricas horizontales, como las que genera una malla de servicios. En el caso de las métricas de implementaciones individuales, usa recursos de Rules para asegurarte de que la evaluación no incluya datos no deseados.

GlobalRules

Puedes usar el recurso GlobalRules para configurar reglas de grabación y alertas que puedan evaluar todas las series temporales enviadas a Managed Service para Prometheus en todos los proyectos de un ámbito de métricas. La especificación es idéntica a la de Rules. La regla de Prometheus de ejemplo anterior se convierte en el siguiente recurso 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)

Como las métricas de Cloud Monitoring no están acotadas a un espacio de nombres o a un clúster, debes usar el recurso GlobalRules al escribir reglas o alertas para las métricas de Cloud Monitoring. También es necesario usar GlobalRules cuando se configuran alertas sobre métricas del sistema de Google Kubernetes Engine.

Si tu regla no conserva las etiquetas project_id o location, se les asignarán los valores predeterminados del clúster.

En el caso de las métricas de Managed Service para Prometheus, te recomendamos que uses GlobalRules solo en aquellos casos poco frecuentes en los que una alerta pueda necesitar datos de todos los clústeres a la vez. Para las métricas de implementaciones individuales, usa los recursos Rules o ClusterRules para aumentar la fiabilidad y asegurarte de que la evaluación no incluya datos no deseados. Te recomendamos que conserves las etiquetas cluster y namespace en los resultados de la evaluación de reglas, a menos que el objetivo de la regla sea agregar esas etiquetas. De lo contrario, el rendimiento de las consultas podría disminuir y podrías alcanzar los 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 elGoogle Cloud proyecto asociado al clúster, que el evaluador de reglas detecta automáticamente. Para evaluar reglas que abarcan proyectos, debe configurar el evaluador de reglas que ejecuta el recurso GlobalRules para que use un proyecto con un ámbito de métricas multiproyecto. Puedes hacerlo de dos formas:

• Coloca el recurso GlobalRules en un proyecto que tenga un ámbito de métricas de varios proyectos.
• Define el campo queryProjectID en OperatorConfig para usar un proyecto con un ámbito de métricas de varios proyectos.

También debes actualizar los permisos de la cuenta de servicio que usa el evaluador de reglas (normalmente, la cuenta de servicio predeterminada del nodo) para que pueda leer del proyecto de ámbito y escribir en todos los proyectos monitorizados del ámbito de métricas.

Si tu ámbito de métricas contiene todos tus proyectos, las reglas se evaluarán de forma global. Para obtener más información, consulta Ámbitos de las métricas.

Alertas mediante métricas de Cloud Monitoring

Puedes usar el recurso GlobalRules para recibir alertas sobre Google Cloudmétricas del sistema mediante PromQL. Para obtener instrucciones sobre cómo crear una consulta válida, consulta PromQL para métricas de Cloud Monitoring.

Configurar reglas y alertas con Terraform

Puedes automatizar la creación y la gestión de recursos de Rules, ClusterRules y GlobalRules si usas los kubernetes_manifesttipos de recurso de Terraform o los kubectl_manifesttipos de recurso de Terraform, que te permiten especificar recursos personalizados arbitrarios.

Para obtener información general sobre el uso de Google Cloud con Terraform, consulta Terraform con Google Cloud.

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. En los clústeres de Kubernetes que no sean de GKE, las credenciales deben proporcionarse explícitamente a través del recurso OperatorConfig en el espacio de nombres gmp-public.

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
   

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

6. Abre el recurso OperatorConfig para editarlo:

   kubectl -n gmp-public edit operatorconfig config
   

   1. Añade 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 añadir estas credenciales a la sección collection para que funcione la recogida gestionada.

   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.

   Evaluación de reglas de escalado

   El evaluador de reglas se ejecuta como una réplica única de Deployment con solicitudes y límites de recursos fijos. Puede que observe interrupciones en la carga de trabajo, como que se cierre por falta de memoria al evaluar un gran número de reglas. Para mitigar este problema, puedes desplegar un VerticalPodAutoscaler para escalar verticalmente el despliegue. Primero, asegúrate de que la opción Autoescalado vertical de pods esté habilitada en tu clúster de Kubernetes. A continuación, aplica un VerticalPodAutoscaler recurso 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 comprobar que la herramienta de escalado automático funciona, consulta su estado:

   kubectl get vpa --namespace gmp-system rule-evaluator
   

   Si el escalador automático funciona, se indica que ha calculado las recomendaciones de recursos para la carga de trabajo en la columna "PROVIDED" (PROPORCIONADO):

   NAME             MODE   CPU   MEM        PROVIDED   AGE
   rule-evaluator   Auto   2m    11534336   True       30m
   

   Configuraciones de compresión

   Si tienes muchos recursos de Rules, es posible que te quedes sin espacio en ConfigMap. Para solucionar este problema, habilita la compresión gzip en tu recurso OperatorConfig:

     apiVersion: monitoring.googleapis.com/v1
     kind: OperatorConfig
     metadata:
       namespace: gmp-public
       name: config
     features:
       config:
         compression: gzip
   

   Configuración de Alertmanager

   Puedes usar el recurso OperatorConfig para configurar el evaluador de reglas gestionado de forma que envíe alertas a un Alertmanager de Prometheus. Puedes enviar alertas al Alertmanager gestionado que se ha implementado automáticamente, además de a cualquier Alertmanager que hayas implementado tú.

   Alertmanager gestionado

   Managed Service para Prometheus despliega una instancia gestionada de Alertmanager, en la que los evaluadores de reglas se configuran automáticamente para reenviar alertas. De forma predeterminada, esta configuración se define con un secreto de Kubernetes con un nombre específico que 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 tus ajustes de Alertmanager (consulta las plantillas de configuración de ejemplo):

      touch alertmanager.yaml
      

   2. Actualiza el archivo con la configuración de Alertmanager que quieras y crea un secreto llamado alertmanager en el espacio de nombres gmp-public:

      kubectl create secret generic alertmanager \
        -n gmp-public \
        --from-file=alertmanager.yaml
      

   Al cabo de unos instantes, Managed Service para Prometheus detecta el nuevo secreto de configuración y habilita Alertmanager gestionado con tus ajustes.

   Personalizar el nombre del secreto de configuración

   El Alertmanager gestionado también admite nombres de secretos personalizados para cargar la configuración. Esta función es útil cuando tienes varios secretos de configuración y quieres que tu instancia de Alertmanager cambie entre las configuraciones correspondientes. Por ejemplo, puede que quieras cambiar los canales de notificación de alertas en función de los turnos de guardia rotativos o sustituir una configuración experimental de Alertmanager para probar una nueva ruta de alertas.

   Para especificar un nombre de secreto no predeterminado mediante el recurso OperatorConfig, haz lo siguiente:

   1. Crea un secreto a partir de tu archivo de configuración local de Alertmanager:

      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 de Alertmanager gestionado, edite el recurso modificando la sección managedAlertmanager, tal 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 hacer algún cambio en la configuración de Alertmanager, puedes editar la configuración de este Alertmanager actualizando el secreto que creaste anteriormente.

   Personalizar la URL externa

   Puede configurar la URL externa del Alertmanager gestionado para que las notificaciones de alertas puedan proporcionar un enlace de retrollamada a su interfaz de usuario de alertas. Es equivalente a usar la marca --web.external-url de Alertmanager de Prometheus.

   apiVersion: monitoring.googleapis.com/v1
   kind: OperatorConfig
   metadata:
     namespace: gmp-public
     name: config
   managedAlertmanager:
     externalURL: EXTERNAL_URL
   

   Alertmanager con despliegue automático

   Para configurar el evaluador de reglas de un Alertmanager autodesplegado, haz lo siguiente:

   1. Abre el recurso OperatorConfig para editarlo:

      kubectl -n gmp-public edit operatorconfig config
      

   2. Configura el recurso para que envíe alertas a tu servicio 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 distinto al de tu evaluador de reglas, puede que tengas que configurar un recurso Endpoints. Por ejemplo, si tu OperatorConfig indica que los endpoints de Alertmanager se pueden encontrar en el objeto Endpoints ns=alertmanager/name=alertmanager, puedes crear este objeto manualmente o mediante programación y rellenarlo con IPs accesibles del otro clúster. La sección de configuración AlertmanagerEndpoints proporciona opciones para configurar la autorización si es necesario.

   Ahorrar recursos cuando está inactivo

   Si no se configuran recursos Rules, ClusterRules o GlobalRules, GKE reduce a cero las implementaciones de rule-evaluator y Alertmanager para conservar los recursos del clúster para los clientes que no usan reglas ni alertas gestionadas. Estas implementaciones se ampliarán automáticamente cuando apliques un nuevo recurso Rules. Puedes forzar el escalado aplicando un recurso Rules que no haga nada.