Valutazione e avvisi di regole di cui è stato eseguito il deployment autonomo

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 di cui è stato eseguito il deployment autonomo, incluso il componente autonomo di valutazione delle regole.

Devi seguire queste istruzioni solo se vuoi eseguire regole e avvisi per l'archivio dati globale.

Valutazione delle regole per la raccolta con deployment automatico

Dopo aver eseguito il deployment di Managed Service per Prometheus, puoi continuare a valutare le regole localmente in ogni istanza di cui è stato eseguito il deployment utilizzando il campo rule_files del file di configurazione di Prometheus. Tuttavia, la finestra di query massima per le regole è limitata dal periodo di conservazione dei dati locali da parte del server.

La maggior parte delle regole viene eseguita solo negli ultimi minuti di dati, pertanto l'esecuzione delle regole su ogni server locale è spesso una strategia valida. In questo caso, non vengono eseguite ulteriori configurazioni necessaria.

Tuttavia, a volte è utile poter valutare le regole a fronte del backend delle metriche, ad esempio quando tutti i dati di una regola non sono collocati in una un'istanza Prometheus specifica. In questi casi, Managed Service per Prometheus è un componente anche per la valutazione delle regole.

Prima di iniziare

Questa sezione descrive la configurazione necessaria per le attività descritte in questo documento.

Configura il tuo ambiente

Per evitare di inserire ripetutamente l'ID progetto o il nome del cluster, esegui la seguente configurazione:

  • Configura gli strumenti a riga di comando come segue:

    • Configura Google Cloud CLI in modo che faccia riferimento all'ID del tuo progetto Google Cloud:

      gcloud config set project PROJECT_ID

    • Configura l'interfaccia a riga di comando kubectl per utilizzare il tuo cluster:

      kubectl config set-cluster CLUSTER_NAME

    Per ulteriori informazioni su questi strumenti, consulta le seguenti risorse:

Configura uno spazio dei nomi

Crea lo spazio dei nomi Kubernetes NAMESPACE_NAME per le risorse che crei nell'ambito dell'applicazione di esempio:

kubectl create ns NAMESPACE_NAME

Verifica le credenziali dell'account di servizio

Puoi saltare questa sezione se nel tuo cluster Kubernetes è attivata la federazione delle identità per i carichi di lavoro per GKE.

Quando viene eseguito su GKE, Managed Service per Prometheus recupera automaticamente le credenziali dall'ambiente in base all'account di servizio predefinito di Compute Engine. L'account di servizio predefinito ha le autorizzazioni necessarie, monitoring.metricWriter e monitoring.viewer, per impostazione predefinita. Se non utilizzi la federazione delle identità per i carichi di lavoro per GKE e in precedenza avevi rimosso uno di questi ruoli dall'account di servizio del nodo predefinito, Devi aggiungere di nuovo le autorizzazioni mancanti prima di continuare.

Se non esegui l'operazione su GKE, consulta Fornire le credenziali in modo esplicito.

Configura un account di servizio per la federazione delle identità per i carichi di lavoro per GKE

Puoi saltare questa sezione se il tuo cluster Kubernetes non dispone Federazione delle identità dei carichi di lavoro per GKE abilitata.

Managed Service per Prometheus acquisisce i dati delle metriche utilizzando l'API Cloud Monitoring. Se il tuo cluster utilizza la federazione delle identità per i carichi di lavoro per GKE, devi concedere all'account di servizio Kubernetes l'autorizzazione all'API Monitoring. Questa sezione descrive quanto segue:

Crea e associa l'account di servizio

Questo passaggio viene visualizzato in diverse posizioni all'interno di Managed Service per Prometheus documentazione. Se hai già eseguito questo passaggio nell'ambito di un'attività precedente, non devi ripeterlo. Vai a Autorizzare l'account di servizio.

La seguente sequenza di comandi crea l'account di servizio gmp-test-sa e lo associa all'account di servizio Kubernetes predefinito Spazio dei nomi NAMESPACE_NAME:

gcloud config set project PROJECT_ID \
&&
gcloud iam service-accounts create gmp-test-sa \
&&
gcloud iam service-accounts add-iam-policy-binding \
  --role roles/iam.workloadIdentityUser \
  --member "serviceAccount:PROJECT_ID.svc.id.goog[NAMESPACE_NAME/default]" \
  gmp-test-sa@PROJECT_ID.iam.gserviceaccount.com \
