Valutazione e avvisi delle regole gestite

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

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

Regole

Il valutatore delle regole gestito utilizza la risorsa regole per configurare le regole di registrazione e avviso. Di seguito è riportato un esempio di risorsa di 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 dell'array Prometheus rule_group upstream. 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 precedente esegue una query efficace su sum without(instance) (up{project_id="test-project", cluster="test-cluster", namespace="NAMESPACE_NAME"}). In questo modo, le regole di avviso o registrazione non valutano accidentalmente le metriche di applicazioni di cui potresti non essere a conoscenza.

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

Dopo alcuni minuti, diventa disponibile la metrica job:up:sum. Viene avviato anche l'avviso AlwaysFiring. Per informazioni su come inviare avvisi a 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 usando le etichette project_id e cluster, mentre GlobalRules selezionano tutti i dati nell'ambito delle metriche oggetto della query senza limitare le etichette.

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

Conversione dalle regole di Prometheus alle regole

La risorsa Regole fornisce un'interfaccia compatibile con le regole 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 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 che possono valutare tutte le serie temporali inviate a Managed Service per Prometheus da tutti gli spazi dei nomi in un determinato cluster. Le specifiche sono identiche a quelle di Rules. La regola 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 su 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 possono valutare tutte le serie temporali inviate a Managed Service per Prometheus in tutti i progetti nell'ambito delle metriche. Le specifiche sono identiche a quelle di Rules. La regola 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 quando ricevi avvisi sulle metriche di sistema di Google Kubernetes Engine.

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

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 dei singoli deployment, utilizza le risorse regole o ClusterRules per una maggiore affidabilità e per assicurarti che la valutazione non includa dati indesiderati. Consigliamo vivamente di conservare le etichette cluster e namespace nei risultati di valutazione delle regole, a meno che lo scopo della regola non sia aggregarle, altrimenti le prestazioni delle query potrebbero diminuire e potrebbero verificarsi limiti di cardinalità. La rimozione di entrambe le etichette è fortemente sconsigliata.

Valutazione di regole globali e multiprogetto

Dopo il deployment in Google Kubernetes Engine, il valutatore delle regole utilizza il progetto Google Cloud associato al cluster, che rileva automaticamente. Per valutare le regole che riguardano i progetti, devi configurare il valutatore delle regole che esegue la risorsa GlobalRules in modo da utilizzare un progetto con un ambito delle metriche multiprogetto. Puoi farlo in due modi:

  • Posiziona la risorsa GlobalRules in un progetto che ha un ambito delle metriche multiprogetto.
  • 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 dallo strumento di valutazione delle regole (che in genere è 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 mediante le metriche di Cloud Monitoring

Puoi utilizzare la risorsa GlobalRules per creare avvisi sulle metriche di sistema di Google Cloud utilizzando PromQL. Per istruzioni su come creare 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 delle risorse Regole, ClusterRules e GlobalRules utilizzando il tipo di risorsa Terraform kubernetes_manifest o il kubectl_manifest tipo di risorsa Terraform, che ti consente di specificare risorse personalizzate arbitrarie.

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

Fornisci le credenziali in modo esplicito

Durante l'esecuzione su GKE, il valutatore 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 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 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 viene avviata l'autenticazione nel backend della metrica con l'account di servizio specificato.

    Valutazione delle regole di scalabilità

    Il valutatore delle regole viene eseguito come un deployment a replica singola con richieste e limiti di risorse fissi. Potrebbero verificarsi interruzioni del carico di lavoro, ad esempio l'interruzione definitiva del carico di lavoro durante la valutazione di un numero elevato di regole. Per mitigare questo problema, puoi eseguire il deployment di una VerticalPodAutoscaler per scalare verticalmente il deployment. Innanzitutto, assicurati che la scalabilità automatica verticale dei pod sia abilitata nel 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, segnala di aver calcolato i suggerimenti relativi alle risorse per il carico di lavoro nella colonna "PROVIDED":

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

    Configurazione Alertmanager

    Puoi utilizzare la risorsa OperatorConfig per configurare il valutatore delle regole gestito in modo da inviare avvisi a Alertmanager Prometheus. Puoi inviare avvisi a Alertmanager gestito di cui è stato eseguito il deployment automatico oltre che a qualsiasi altro Alertmanager implementato automaticamente.

    Gestore avvisi gestito

    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 è impostata con un secret Kubernetes denominato specificamente contenente un file di configurazione Alertmanager.

    Per abilitare e configurare il reporting per l'istanza Alertmanager di cui è stato eseguito il deployment, segui questi passaggi:

    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 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 recupera il nuovo secret di configurazione e abilita Alertmanager gestito con le tue impostazioni.

    Personalizzazione del nome del secret di configurazione

    Alertmanager gestito supporta anche i nomi dei secret personalizzati per il caricamento della configurazione. Questa funzionalità è utile quando hai più secret di configurazione e vuoi che la tua istanza Alertmanager passi tra le configurazioni corrispondenti. Ad esempio, potresti voler modificare i canali di notifica di avviso in base ai turni di chiamata a rotazione oppure potresti voler invertire una configurazione sperimentale di AlertManager per testare una nuova route di avviso.

    Per specificare un nome del 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 di Alertmanager, puoi modificare la configurazione per 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 degli avvisi possano fornire un link di callback alla UI degli avvisi. Equivale all'utilizzo del flag --web.external-url upstream di Prometheus Alertmanager.

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

    Gestore avvisi con 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 di regole, potrebbe essere necessario configurare una risorsa Endpoint. Ad esempio, se il tuo 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 completarlo con IP raggiungibili dall'altro cluster. La sezione sulla configurazione degli endpoint avvisi fornisce opzioni per la configurazione dell'autorizzazione, se necessario.