Valutazione delle regole gestite e avvisi

Google Cloud Managed Service per Prometheus supporta la valutazione delle regole e gli avvisi compatibili con Prometheus. Questo documento descrive come configurare la valutazione delle regole gestite.

Valutazione delle regole

Managed Service per Prometheus fornisce un componente di valutazione delle regole che ti consente di scrivere regole in modo sicuro nel contesto di un backend Prometheus globale, impedendoti di interferire con i dati di altri utenti nelle organizzazioni più grandi. Il componente viene implementato automaticamente come parte della raccolta gestita quando viene eseguito su cluster Kubernetes.

Puoi scrivere regole e avvisi sia sulle metriche di Managed Service per Prometheus sia sulle metriche di Cloud Monitoring. Devi utilizzare la risorsa GlobalRules quando scrivi regole per le metriche di Cloud Monitoring.

Nota :puoi creare criteri di avviso di Cloud Monitoring basati su query PromQL e regole di avviso di Prometheus. Per ulteriori informazioni, consulta Criteri di avviso con PromQL.

Regole

Lo strumento di valutazione delle regole gestito utilizza la risorsa Rules per configurare le regole di registrazione e avviso. Di seguito è riportata una risorsa Rules di esempio:

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)

Il formato dell'elemento .spec.groups è identico all'array Prometheus upstream rule_group. Le regole di avviso e registrazione definite in Rules sono limitate a project_id, cluster e namespace della risorsa. Ad esempio, la regola job:up:sum nella risorsa precedente esegue query in modo efficace su sum without(instance) (up{project_id="test-project", cluster="test-cluster", namespace="NAMESPACE_NAME"}). Questa garanzia assicura che le regole di avviso o registrazione non valutino accidentalmente le metriche di applicazioni che potresti non conoscere.

Per applicare le regole di esempio al tuo cluster, esegui il comando seguente:

kubectl apply -n NAMESPACE_NAME -f https://raw.githubusercontent.com/GoogleCloudPlatform/prometheus-engine/v0.15.3/examples/rules.yaml

Dopo alcuni minuti, la metrica job:up:sum diventa disponibile. Viene attivato anche l'avviso AlwaysFiring. Per informazioni su come inviare avvisi a un Alertmanager, consulta Configurazione di Alertmanager.

Le risorse ClusterRules e GlobalRules forniscono la stessa interfaccia della risorsa Rules, ma applicano le regole a ambiti più ampi. ClusterRules seleziona i dati utilizzando le etichette project_id e cluster, mentre GlobalRules seleziona tutti i dati nell'ambito delle metriche sottoposte a query senza limitare le etichette.

Per la documentazione di riferimento su tutte le risorse personalizzate di Managed Service per Prometheus, consulta la guida di riferimento dell'API prometheus-engine/doc/api.

Conversione dalle regole di Prometheus alle regole

La risorsa Rules fornisce un'interfaccia compatibile con le regole di Prometheus per fornire un percorso di migrazione semplice per incorporare le regole esistenti nella valutazione delle regole gestite. Puoi includere le regole esistenti in una risorsa Rules. Ad esempio, la seguente è una regola Prometheus:

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

Di seguito è riportata la risorsa Rules corrispondente, con la regola Prometheus originale in grassetto:

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

Puoi utilizzare la risorsa ClusterRules per configurare le regole di registrazione e avviso che possono valutare tutte le serie temporali inviate a Managed Service for Prometheus da tutti gli spazi dei nomi di un determinato cluster. La specifica è identica a quella di Rules. La precedente regola Prometheus di esempio diventa la seguente risorsa 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)

Ti consigliamo di utilizzare le risorse ClusterRules solo per le metriche orizzontali, come quelle prodotte da unmesh di servizih. Per le metriche delle singole implementazioni, utilizza le risorse Regole per assicurarti che la valutazione non includa dati non intenzionali.

GlobalRules

Puoi utilizzare la risorsa GlobalRules per configurare le regole di registrazione e avviso che possono valutare tutte le serie temporali inviate a Managed Service per Prometheus in tutti i progetti all'interno di un ambito delle metriche. La specifica è identica a quella di Rules. La precedente regola Prometheus di esempio diventa la seguente risorsa 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)

Poiché le metriche di Cloud Monitoring non sono limitate a uno spazio dei nomi o a un cluster, devi utilizzare la risorsa GlobalRules quando scrivi regole o avvisi per le metriche di Cloud Monitoring. L'utilizzo di GlobalRules è necessario anche quando vengono generati avvisi sulle metriche di sistema di Google Kubernetes Engine.

Se la regola non conserva le etichette project_id o location, queste vengono impostate sui valori del cluster.

