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 con deployment automatico, incluso il componente autonomo di valutazione delle regole.
Devi seguire queste istruzioni solo se vuoi eseguire regole e avvisi sul datastore 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 tempo in cui il server conserva i dati locali.
La maggior parte delle regole viene eseguita solo sugli ultimi minuti di dati, quindi l'esecuzione delle regole su ogni server locale è spesso una strategia valida. In questo caso, non è necessaria alcuna ulteriore configurazione.
Tuttavia, a volte è utile poter valutare le regole rispetto al backend delle metriche globale, ad esempio quando tutti i dati per una regola non si trovano nella stessa istanza Prometheus. In questi casi, Managed Service per Prometheus fornisce anche un componente di 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 gcloud CLI in modo che faccia riferimento all'ID del tuo progettoGoogle Cloud :
gcloud config set project PROJECT_ID
Se esegui l'operazione su GKE, utilizza gcloud CLI per impostare il cluster:
gcloud container clusters get-credentials CLUSTER_NAME --location LOCATION --project PROJECT_ID
In caso contrario, utilizza la CLI
kubectlper impostare il cluster:kubectl config set-cluster CLUSTER_NAME
Per ulteriori informazioni su questi strumenti, consulta quanto segue:
Configurare 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
Verificare le credenziali del account di servizio
Se nel tuo cluster Kubernetes è abilitata Workload Identity Federation for GKE, puoi saltare questa sezione.
Quando viene eseguito su GKE, Managed Service per Prometheus
recupera automaticamente le credenziali dall'ambiente in base alaccount di serviziont predefinito di Compute Engine. Per impostazione predefinita, il account di servizio predefinito dispone delle autorizzazioni necessarie, monitoring.metricWriter e monitoring.viewer. Se non utilizzi Workload Identity Federation for GKE e hai rimosso in precedenza uno di questi ruoli dall'account di servizio del nodo predefinito, dovrai aggiungere nuovamente le autorizzazioni mancanti prima di continuare.
Configura un account di servizio per Workload Identity Federation for GKE
Se il tuo cluster Kubernetes non ha abilitato Workload Identity Federation for GKE, puoi saltare questa sezione.
Managed Service per Prometheus acquisisce i dati delle metriche utilizzando l'API Cloud Monitoring. Se il tuo cluster utilizza Workload Identity Federation for GKE, devi concedere al tuo account di servizio Kubernetes l'autorizzazione per l'API Monitoring. Questa sezione descrive quanto segue:
- Creazione di un Google Cloud service account dedicato,
gmp-test-sa. - Associazione del service account Google Cloud al service account Kubernetes predefinito in uno spazio dei nomi di test,
NAMESPACE_NAME. - Concessione dell'autorizzazione necessaria al service account Google Cloud .
Crea e associa il account di servizio
Questo passaggio viene visualizzato in diversi punti della documentazione di Managed Service per Prometheus. Se hai già eseguito questo passaggio nell'ambito di un'attività precedente, non è necessario ripeterlo. Vai direttamente alla sezione Autorizzare l'account di servizio.
Innanzitutto, crea un account di servizio se non l'hai ancora fatto:
gcloud config set project PROJECT_ID \ && gcloud iam service-accounts create gmp-test-sa
Quindi utilizza la seguente sequenza di comandi per associare il service accountgmp-test-sa al account di servizio Kubernetes predefinito nello spazio dei nomi NAMESPACE_NAME:
gcloud config set project PROJECT_ID \ && gcloud iam service-accounts add-iam-policy-binding \ --role roles/iam.workloadIdentityUser \ --condition=None \ --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 account di servizio diverso, modifica i comandi di conseguenza.
Autorizzare il account di servizio
I gruppi di autorizzazioni correlate vengono raccolti in ruoli e concedi i ruoli a un'entità, in questo esempio, il account di servizio account Google Cloud. Per saperne di più sui ruoli di monitoraggio, consulta Controllo dell'accesso.
Il seguente comando concede al service account Google Cloud ,
gmp-test-sa, i ruoli API Monitoring necessari per
leggere e scrivere
i dati delle metriche.
Se hai già concesso un ruolo specifico al service account Google Cloud nell'ambito di un'attività precedente, non devi farlo di nuovo.
gcloud projects add-iam-policy-binding PROJECT_ID \ --member=serviceAccount:gmp-test-sa@PROJECT_ID.iam.gserviceaccount.com \ --role=roles/monitoring.viewer \ --condition=None \ && \ gcloud projects add-iam-policy-binding PROJECT_ID\ --member=serviceAccount:gmp-test-sa@PROJECT_ID.iam.gserviceaccount.com \ --role=roles/monitoring.metricWriter \ --condition=None \ && \ gcloud projects add-iam-policy-binding PROJECT_ID \ --member=serviceAccount:gmp-test-sa@PROJECT_ID.iam.gserviceaccount.com \ --role=roles/iam.serviceAccountTokenCreator \ --condition=None
Esegui il debug della configurazione di Workload Identity Federation for GKE
Se hai difficoltà a far funzionare Workload Identity Federation for GKE, consulta la documentazione per verificare la configurazione di Workload Identity Federation for GKE e la guida alla risoluzione dei problemi di Workload Identity Federation for GKE.
Poiché gli errori di battitura e i copia-incolla parziali sono le fonti più comuni di errori durante la configurazione di Workload Identity Federation for GKE, ti consigliamo vivamente di utilizzare le variabili modificabili e le icone di copia-incolla cliccabili incorporate negli esempi di codice in queste istruzioni.
Workload Identity Federation for GKE negli ambienti di produzione
L'esempio descritto in questo documento associa il service account Google Cloud al account di servizio Kubernetes predefinito e concede al account di servizio Google Cloudtutte le autorizzazioni necessarie per utilizzare l'API Monitoring.
In un ambiente di produzione, potresti voler utilizzare un approccio più granulare, con unaccount di serviziot per ogni componente, ciascuno con autorizzazioni minime. Per saperne di più sulla configurazione dei service account per la gestione delle identità dei workload, consulta Utilizzare la federazione delle identità dei workload per GKE.
Esegui il deployment del valutatore di regole autonomo
Lo strumento di valutazione delle regole di Managed Service per Prometheus valuta le regole di registrazione e avviso di Prometheus rispetto all'API HTTP di Managed Service per Prometheus e riscrive i risultati in Monarch. Accetta lo stesso formato del file di configurazione e del file di regole di Prometheus. Anche i flag sono per lo più identici.
Crea un esempio di deployment del valutatore di regole preconfigurato per valutare una regola di avviso e una regola di registrazione:
kubectl apply -n NAMESPACE_NAME -f https://raw.githubusercontent.com/GoogleCloudPlatform/prometheus-engine/v0.15.3/manifests/rule-evaluator.yaml
Verifica che il deployment dei pod per rule-evaluator sia andato a buon fine:
kubectl -n NAMESPACE_NAME get pod
Se il deployment è andato a buon fine, viene visualizzato un output simile al seguente:
NAME READY STATUS RESTARTS AGE ... rule-evaluator-64475b696c-95z29 2/2 Running 0 1m
Dopo aver verificato che rule-evaluator sia stato implementato correttamente, puoi apportare modifiche ai manifest installati per:
- Aggiungi i file delle regole personalizzate.
- Configura il valutatore di regole per inviare avvisi a un Alertmanager Prometheus autodeployato utilizzando il campo
alertmanager_configdel file di configurazione.
Se Alertmanager si trova in un cluster diverso
dal valutatore di regole, potrebbe essere necessario configurare una risorsa Endpoints.
Ad esempio, se OperatorConfig specifica che gli endpoint Alertmanager possono essere trovati 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.
Fornisci le credenziali in modo esplicito
Quando viene eseguito su GKE, rule-evaluator
recupera automaticamente le credenziali dall'ambiente in base
al account di servizio del nodo o alla configurazione di Workload Identity Federation for GKE.
Nei cluster Kubernetes non GKE, le credenziali devono essere fornite
in modo esplicito al valutatore delle regole utilizzando i flag o la
variabile di ambiente GOOGLE_APPLICATION_CREDENTIALS.
Imposta il contesto sul progetto di destinazione:
gcloud config set project PROJECT_ID
Crea un service account:
gcloud iam service-accounts create gmp-test-sa
Questo passaggio crea il account di servizio che potresti aver già creato nelle istruzioni per la federazione delle identità per i carichi di lavoro per GKE.
Concedi le autorizzazioni richieste 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
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
Aggiungi il file della chiave come secret al tuo 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 di deployment rule-evaluator per la modifica:
kubectl -n NAMESPACE_NAME edit deploy rule-evaluator
Aggiungi il testo mostrato 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 ...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 iaccount di serviziont specificato.
GOOGLE_APPLICATION_CREDENTIALS.Valutazione delle regole globali e per più progetti
Ti consigliamo di eseguire un'istanza del valutatore di regole in ogni Google Cloud progetto e regione anziché un'istanza che valuta rispetto a molti progetti e regioni. Tuttavia, supportiamo la valutazione delle regole per più progetti per gli scenari che lo richiedono.
Quando viene eseguito il deployment su Google Kubernetes Engine, il valutatore di regole utilizza il progettoGoogle Cloud associato al cluster, che rileva automaticamente. Per valutare le regole che si estendono a più progetti, puoi sostituire il progetto di cui è stata eseguita la query utilizzando il flag
--query.project-ide specificando un progetto con un ambito delle metriche multi-progetto. Se l'ambito delle metriche contiene tutti i tuoi progetti, le regole vengono valutate a livello globale. Per ulteriori informazioni, consulta Ambiti delle metriche.Devi anche aggiornare le autorizzazioni del account di servizio utilizzato dal valutatore delle regole in modo che possa leggere dal progetto di definizione dell'ambito e scrivere in tutti i progetti monitorati nell'ambito delle metriche.
Mantieni le etichette quando scrivi le regole
Per i dati che l'evaluator riscrive in Managed Service per Prometheus, l'evaluator supporta gli stessi flag
--export.*e la configurazione basata suexternal_labelsdel binario del server Managed Service per Prometheus. Ti consigliamo vivamente di scrivere regole in modo che le etichetteproject_id,location,clusterenamespacevengano conservate in modo appropriato per il loro livello di aggregazione, altrimenti il rendimento delle query potrebbe diminuire e potresti riscontrare limiti di cardinalità.Le etichette
project_idolocationsono obbligatorie. Se queste etichette non sono presenti, i valori nei risultati della valutazione delle regole vengono impostati in base alla configurazione del valutatore delle regole. Le etichetteclusteronamespacenon hanno valori.Osservabilità automatica
Rule-evaluator emette metriche Prometheus su una porta configurabile utilizzando il flag
--web.listen-address.Ad esempio, se il pod
rule-evaluator-64475b696c-95z29espone queste metriche sulla porta9092, le metriche possono essere visualizzate manualmente utilizzandokubectl:# Port forward the metrics endpoint. kubectl port-forward rule-evaluator-64475b696c-95z29 9092 # Then query in a separate terminal. curl localhost:9092/metricsPuoi configurare lo stack Prometheus per raccoglierli in modo da avere visibilità sul rendimento di rule-evaluator.
Deployment ad alta disponibilità
L'evaluator delle regole può essere eseguito in una configurazione a disponibilità elevata seguendo lo stesso approccio documentato per il server Prometheus.
Avvisi tramite le metriche di Cloud Monitoring
Puoi configurare il valutatore di regole in modo che generi avvisi in base alle metriche di sistemaGoogle Cloud utilizzando PromQL. Per istruzioni su come creare una query valida, consulta PromQL per le metriche di Cloud Monitoring.