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 in sicurezza le regole nel contesto di un backend Prometheus globale, impedendoti di interferire con i dati di altri utenti in organizzazioni più grandi. Il componente viene disegnato automaticamente come parte della collezione 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 in base a query PromQL e regole di avviso Prometheus. Per ulteriori informazioni, consulta Criteri di avviso con PromQL.

Regole

Lo strumento di valutazione delle regole gestite utilizza la risorsa Regole per configurare le regole di registrazione e avviso. Di seguito è riportato un esempio di risorsa Regole:

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 rule_group a monte. Le regole di avviso e registrazione definite in Rules hanno come ambito project_id, cluster e namespace della risorsa. Ad esempio, la regola job:up:sum nella risorsa riportata sopra effettua query 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 cluster, esegui il seguente comando:

kubectl apply -n NAMESPACE_NAME -f https://raw.githubusercontent.com/GoogleCloudPlatform/prometheus-engine/v0.13.0/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 la sezione Configurazione di Alertmanager.

Le risorse ClusterRules e GlobalRules forniscono la stessa interfaccia della risorsa Rules, ma applicano le regole ad 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 sezione prometheus-engine/doc/api reference.

Conversione da regole Prometheus a Regole

La risorsa Regole fornisce un'interfaccia compatibile con le regole Prometheus per offrire un percorso di migrazione senza problemi per l'integrazione delle regole esistenti nella valutazione delle regole gestite. Puoi includere le regole esistenti in una risorsa Regole. 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 Regole 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 regole di registrazione e invio di avvisi che possono valutare tutte le serie temporali inviate a Managed Service per 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 ClusterRules risorsa:

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 un mesh di servizi. Per le metriche dei singoli implementazioni, utilizza le risorse Regole per assicurarti che la valutazione non includa dati indesiderati.

GlobalRules

Puoi utilizzare la risorsa GlobalRules per configurare 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 GlobalRules risorsa:

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 un ambito, un nome spazio o un cluster, devi utilizzare la risorsa GlobalRules quando scrivi regole o avvisi per le metriche di Cloud Monitoring. L'utilizzo di GlobalRules è obbligatorio anche per gli avvisi sulle metriche di sistema di Google Kubernetes Engine.

Se la regola non conserva le etichette project_id o location, per impostazione predefinita vengono utilizzati i valori del cluster.

Per le metriche di Managed Service per Prometheus, ti consigliamo di utilizzare GlobalRules solo per i rari casi d'uso in cui un avviso potrebbe richiedere dati su tutti i cluster contemporaneamente. Per le metriche dei singoli implementazioni, utilizza le risorse Rules o ClusterRules per una maggiore affidabilità e per assicurarti che la valutazione non includa dati indesiderati. Ti consigliamo vivamente di conservare le etichette cluster e namespace nei risultati di valutazione delle regole, a meno che lo scopo della regola non sia eliminare 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 a livello globale e per più progetti

Quando viene eseguito il deployment su Google Kubernetes Engine, lo valutatore delle regole utilizza il progetto Google Cloud associato al cluster, che viene rilevato automaticamente. Per valutare le regole che interessano più progetti, devi configurare il valutatore delle regole che esegue la risorsa GlobalRules in modo che utilizzi un progetto con un ambito di metriche multi-progetto. Puoi eseguire questa operazione in due modi:

• Inserisci la risorsa GlobalRules in un progetto con un ambito delle metriche per più progetti.
• Imposta il campo queryProjectID in OperatorConfig per utilizzare un progetto con un ambito delle metriche multi-progetto.

Devi anche aggiornare le autorizzazioni dell'account di servizio utilizzato dall'evaluator delle regole (di solito l'account di servizio predefinito sul nodo) in modo che 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 progetti, le regole vengono valutate a livello globale. Per ulteriori informazioni, consulta Ambiti delle metriche.

Avvisi con le metriche di Cloud Monitoring

Puoi utilizzare la risorsa GlobalRules per generare avvisi sulle metriche del sistema Google Cloud 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 kubernetes_manifest tipo di risorsa Terraform o il kubectl_manifest tipo di risorsa Terraform, entrambi che ti 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 all'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 l'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 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 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 inoltre di aggiungere queste credenziali alla sezione collection perché 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 metrico con l'account di servizio specificato.

   Valutazione delle regole di scalabilità

   L'Evaluator delle regole viene eseguito come deployment con una singola replica con richieste e limiti di risorse fissi. Potresti notare interruzioni del carico di lavoro, ad esempio l'interruzione dell'esecuzione per OOM (out of memory) durante la valutazione di un numero elevato di regole. Per attenuare 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. Quindi 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 controllandone lo 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 carico di lavoro nella colonna "FORNITO":

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

   Configurazioni di compressione

   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 il valutatore delle regole gestito in modo che invii avvisi a un Alertmanager di Prometheus. Puoi inviare avvisi all'Alertmanager gestito di cui è stato eseguito il deployment automatico, oltre a quelli di cui è stato eseguito il deployment autonomo.

   Alertmanager gestito

   Anteprima

   Questa funzionalità è soggetta ai "Termini delle Offerte pre-GA" nella sezione Termini generali del servizio 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 gli valutatori delle regole sono 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 di Alertmanager.

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

   1. Crea un file di configurazione locale contenente le impostazioni di Alertmanager (consulta 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 alcuni istanti, Managed Service per Prometheus recupera il nuovo secret di configurazione e attiva Alertmanager con le tue impostazioni.

   Personalizzazione del nome del secret di configurazione

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

   Per specificare un nome di secret non predefinito utilizzando la risorsa OperatorConfig, segui questi passaggi:

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

      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 i report di Alertmanager gestiti, 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 segreto 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 a utilizzare il flag --web.external-url di Prometheus Alertmanager.

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

   Alertmanager di cui è stato eseguito il deployment autonomo

   Per configurare l'attributo rule-evaluator per un Alertmanager di cui è stato eseguito il deployment autonomo:

   1. Apri la risorsa OperatorConfig per la modifica:

      kubectl -n gmp-public edit operatorconfig config
      

   2. Configura la risorsa per inviare 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 rispetto al valutatore delle regole, potrebbe essere necessario configurare una risorsa Endpoints. Ad esempio, se OperatorConfig indica che gli endpoint Alertmanager possono essere trovati nell'oggetto Endpoints ns=alertmanager/name=alertmanager, puoi creare questo oggetto manualmente o tramite programmazione e compilarlo con gli IP raggiungibili dall'altro cluster. La sezione di configurazione AlertmanagerEndpoints fornisce opzioni per la configurazione dell'autorizzazione, se necessario.