Questa pagina è stata tradotta dall'API Cloud Translation.

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

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

Segui queste istruzioni solo se vuoi eseguire regole e avvisi sul datastore globale.

Valutazione delle regole per la raccolta di cui è stato eseguito il deployment autonomo

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 massima di query per le regole è vincolata dal tempo di conservazione dei dati locali del server.

La maggior parte delle regole viene eseguita solo negli ultimi minuti di dati, pertanto eseguire regole su ciascun server locale è spesso una strategia valida. In questo caso, non sono necessarie ulteriori configurazioni.

Tuttavia, a volte è utile poter valutare le regole rispetto al backend della metrica globale, ad esempio quando tutti i dati di una regola non sono collocati congiuntamente su una determinata istanza Prometheus. In questi casi, Managed Service per Prometheus fornisce anche un componente 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 questa configurazione:

Configura gli strumenti a riga di comando come segue:
- Configura gcloud CLI per fare 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:
- Panoramica dell'interfaccia a riga di comando gcloud
- Comandi kubectl

Configura uno spazio dei nomi

Crea lo spazio dei nomi Kubernetes NAMESPACE_NAME per le risorse create come parte dell'applicazione di esempio:

kubectl create ns NAMESPACE_NAME

Verificare le credenziali dell'account di servizio

Puoi saltare questa sezione se nel cluster Kubernetes è abilitata Workload Identity.

Durante l'esecuzione 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 dispone delle autorizzazioni necessarie, monitoring.metricWriter e monitoring.viewer, per impostazione predefinita. Se non utilizzi Workload Identity e in precedenza hai rimosso uno di questi ruoli dall'account di servizio del nodo predefinito, dovrai aggiungere di nuovo le autorizzazioni mancanti prima di continuare.

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

Configura un account di servizio per Workload Identity

Puoi saltare questa sezione se nel cluster Kubernetes non è abilitata Workload Identity.

Managed Service per Prometheus acquisisce i dati delle metriche utilizzando l'API Cloud Monitoring. Se il cluster utilizza Workload Identity, devi concedere all'API Monitoring l'autorizzazione del tuo account di servizio Kubernetes. In questa sezione vengono descritte le seguenti informazioni:

Creazione di un account di servizio Google Cloud dedicato, gmp-test-sa.
Associazione dell'account di servizio Google Cloud all'account di servizio Kubernetes predefinito in uno spazio dei nomi di test, NAMESPACE_NAME.
Concedere l'autorizzazione necessaria all'account di servizio Google Cloud.

Crea e associa l'account di servizio

Questo passaggio viene visualizzato in diverse sezioni della documentazione di Managed Service per Prometheus. Se hai già eseguito questo passaggio come parte di un'attività precedente, non è necessario ripeterlo. Vai direttamente ad 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 nello 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 utilizzi uno spazio dei nomi GKE o un account di servizio diverso, modifica i comandi in modo appropriato.

Autorizza l'account di servizio

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

Il comando seguente concede all'account di servizio Google Cloud gmp-test-sa i ruoli dell'API Monitoring necessari per leggere e scrivere i dati delle metriche.

Se hai già concesso all'account di servizio Google Cloud un ruolo specifico nell'ambito di un'attività precedente, non sarà necessario 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

Debug della configurazione di Workload Identity

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

Poiché gli errori di battitura e il copia-incolla parziale sono le fonti più comuni di errori durante la configurazione di Workload Identity, ti consigliamo vivamente di utilizzare le variabili modificabili e le icone di copia e incolla cliccabili incorporate negli esempi di codice di queste istruzioni.

Workload Identity in ambienti di produzione

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

In un ambiente di produzione, conviene utilizzare un approccio più granulare, con un account di servizio per ogni componente e ciascuno con autorizzazioni minime. Per ulteriori informazioni sulla configurazione degli account di servizio per la gestione dei carichi di lavoro e delle identità, consulta Utilizzo di Workload Identity.

Esegui il deployment dello strumento di valutazione delle regole autonomo

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

Crea un deployment di esempio del valutatore delle regole preconfigurato per valutare un avviso e una regola di registrazione:

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

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 seguente:

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

Dopo aver verificato che il deployment del valutatore delle regole sia andato a buon fine, puoi modificare i manifest installati per:

Aggiungi i file delle regole personalizzate.
Configura il valutatore delle regole in modo che invii avvisi a un Alertmanager Prometheus di cui è stato eseguito il deployment autonomo utilizzando il campo alertmanager_config del file di configurazione.

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

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 o alla configurazione di Workload Identity. Nei cluster Kubernetes non GKE, le credenziali devono essere fornite esplicitamente al valutatore delle regole utilizzando flag o la variabile di ambiente GOOGLE_APPLICATION_CREDENTIALS.

Imposta il contesto sul progetto di destinazione:
```
gcloud config set project PROJECT_ID
```
Crea un account di servizio:
```
gcloud iam service-accounts create gmp-test-sa
```
Questo passaggio crea l'account di servizio che potresti avere già creato nelle istruzioni di Workload Identity.

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

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

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

Apri la risorsa Deployment per la valutazione delle regole da modificare:
```
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. Una volta applicata la modifica, i pod vengono ricreati e viene avviata l'autenticazione nel backend della metrica con l'account di servizio specificato.
In alternativa, invece di utilizzare i flag impostati in questo esempio, puoi impostare il percorso del file chiave utilizzando la variabile di ambiente GOOGLE_APPLICATION_CREDENTIALS.
Valutazione di regole globali e multiprogetto

Ti consigliamo di eseguire un'istanza del valutatore delle regole in ogni progetto e regione Google Cloud anziché eseguire un'istanza che esegue la valutazione sulla base di più progetti e regioni. Tuttavia, supportiamo la valutazione delle regole multiprogetto per scenari che la richiedono.

Quando viene eseguito 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, puoi eseguire l'override del progetto sottoposto a query utilizzando il flag --query.project-id e specificando un progetto con un ambito delle metriche multiprogetto. 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 dallo strumento di valutazione delle regole, 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.

Mantiene le etichette durante la scrittura delle regole

Per i dati che il valutatore scrive di nuovo a Managed Service per Prometheus, supporta gli stessi flag --export.* e la stessa configurazione basata su external_labels del file binario del server di Managed Service per Prometheus. Ti consigliamo vivamente di scrivere le regole in modo che le etichette project_id, location, cluster e namespace vengano conservate in modo appropriato per il loro livello di aggregazione, altrimenti le prestazioni delle query potrebbero diminuire e potresti incontrare limiti di cardinalità.

Le etichette project_id o location sono obbligatorie. Se mancano queste etichette, i valori nei risultati della valutazione delle regole vengono impostati in base alla configurazione del valutatore delle regole. Alle etichette cluster o namespace mancanti non sono stati forniti valori.

Deployment ad alta disponibilità

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

Avvisi mediante le metriche di Cloud Monitoring

Puoi configurare lo strumento di valutazione delle regole in modo che 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.