&&
kubectl annotate serviceaccount \
  --namespace NAMESPACE_NAME \
  default \
  iam.gke.io/gcp-service-account=gmp-test-sa@PROJECT_ID.iam.gserviceaccount.com

Se usi uno spazio dei nomi GKE o un account di servizio diverso, e regolare i comandi in modo appropriato.

Autorizza l'account di servizio

I gruppi di autorizzazioni correlate vengono raccolti in ruoli e li concedi a un entità, in questo esempio l'account di servizio Google Cloud. Per ulteriori informazioni sui ruoli di monitoraggio, consulta Controllo dell'accesso.

Il comando seguente concede l'account di servizio Google Cloud, gmp-test-sa, i ruoli dell'API Monitoring necessari lettura e scrittura dati delle metriche.

Se hai già concesso l'account di servizio Google Cloud un ruolo specifico nell'ambito dell'attività precedente, non dovrai ripeterlo.

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

Eseguire il debug della configurazione di Workload Identity Federation for GKE

Se hai difficoltà a far funzionare Workload Identity Federation per GKE, consulta la documentazione per la verifica della configurazione di Workload Identity Federation per GKE e la guida alla risoluzione dei problemi di Workload Identity Federation per GKE.

Poiché gli errori di battitura e i testi incollati parziali sono le fonti più comuni di errori quando configurazione della federazione delle identità per i carichi di lavoro per GKE, consigliamo vivamente l'uso del variabili e icone di copia e incolla cliccabili incorporate negli esempi di codice in questi istruzioni.

Workload Identity Federation for GKE negli ambienti di produzione

L'esempio descritto in questo documento lega l'account di servizio Google Cloud all'account di servizio Kubernetes predefinito e concede all'account di servizio Google Cloud tutte le autorizzazioni necessarie per utilizzare l'API Monitoring.

In un ambiente di produzione, ti consigliamo di utilizzare un approccio più granulare, con un account di servizio per ogni componente, ciascuno con autorizzazioni minime. Per ulteriori informazioni sulla configurazione degli account di servizio per gestione dei carichi di lavoro e delle identità, consulta Utilizzo della federazione delle identità per i carichi di lavoro per GKE.

Esegui il deployment del valutatore delle regole autonomo

Lo valutatore delle regole di Managed Service per Prometheus valuta le regole di registrazione e avviso di Prometheus in base all'API HTTP di Managed Service per Prometheus e restituisce i risultati a Monarch. Accetta lo stesso formato di file di configurazione e file di regole di Prometheus Anche i flag sono per lo più identici.

  1. Crea un esempio di implementazione dell'valutatore delle regole preconfigurato per valutare una regola di avviso e una di registrazione:

    kubectl apply -n NAMESPACE_NAME -f https://raw.githubusercontent.com/GoogleCloudPlatform/prometheus-engine/v0.13.0/manifests/rule-evaluator.yaml

  2. Verifica che il deployment dei pod per il valutatore delle regole sia andato a buon fine:

    kubectl -n NAMESPACE_NAME get pod

    Se il deployment è riuscito, vedrai un output simile al seguenti:

    NAME                              READY   STATUS    RESTARTS   AGE
...
rule-evaluator-64475b696c-95z29   2/2     Running   0          1m

Dopo aver verificato che lo strumento di valutazione delle regole è stato implementato correttamente, puoi apportare modifiche ai manifest installati per:

  • Aggiungi i file delle regole personalizzate.
  • Configura il valutatore delle regole in modo che invii avvisi a un deployment autonomo Alertmanager in Prometheus utilizzando alertmanager_config dell' di configurazione del deployment.

Se Alertmanager si trova in un cluster diverso rispetto al valutatore delle regole, potrebbe essere necessario configurare una risorsa Endpoints. Ad esempio, se il tuo OperatorConfig specifica 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.

Fornisci le credenziali in modo esplicito