Per le metriche di Managed Service for Prometheus, ti consigliamo di utilizzare GlobalRules solo per i rari casi d'uso in cui un avviso potrebbe richiedere dati in tutti i cluster contemporaneamente. Per le metriche dei singoli deployment, utilizza le risorse Rules o ClusterRules per una maggiore affidabilità e per assicurarti che la valutazione non includa dati non intenzionali. Ti consigliamo vivamente di conservare le etichette cluster e namespace nei risultati della valutazione delle regole, a meno che lo scopo della regola non sia quello di aggregare queste etichette, altrimenti il rendimento delle query potrebbe diminuire e potresti riscontrare limiti di cardinalità. La rimozione di entrambe le etichette è fortemente sconsigliata.

Valutazione delle regole globali e per più progetti

Quando viene eseguito il deployment su Google Kubernetes Engine, il valutatore di regole utilizza il progettoGoogle Cloud associato al cluster, che il valutatore di regole rileva automaticamente. Per valutare le regole che si estendono a più progetti, devi configurare il valutatore di regole che esegue la risorsa GlobalRules in modo che utilizzi un progetto con un ambito delle metriche multiprogetto. Puoi farlo in due modi:

• Inserisci la risorsa GlobalRules in un progetto con un ambito delle metriche multi-progetto.
• Imposta il campo queryProjectID all'interno di OperatorConfig per utilizzare un progetto con un ambito delle metriche multiprogetto.

Devi anche aggiornare le autorizzazioni del account di servizio utilizzato dal valutatore delle regole (che di solito è il account di servizio predefinito sul nodo) in modo che il account di servizio possa leggere dal progetto di definizione dell'ambito e scrivere in tutti i progetti monitorati nell'ambito delle metriche.

Se l'ambito delle metriche contiene tutti i tuoi progetti, le regole vengono valutate a livello globale. Per ulteriori informazioni, consulta Ambiti delle metriche.

Avvisi tramite le metriche di Cloud Monitoring

Puoi utilizzare la risorsa GlobalRules per generare avvisi sulle Google Cloud metriche di sistema utilizzando PromQL. Per istruzioni su come creare una query valida, consulta PromQL per le metriche di Cloud Monitoring.

Configurare regole e avvisi utilizzando Terraform

Puoi automatizzare la creazione e la gestione delle risorse Rules, ClusterRules e GlobalRules utilizzando il tipo di risorsa Terraform kubernetes_manifest o il tipo di risorsa Terraform kubectl_manifest, entrambi consentono di specificare risorse personalizzate arbitrarie.

Per informazioni generali sull'utilizzo di Google Cloud con Terraform, consulta Terraform con Google Cloud.

Fornisci le credenziali in modo esplicito

Quando viene eseguito su GKE, lo strumento di valutazione delle regole recupera automaticamente le credenziali dall'ambiente in base all'account di servizio del nodo. Nei cluster Kubernetes non GKE, le credenziali devono essere fornite esplicitamente tramite la risorsa OperatorConfig nello spazio dei nomi gmp-public.

1. Imposta il contesto sul progetto di destinazione:

   gcloud config set project PROJECT_ID
   

2. Crea un account di servizio:

   gcloud iam service-accounts create gmp-test-sa
   

3. Concedi le autorizzazioni richieste al account di servizio:

   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 e scarica una chiave per il account di servizio:

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

5. Aggiungi il file della chiave come secret al tuo cluster non GKE:

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

