Valutazione e avvisi di regole gestite

Google Cloud Managed Service per Prometheus supporta la valutazione e gli avvisi di regole 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 modo sicuro le regole nel contesto di un backend Prometheus globale, impedendoti di interferire con i dati di altri utenti in organizzazioni più grandi. Il deployment del componente viene automaticamente eseguito nell'ambito della raccolta gestita durante l'esecuzione sui cluster Kubernetes.

Puoi scrivere regole e avvisi sia per le metriche Managed Service per Prometheus che per le metriche di Cloud Monitoring. Quando scrivi le regole per le metriche di Cloud Monitoring, devi utilizzare la risorsa GlobalRules.

Regole

Il responsabile della valutazione delle regole utilizza la risorsa Regole per configurare le regole di registrazione e avviso. Di seguito è riportato un esempio di risorsa delle 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. L'ambito delle regole di avviso e registrazione definite in Rules è project_id, cluster e namespace della risorsa. Ad esempio, la regola job:up:sum nella risorsa precedente esegue effettivamente delle query su sum without(instance) (up{project_id="test-project", cluster="test-cluster", namespace="NAMESPACE_NAME"}). Questa garanzia garantisce che le regole di avviso o registrazione non valutino accidentalmente le metriche di applicazioni di cui potresti non essere a conoscenza.

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

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

Dopo alcuni minuti, la metrica job:up:sum diventa disponibile. Anche l'avviso AlwaysFiring inizia ad attivarsi. 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 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 oggetto di query senza limitare le etichette.

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

Conversione dalle regole di Prometheus a regole

La risorsa Regole fornisce un'interfaccia compatibile con le regole di Prometheus per fornire un percorso di migrazione senza interruzioni per incorporare le regole esistenti nella valutazione delle regole gestite. Puoi includere le regole esistenti in una risorsa Regole. Ad esempio, di seguito è riportata una regola di Prometheus:

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

La risorsa Regole corrispondente, con la regola di Prometheus originale in grassetto, segue:

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 avviso in grado di valutare tutte le serie temporali inviate a Managed Service per Prometheus da tutti gli spazi dei nomi di un determinato cluster. Le specifiche sono identiche a quelle di Rules. La regola di Prometheus di esempio precedente 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 sulle metriche orizzontali, come quelle prodotte da un mesh di servizi. Per le metriche dei singoli deployment, utilizza le risorse delle regole per assicurarti che la valutazione non includa dati indesiderati.

GlobalRules

Puoi utilizzare la risorsa GlobalRules per configurare regole di registrazione e avviso che possano valutare tutte le serie temporali inviate a Managed Service per Prometheus in tutti i progetti all'interno di un ambito delle metriche. Le specifiche sono identiche a quelle di Rules. La regola di Prometheus di esempio precedente 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 hanno come ambito uno spazio dei nomi o un cluster, devi utilizzare la risorsa GlobalRules quando scrivi regole o avvisi per le metriche di Cloud Monitoring. L'utilizzo di GlobalRules è richiesto anche per gli avvisi sulle metriche di sistema di Google Kubernetes Engine.

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

Per le metriche di Managed Service per Prometheus, 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 di singoli deployment, utilizza le risorse Regole 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 aggregare tali etichette, altrimenti le prestazioni delle query potrebbero diminuire e potresti riscontrare limiti di cardinalità. È sconsigliato rimuovere entrambe le etichette.

Valutazione di più progetti e regole globali

Quando viene eseguito il deployment in Google Kubernetes Engine, il responsabile della valutazione delle regole utilizza il progetto Google Cloud associato al cluster, che lo strumento di valutazione delle regole rileva automaticamente. Per valutare le regole che comprendono progetti, devi configurare il valutatore delle regole che esegue la risorsa GlobalRules per utilizzare un progetto con un ambito delle metriche multiprogetto. Puoi farlo in due modi:

  • Inserisci la risorsa GlobalRules in un progetto che abbia un ambito di metriche multiprogetto.
  • 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 dallo strumento di valutazione delle regole (che di solito è l'account di servizio predefinito sul nodo) in modo che l'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 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 sulle metriche di sistema di 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 regole, ClusterRules e GlobalRules utilizzando il tipo di risorsa Terraform kubernetes_manifest o il kubectl_manifesttipo di risorsa Terraform, che ti 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 responsabile della 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 per il 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 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 anche di aggiungere queste credenziali alla sezione collection per garantire il funzionamento della raccolta gestita.

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

    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 automaticamente il deployment oltre a a Alertmanager di cui è stato eseguito il deployment automatico.

    Gestore avvisi gestito

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

    Per abilitare e configurare i report nell'istanza Alertmanager di cui è stato eseguito il deployment, segui questi passaggi:

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

      touch alertmanager.yaml
      
    2. Aggiorna il file con le impostazioni di Alertmanager desiderate 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 acquisisce il nuovo secret di configurazione e abilita il gestore degli avvisi gestito con le tue impostazioni.

    Personalizzazione del nome del secret di configurazione

    Il gestore Alertmanager supporta anche i nomi personalizzati dei secret per il caricamento della configurazione. Questa funzionalità è utile quando hai più secret di configurazione e vuoi che l'istanza Alertmanager passi tra le configurazioni corrispondenti. Ad esempio, potresti voler modificare i canali di notifica degli avvisi in base ai turni di chiamata a rotazione o cambiare una configurazione sperimentale di Alertmanager per testare una nuova route di avviso.

    Per specificare un nome secret non predefinito utilizzando la risorsa OperatorConfig:

    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 di Alertmanager, puoi modificare la configurazione di Alertmanager aggiornando il secret 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. Equivale a utilizzare il flag --web.external-url di Prometheus Alertmanager a monte.

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

    Gestione avvisi con deployment autonomo

    Per configurare il valutatore delle regole per un Alertmanager con deployment autonomo, segui questi passaggi:

    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 dal responsabile della valutazione delle regole, potrebbe essere necessario 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 manualmente o in modo programmatico questo oggetto e popolarlo con IP raggiungibili dall'altro cluster. La sezione di configurazione di AlertmanagerEndpoints fornisce opzioni per la configurazione dell'autorizzazione, se necessario.