Valutazione e avvisi delle regole gestite

Google Cloud Managed Service per Prometheus supporta la valutazione delle regole compatibili con Prometheus e avvisi di sicurezza. 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.

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 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 di Prometheus a monte Array rule_group. Avvisi e registrazione Le regole definite in Rules hanno come ambito project_id, cluster e namespace della risorsa. Ad esempio, la regola job:up:sum nella risorsa riportata sopra query in modo efficace 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.12.0/examples/rules.yaml

Dopo alcuni minuti, diventa disponibile la metrica job:up:sum. Viene avviato anche l'avviso AlwaysFiring. Per informazioni su su come inviare avvisi a AlertManager, vedi Configurazione di Alertmanager.

Il parametro ClusterRules e Le risorse GlobalRules offrono lo stesso come risorsa Rules, ma applicano le regole ad ambiti più ampi. ClusterRules seleziona i dati usando le etichette project_id e cluster, e GlobalRules selezionano tutti i dati nell'ambito delle metriche sottoposte a query senza delle etichette.

Per la documentazione di riferimento su tutti i servizi Managed Service per Prometheus di risorse personalizzate, consulta riferimento prometheus-engine/doc/api.

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, 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 versione originale di Prometheus 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 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 su metriche orizzontali, come quelle generate da un mesh di servizi. Per le metriche dei singoli deployment, utilizzare le risorse delle regole per garantire che la valutazione non includa errori e i dati di Google Cloud.

GlobalRules

Puoi utilizzare la risorsa GlobalRules per configurare la registrazione regole di avviso in grado di valutare tutte le serie temporali inviate Managed Service per Prometheus in tutti i progetti in un ambito delle metriche. Le specifiche sono identiche a quelle 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. È obbligatorio anche utilizzare GlobalRules quando ricevi 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 quei rari casi d'uso in cui un avviso potrebbe richiedere dati tra in tutti i cluster contemporaneamente. Per le metriche dei singoli deployment, usa le regole alle risorse ClusterRules per una maggiore affidabilità e per garantire che la valutazione non include dati indesiderati. Ti consigliamo vivamente di conservare cluster e namespace etichetta nei risultati di valutazione delle regole, a meno che lo scopo della regola consiste nell'aggregare le etichette, altrimenti le prestazioni delle query potrebbero diminuire potresti riscontrare limiti di cardinalità. La rimozione di entrambe le etichette è fortemente scoraggiati.

Valutazione di regole globali e multiprogetto

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 riguardano i progetti, devi configurare il valutatore delle regole che esegue la risorsa GlobalRules per utilizzare un progetto un ambito delle metriche multiprogetto. Puoi farlo 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 lo 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 su tutti a progetti monitorati nell'ambito delle metriche.

Se l'ambito delle metriche contiene tutti i progetti, le regole valutano a livello globale. Per saperne di più, consulta Ambiti delle metriche.

Avvisi mediante 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. Una volta applicata la modifica, vengono ricreati e avviano l'autenticazione nella metrica 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. Potrebbero verificarsi interruzioni del carico di lavoro, ad esempio come OOM Eliminato durante la valutazione di un elevato numero di regole. Per mitigare questo problema, puoi eseguire il deployment VerticalPodAutoscaler per scalare verticalmente il deployment. Innanzitutto, assicurati che Scalabilità automatica pod verticale sia abilitata sul tuo cluster Kubernetes. Poi applica un 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 la risorsa per il carico di lavoro nel colonna:

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

    Configurazioni di compressione

    Se hai molte risorse di regole, 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 Alertmanager 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

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

    Per abilitare e configurare il reporting per l'istanza Alertmanager di cui è stato eseguito il deployment, procedi nel seguente modo:

    1. Crea un file di configurazione locale contenente le tue 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 creerai 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 config Secret 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 alla tua istanza Alertmanager per passare tra le configurazioni corrispondenti. 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 del secret non predefinito utilizzando la risorsa OperatorConfig, procedi nel seguente modo:

    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
    

    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 delle regole, potresti dover configurare una risorsa endpoint. Ad esempio, se OperatorConfig indica che gli endpoint Alertmanager possono essere trovato nell'oggetto Endpoints ns=alertmanager/name=alertmanager, puoi manualmente o in modo programmatico, crea personalmente questo oggetto e compilalo con IP raggiungibili dall'altro cluster. La Sezione di configurazione AlertmanagerEndpoints fornisce opzioni per la configurazione dell'autorizzazione, se necessario.