6. Apri la risorsa OperatorConfig per la modifica:

   kubectl -n gmp-public edit operatorconfig config
   

   1. Aggiungi il testo mostrato in grassetto alla risorsa:

      apiVersion: monitoring.googleapis.com/v1
      kind: OperatorConfig
      metadata:
        namespace: gmp-public
        name: config
      rules:
        credentials:
          name: gmp-test-sa
          key: key.json
      

      Assicurati di aggiungere queste credenziali alla sezione collection in modo che la raccolta gestita funzioni.

   2. Salva il file e chiudi l'editor. Una volta applicata la modifica, i pod vengono ricreati e iniziano l'autenticazione al backend delle metriche con iaccount di serviziont specificato.

   Valutazione delle regole di scalabilità

   L'evaluator delle regole viene eseguito come Deployment di una singola replica con richieste e limiti di risorse fissi. Potresti notare interruzioni del carico di lavoro, ad esempio l'arresto anomalo per esaurimento della memoria quando valuti un numero elevato di regole. Per risolvere questo problema, puoi eseguire il deployment di un VerticalPodAutoscaler per scalare verticalmente il deployment. Innanzitutto, assicurati che la scalabilità automatica pod verticale sia abilitata nel tuo cluster Kubernetes. Poi applica una risorsa VerticalPodAutoscaler come la seguente:

   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
   

   Puoi verificare che il gestore della scalabilità automatica funzioni controllando il suo stato:

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

   Se il gestore della scalabilità automatica funziona, indica di aver calcolato i consigli sulle risorse per il workload nella colonna "FORNITO":

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

   Comprimi configurazioni

   Se hai molte risorse Rules, potresti esaurire lo spazio ConfigMap. Per risolvere il problema, attiva la compressione gzip nella risorsa OperatorConfig:

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

   Configurazione di Alertmanager

   Puoi utilizzare la risorsa OperatorConfig per configurare lo strumento di valutazione delle regole gestito in modo che invii avvisi a un Alertmanager di Prometheus. Puoi inviare avvisi all'Alertmanager gestito e implementato automaticamente, oltre a qualsiasi Alertmanager implementato autonomamente.

   Managed Alertmanager

   Anteprima

   Questa funzionalità è soggetta ai "Termini delle Offerte pre-GA" nella sezione Termini di servizio generali dei Termini specifici dei servizi. Le funzionalità pre-GA sono disponibili "così come sono" e potrebbero avere un supporto limitato. Per saperne di più, consulta le descrizioni della fase di lancio.

   Managed Service per Prometheus esegue il deployment di un'istanza gestita di Alertmanager, a cui i valutatori delle regole vengono configurati automaticamente per inoltrare gli avvisi. Per impostazione predefinita, questa configurazione viene impostata con un secret Kubernetes denominato in modo specifico contenente un file di configurazione Alertmanager.

   Per attivare e configurare il reporting per l'istanza di Alertmanager di cui è stato eseguito il deployment:

   1. Crea un file di configurazione locale contenente le impostazioni di Alertmanager (vedi i modelli di configurazione di esempio):

      touch alertmanager.yaml
      

   2. Aggiorna il file con le impostazioni di Alertmanager che preferisci e crea un secret denominato alertmanager nello spazio dei nomi gmp-public:

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

   Dopo qualche istante, Managed Service per Prometheus rileva il nuovo secret di configurazione e abilita Alertmanager gestito con le tue impostazioni.

   Personalizzare il nome del secret di configurazione

   Alertmanager gestito supporta anche nomi secret personalizzati per il caricamento della configurazione. Questa funzionalità è utile quando hai più secret di configurazione e vuoi che l'istanza di Alertmanager passi da una configurazione all'altra. Ad esempio, potresti voler modificare i canali di notifica degli avvisi in base ai turni di reperibilità a rotazione oppure potresti voler inserire una configurazione sperimentale di Alertmanager per testare un nuovo percorso di avviso.

   Per specificare un nome secret non predefinito utilizzando la risorsa OperatorConfig, svolgi le seguenti operazioni:

   1. Crea un secret dal file di configurazione Alertmanager locale:

      kubectl create secret generic SECRET_NAME \
        -n gmp-public \
        --from-file=FILE_NAME
      

   2. Apri la risorsa OperatorConfig per la modifica:

      kubectl -n gmp-public edit operatorconfig config
      

   3. Per attivare la generazione di report di Alertmanager gestito, modifica la risorsa modificando la sezione managedAlertmanager come mostrato nel seguente testo in grassetto:

      apiVersion: monitoring.googleapis.com/v1
      kind: OperatorConfig
      metadata:
        namespace: gmp-public
        name: config
      managedAlertmanager:
        configSecret:
          name: SECRET_NAME
          key: FILE_NAME
      

   Se devi apportare modifiche alla configurazione di Alertmanager, puoi modificare la configurazione di questo Alertmanager aggiornando il secret che hai creato in precedenza.

   Personalizzazione dell'URL esterno

   Puoi configurare l'URL esterno per Alertmanager gestito in modo che le notifiche di avviso possano fornire un link di callback alla tua UI di avviso. Ciò equivale all'utilizzo del flag --web.external-url di Prometheus Alertmanager upstream.

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

   Alertmanager con deployment autonomo

   Per configurare lo strumento di valutazione delle regole per un Alertmanager autogestito:

   1. Apri la risorsa OperatorConfig per la modifica:

      kubectl -n gmp-public edit operatorconfig config
      

   2. Configura la risorsa in modo che invii avvisi al servizio 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
      

   Se Alertmanager si trova in un cluster diverso dal valutatore di regole, potrebbe essere necessario configurare una risorsa Endpoints. Ad esempio, se OperatorConfig indica che gli endpoint Alertmanager si trovano nell'oggetto Endpoints ns=alertmanager/name=alertmanager, puoi creare manualmente o a livello di programmazione questo oggetto e popolarlo con IP raggiungibili dall'altro cluster. La sezione di configurazione AlertmanagerEndpoints fornisce opzioni per la configurazione dell'autorizzazione, se necessario.

   Risparmio di risorse in caso di inattività

   Quando non sono configurate risorse Rules, ClusterRules o GlobalRules, GKE ridimensiona a zero i deployment di rule-evaluator e Alertmanager per conservare le risorse del cluster per i clienti che non utilizzano regole o avvisi gestiti. Questi deployment verranno scalati automaticamente quando applichi una nuova risorsa Rules. Puoi forzarli a scalare applicando una risorsa Rules che non fa nulla.