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 per la valutazione delle regole che consente di scrivere in sicurezza le regole nel contesto di un ambiente Prometheus globale , impedendoti di interferire con il traffico di altri utenti. in modo che i dati le tue organizzazioni. Il deployment del componente viene eseguito automaticamente nell'ambito dei raccolta durante l'esecuzione su cluster Kubernetes.

Puoi scrivere regole e avvisi su entrambe le metriche Managed Service per Prometheus e metriche di Cloud Monitoring. Devi utilizzare Risorsa GlobalRules durante la scrittura delle regole per Cloud Monitoring metriche di valutazione.

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

Regole

Il valutatore delle regole gestite utilizza le regole risorsa su e 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 a quello di Prometheus a monte Array rule_group. 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 vengano accidentalmente e valutano le metriche di applicazioni che potresti anche non conoscere.

Per applicare le regole di esempio al cluster, esegui questo 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 su come inviare avvisi a AlertManager, vedi 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 dalle regole di Prometheus alle regole

La risorsa Rules (Regole) fornisce un'interfaccia compatibile con le regole Prometheus per: Offrire un percorso di migrazione senza soluzione di continuità per l'integrazione delle regole esistenti e la valutazione delle regole gestite. Puoi includere le regole esistenti in una sezione Regole risorsa. 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 la registrazione regole di avviso in grado di valutare tutte le serie temporali inviate Managed Service per Prometheus da tutti gli spazi dei nomi di un determinato cluster. Le specifiche sono identiche a quelle di Rules. La precedente regola di 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 service mesh. 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 di 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 rientrano nell'ambito di una dello spazio dei nomi o di cluster, devi utilizzare la risorsa GlobalRules quando scrivi le 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 il valore project_id o location, vengono utilizzati per impostazione predefinita 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 scoraggiati.

Valutazione delle regole a livello globale e per più progetti

Quando viene eseguito il deployment su Google Kubernetes Engine, il valutatore delle regole utilizza Progetto Google Cloud associato al cluster, che il valutatore delle regole 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:

• Posiziona la risorsa GlobalRules in un progetto con metriche multiprogetto l'ambito di attività.
• Imposta il campo queryProjectID in OperatorConfig per utilizzare un progetto con un ambito delle metriche multiprogetto.

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 saperne di più, consulta Ambiti delle metriche.

Avvisi con le metriche di Cloud Monitoring

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

Configurazione di regole e avvisi mediante Terraform

Puoi automatizzare la creazione e la gestione di regole, ClusterRules e Risorse GlobalRules usando lo strumento Terraform kubernetes_manifest risorsa o kubectl_manifest Tipo di risorsa Terraform, uno di che consente 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

Durante l'esecuzione su GKE, il valutatore recupera automaticamente le credenziali dall'ambiente in base l'account di servizio del nodo. Nei cluster Kubernetes non GKE, le credenziali devono essere fornita tramite la risorsa OperatorConfig in dello 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 visualizzato 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 anche queste credenziali alla sezione collection per far sì che la raccolta gestita funzioni.

   2. Salva il file e chiudi l'editor. Dopo l'applicazione della modifica, i pod vengono ricreati e iniziano l'autenticazione al backend metrico con l'account di servizio specificato.

   Valutazione delle regole di scalabilità

   Il valutatore delle regole viene eseguito come un deployment di replica singola con risorsa fissa richieste e limiti. Potresti notare interruzioni del carico di lavoro, ad esempio l'interruzione OOMKilled 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 Scalabilità automatica pod verticale sia abilitata sul 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 controllando lo stato del gestore della scalabilità automatica:

   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
   

   Comprimi configurazioni

   Se hai molte risorse Rules, potresti esaurire lo spazio ConfigMap. Per risolvere il problema questo, attiva la compressione gzip nel tuo Risorsa OperatorConfig:

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

   Configurazione 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 a Alertmanager gestito di cui è stato eseguito il deployment automatico oltre che a qualsiasi altro Alertmanager di cui è stato eseguito il deployment autonomo.

   Gestore avvisi 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 i valutatori delle regole sono automaticamente configurati 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 creerai 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 cambiare i canali di notifica degli avvisi in base ai turni di chiamata, oppure passa a una configurazione sperimentale Alertmanager per testare una nuova route di avviso.

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

   1. Crea un secret dal tuo 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 abilitare i report 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 Alertmanager, puoi quindi modificare la configurazione per questo Alertmanager aggiornando il campo Secret che hai creato in precedenza.

   Personalizzazione dell'URL esterno

   Puoi configurare l'URL esterno per AlertManager gestito in modo che le notifiche possono fornire un link di callback all'UI per gli avvisi. Equivale a utilizzare Prometheus Alertmanager upstream --web.external-url flag.

   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 il valutatore delle regole 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, potresti dover configurare una risorsa endpoint. 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.