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 eseguito il deployment automaticamente nell'ambito 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.

Regole

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

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 questo comando:

kubectl apply -n NAMESPACE_NAME -f https://raw.githubusercontent.com/GoogleCloudPlatform/prometheus-engine/v0.17.2/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 documentazione 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 di 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 per Prometheus da tutti gli spazi dei nomi di un determinato cluster. La specifica è identica a quella di Rules. La precedente regola di 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 una mesh di servizi. Per le metriche delle singole implementazioni, utilizza le risorse delle 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 di 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 per 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 a livello globale 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:

  • Posiziona la risorsa GlobalRules in un progetto con un ambito delle metriche multiprogetto.
  • 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 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, vedi 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.

Fornire le credenziali in modo esplicito

Quando viene eseguito su GKE, lo strumento di valutazione delle regole recupera automaticamente le credenziali dall'ambiente in base al 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 service account:

    gcloud iam service-accounts create gmp-test-sa

  3. Concedi le autorizzazioni necessarie 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 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 alla risorsa il testo mostrato in grassetto:

      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 collectionsezione 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 il account di servizio specificato.

    Valutazione delle regole di scalabilità

    Il deployment rule-evaluator viene eseguito come singola replica con richieste e limiti di risorse fissi. Potresti notare che il workload subisce interruzioni, ad esempio viene interrotto per esaurimento della memoria (OOMKilled) quando valuta un numero elevato di regole. Per risolvere questo problema, puoi utilizzare un VerticalPodAutoscaler per scalare verticalmente il deployment.

    Per configurare la scalabilità automatica verticale dei pod sul cluster:

    1. Assicurati che la scalabilità automatica verticale dei pod sia abilitata sul cluster Kubernetes.

    2. Configura la scalabilità automatica pod verticale utilizzando uno dei seguenti metodi:

      • Cluster Autopilot e Standard: abilita la scalabilità automatica verticale dei pod per i carichi di lavoro Managed Service per Prometheus nella risorsa OperatorConfig. Nei cluster Autopilot, il deployment rule-evaluator viene eseguito nello spazio dei nomi gke-gmp-system gestito, in cui la creazione diretta di risorse è limitata, pertanto devi configurare VPA tramite la risorsa OperatorConfig:

        kubectl -n gmp-public patch operatorconfig/config -p '{"scaling":{"vpa":{"enabled":true}}}' --type=merge

        Per saperne di più, consulta Attivare la scalabilità automatica verticale dei pod (VPA) per la raccolta gestita.

      • Norma VPA personalizzata sui cluster Standard: sui cluster Standard, se vuoi applicare una norma VerticalPodAutoscaler personalizzata solo a rule-evaluator senza attivare VPA per tutti i componenti di Managed Service per Prometheus, applica una risorsa VerticalPodAutoscaler nello spazio dei nomi gmp-system:

        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

    Per verificare che lo scalatore automatico funzioni, controlla lo stato della risorsa VerticalPodAutoscaler. Nei cluster Standard, controlla lo spazio dei nomi gmp-system; nei cluster Autopilot, controlla lo spazio dei nomi gke-gmp-system:

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

    Se il gestore della scalabilità automatica funziona, indica di aver calcolato i suggerimenti per le risorse per il workload nella colonna PROVIDED:

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

    Managed Alertmanager

    Managed Service per Prometheus esegue il deployment di un'istanza gestita di Alertmanager, a cui i valutatori di 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 di Alertmanager.

    Per attivare 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 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.

    Personalizzazione del nome del secret di configurazione

    Alertmanager gestito supporta anche nomi secret personalizzati per caricare la configurazione. Questa funzionalità è utile quando hai più secret di configurazione e vuoi che l'istanza 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 scambiare una configurazione sperimentale di Alertmanager per testare un nuovo percorso di avviso.

    Per specificare un nome Secret non predefinito utilizzando la risorsa OperatorConfig, esegui 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 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.

    Personalizzare l'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 autodeployato:

    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, potresti dover 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 fare lo scale up applicando una risorsa Rules che non fa nulla.