Quando viene eseguito su GKE, lo strumento di valutazione delle regole recupera automaticamente le credenziali dall'ambiente in base all'account di servizio del nodo o alla configurazione di Workload Identity Federation for GKE. Nei cluster Kubernetes non GKE, le credenziali devono essere forniti al valutatore delle regole utilizzando i flag GOOGLE_APPLICATION_CREDENTIALS variabile di ambiente.

  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

    Questo passaggio crea l'account di servizio che potresti aver già creato nelle istruzioni di Workload Identity Federation per GKE.

  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 NAMESPACE_NAME create secret generic gmp-test-sa \
  --from-file=key.json=gmp-test-sa-key.json

  6. Apri la risorsa di deployment dello valutatore delle regole per la modifica:

    kubectl -n NAMESPACE_NAME edit deploy rule-evaluator

    1. Aggiungi il testo visualizzato in grassetto alla risorsa:

      apiVersion: apps/v1
kind: Deployment
metadata:
  namespace: NAMESPACE_NAME
  name: rule-evaluator
spec:
  template
    containers:
    - name: evaluator
      args:
      - --query.credentials-file=/gmp/key.json
      - --export.credentials-file=/gmp/key.json
...
      volumeMounts:
      - name: gmp-sa
        mountPath: /gmp
        readOnly: true
...
    volumes:
    - name: gmp-sa
      secret:
        secretName: gmp-test-sa
...

    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.

    In alternativa, invece di usare i flag impostati in questo esempio, puoi impostare il percorso del file chiave utilizzando il metodo GOOGLE_APPLICATION_CREDENTIALS variabile di ambiente.

    Valutazione di regole globali e multiprogetto

    Ti consigliamo di eseguire un'istanza del valutatore delle regole in per ogni progetto e ogni regione Google Cloud anziché eseguire un'istanza viene valutata in base a molti progetti e regioni. Tuttavia, supportiamo la valutazione di regole multiprogetto per scenari che lo richiedono.

    Quando viene eseguito il deployment su Google Kubernetes Engine, lo valutatore delle regole utilizza il progetto Google Cloud associato al cluster, che viene rilevato automaticamente. Per valutare le regole che interessano più progetti, puoi sostituire il progetto sottoposto a query utilizzando il flag --query.project-id e specificando un progetto con un ambito di metriche multi-progetto. Se l'ambito delle metriche contiene tutti i progetti, le regole vengono valutate a livello globale. Per saperne di più, consulta Ambiti delle metriche.

    Devi anche aggiornare le autorizzazioni dell'account di servizio utilizzato lo strumento di valutazione delle regole in modo che l'account di servizio possa leggere e scrivere su tutti i progetti monitorati nell'ambito delle metriche.

    Mantieni le etichette quando scrivi le regole

    Per i dati che il valutatore scrive a Managed Service per Prometheus, il valutatore supporta gli stessi flag --export.* e basati su external_labels configurazione come file binario del server Managed Service per Prometheus. Me Consigliamo vivamente di scrivere regole in modo che project_id, location, Le etichette cluster e namespace vengono conservate in modo appropriato per il relativo livello di aggregazione, altrimenti le prestazioni delle query potrebbero diminuire che incontri limiti di cardinalità.

    Le etichette project_id o location sono obbligatorie. Se queste etichette non sono presenti, i valori nei risultati della valutazione delle regole vengono impostati in base alla configurazione dell'analizzatore delle regole. Le etichette cluster o namespace mancanti non hanno valori.

    Autoosservabilità

    rule-evaluator emette le metriche Prometheus su una porta configurabile utilizzando il flag --web.listen-address.

    Ad esempio, se il pod rule-evaluator-64475b696c-95z29 espone queste metriche sulla porta 9092, le metriche possono essere visualizzate manualmente utilizzando kubectl:

    # Port forward the metrics endpoint.
kubectl port-forward rule-evaluator-64475b696c-95z29 9092
# Then query in a separate terminal.
curl localhost:9092/metrics

    Puoi configurare il tuo stack Prometheus per raccoglierli in modo da avere visibilità al rendimento del valutatore delle regole.

    Deployment ad alta disponibilità

    Il valutatore delle regole può essere eseguito in una configurazione ad alta disponibilità seguendo lo stesso approccio descritto per il server Prometheus.

    Avvisi mediante le metriche di Cloud Monitoring

    Puoi configurare il valutatore delle regole in modo che invii un avviso per le metriche di sistema di Google Cloud utilizzando PromQL. Per istruzioni su come creare una query valida, consulta PromQL per le metriche di Cloud Monitoring.