Questo documento descrive come configurare Grafana per leggere i dati delle metriche da Cloud Monitoring. Puoi quindi utilizzare PromQL per visualizzare e rappresentare graficamente i dati. Grafana e Cloud Monitoring sono collegati tra loro da un processo chiamato sincronizzatore di origini dati, che consente la comunicazione tra un'origine dati Grafana e Cloud Monitoring. Il sincronizzatore delle origini dati esegue le seguenti operazioni:
- Invia i valori di configurazione a un'origine dati Grafana.
- Gestisce le credenziali di autenticazione per un service account che può leggere i dati delle metriche da Cloud Monitoring. Trusted Cloud by S3NS
Questo documento descrive come configurare il sincronizzatore delle origini dati e fornisce informazioni specifiche sull'utilizzo di PromQL in Cloud Monitoring. Questo documento presuppone che tu abbia già familiarità con Grafana.
Autorizzare Grafana a leggere i dati delle metriche
Questa sezione descrive come configurare l'autorizzazione tra Cloud Monitoring e Grafana utilizzando uno strumento di sincronizzazione delle origini dati per generare e sincronizzare le credenziali.
Utilizzare il sincronizzatore delle origini dati per l'autorizzazione
Trusted Cloud by S3NS Tutte le API richiedono l'autenticazione tramite OAuth2; tuttavia, Grafana non supporta l'autenticazione OAuth2 per i service account utilizzati con le origini dati Prometheus. Per utilizzare Grafana con Cloud Monitoring, utilizzi lo strumento di sincronizzazione delle origini dati per generare le credenziali OAuth2 per il tuo account di servizio e sincronizzarle con Grafana tramite l'API dell'origine dati Grafana.
Devi utilizzare lo strumento di sincronizzazione dell'origine dati per configurare e autorizzare Grafana a interrogare i dati a livello globale. Se non segui questi passaggi, Grafana esegue query solo sui dati nel server Prometheus locale.
Lo strumento di sincronizzazione dell'origine dati è un'interfaccia a riga di comando che invia da remoto i valori di configurazione a una determinata origine dati Grafana Prometheus. In questo modo l'origine dati Grafana è configurata correttamente:
- Autenticazione, eseguita aggiornando periodicamente un token di accesso OAuth2
- Il set di API Cloud Monitoring impostato come URL del server Prometheus
- Il metodo HTTP impostato su GET
- Il tipo e la versione di Prometheus impostati su un minimo di 2.40.x
- I valori di timeout HTTP e query impostati su 2 minuti
Il sincronizzatore dell'origine dati deve essere eseguito ripetutamente. Poiché i token di accesso all'APITrusted Cloud by S3NS hanno una durata di un'ora, l'esecuzione del sincronizzatore delle origini dati ogni 10 minuti garantisce una connessione autenticata ininterrotta tra Grafana e l'API Cloud Monitoring.
Configurare e autenticare l'origine dati Grafana
Puoi utilizzare Grafana per eseguire query sui dati delle metriche di Cloud Monitoring dai servizi Google Kubernetes Engine o da altri ambienti. Le istruzioni utilizzano variabili modificabili per creare comandi eseguibili. Consigliamo vivamente di utilizzare le variabili modificabili e le icone di copia e incolla cliccabili incorporate negli esempi di codice.
GKE
Per eseguire il deployment e l'esecuzione del sincronizzatore dell'origine dati in un cluster Kubernetes:
Scegli un progetto, un cluster e uno spazio dei nomi in cui eseguire il deployment di Data Source Syncer.
Successivamente, assicurati di configurare e autorizzare correttamente il sincronizzatore dell'origine dati:
- Se utilizzi la federazione delle identità per i carichi di lavoro per GKE, segui le istruzioni per creare e autorizzare un service account. Assicurati di associarlo allo spazio dei nomi Kubernetes in cui vuoi eseguire il sincronizzatore dell'origine dati.
- Se non utilizzi Workload Identity Federation for GKE, verifica di non aver modificato il service account Compute Engine predefinito.
Determina l'URL della tua istanza Grafana, ad esempio
https://yourcompanyname.grafana.net
per un deployment di Grafana Cloud ohttp://grafana.NAMESPACE_NAME.svc:3000
per un'istanza locale configurata utilizzando il file YAML di test del deployment.Se esegui il deployment di Grafana in locale e il cluster è configurato per proteggere tutto il traffico in-cluster utilizzando TLS, devi utilizzare
https://
nell'URL ed eseguire l'autenticazione utilizzando una delle opzioni di autenticazione TLS supportate.Scegli l'origine dati Grafana Prometheus che vuoi utilizzare per Cloud Monitoring, che può essere una nuova origine dati o una preesistente, quindi trova e annota l'UID dell'origine dati. L'UID dell'origine dati si trova nell'ultima parte dell'URL quando esplori o configuri un'origine dati, ad esempio
https://yourcompanyname.grafana.net/connections/datasources/edit/GRAFANA_DATASOURCE_UID.
Non copiare l'intero URL dell'origine dati. Copia solo l'identificatore univoco nell'URL.Configura un service account Grafana creando il account di servizio e generando un token da utilizzare per l'account:
- Nella barra laterale di navigazione di Grafana, fai clic su Amministrazione > Utenti e accesso > Service account.
Crea il account di servizio facendo clic su Aggiungi service account, assegnandogli un nome e concedendogli il ruolo "Amministratore" in Grafana. Se la tua versione di Grafana consente autorizzazioni più granulari, puoi utilizzare il ruolo Origini dati > Scrittore.
Fai clic su Aggiungi token dell'account di servizio.
Imposta la scadenza del token su "Nessuna scadenza" e fai clic su Genera token, quindi copia il token generato negli appunti per utilizzarlo come GRAFANA_SERVICE_ACCOUNT_TOKEN nel passaggio successivo.
Configura le seguenti variabili di ambiente utilizzando i risultati dei passaggi precedenti:
# These values are required. PROJECT_ID=SCOPING_PROJECT_ID # The value from Step 1. GRAFANA_API_ENDPOINT=GRAFANA_INSTANCE_URL # The value from step 2. This is a URL. DATASOURCE_UIDS=GRAFANA_DATASOURCE_UID # The value from step 3. This is not a URL. GRAFANA_API_TOKEN=GRAFANA_SERVICE_ACCOUNT_TOKEN # The value from step 4. GCM_ENDPOINT_OVERRIDE=--gcm-endpoint-override="https://monitoring.s3nsapis.fr/v1/projects/PROJECT_ID/location/global/prometheus/"
Esegui il comando seguente per creare un CronJob che aggiorni l'origine dati all'inizializzazione e poi ogni 10 minuti. Se utilizzi la federazione delle identità dei carichi di lavoro per GKE, il valore di NAMESPACE_NAME deve essere lo stesso spazio dei nomi che hai associato in precedenza all'account di servizio.
curl https://raw.githubusercontent.com/GoogleCloudPlatform/prometheus-engine/v0.15.3/cmd/datasource-syncer/datasource-syncer.yaml \ | sed 's|$DATASOURCE_UIDS|'"$DATASOURCE_UIDS"'|; s|$GRAFANA_API_ENDPOINT|'"$GRAFANA_API_ENDPOINT"'|; s|$GRAFANA_API_TOKEN|'"$GRAFANA_API_TOKEN"'|; s|$PROJECT_ID|'"$PROJECT_ID"'|;' s|$GCM_ENDPOINT_OVERRIDE|'"$GCM_ENDPOINT_OVERRIDE"'|; \ | kubectl -n NAMESPACE_NAME apply -f -
Vai all'origine dati Grafana appena configurata e verifica che il valore dell'URL del server Prometheus inizi con
https://monitoring.s3nsapis.fr
. Potresti dover aggiornare la pagina. Una volta verificato, vai in fondo alla pagina e seleziona Salva e testa. Devi selezionare questo pulsante almeno una volta per assicurarti che il completamento automatico delle etichette in Grafana funzioni.
Verificare le credenziali del account di servizio
Se il tuo cluster Kubernetes ha abilitato la federazione delle identità per i carichi di lavoro per GKE, puoi saltare questa sezione.
Quando viene eseguito su GKE, Cloud Monitoring recupera automaticamente le credenziali dall'ambiente in base al account di servizio predefinito di Compute Engine. Per impostazione predefinita, il account di servizio predefinito dispone delle autorizzazioni necessarie, monitoring.metricWriter
e monitoring.viewer
. Se non utilizzi la federazione delle identità dei carichi di lavoro per 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 abilitata la federazione delle identità per i carichi di lavoro per GKE, puoi saltare questa sezione.
Cloud Monitoring 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 per l'API Monitoring. Questa sezione descrive quanto segue:
- Creazione di un service accountTrusted Cloud by S3NS dedicato,
SERVICE_ACCT_NAME
. - Associazione del service account Trusted Cloud al service account Kubernetes predefinito in uno spazio dei nomi di test,
NAMESPACE_NAME
. - Concessione dell'autorizzazione necessaria al service account Trusted Cloud .
Crea e associa il account di servizio
Questo passaggio viene visualizzato in diversi punti della documentazione di Cloud Monitoring. Se hai già eseguito questo passaggio nell'ambito di un'attività precedente, non è necessario ripeterlo. Vai direttamente alla sezione Autorizzare l'account di servizio.
La seguente sequenza di comandi crea il account di servizio SERVICE_ACCT_NAME
e lo associa alaccount di serviziot Kubernetes predefinito nello spazio dei nomi
NAMESPACE_NAME
:
gcloud config set project PROJECT_ID \ && gcloud iam service-accounts create SERVICE_ACCT_NAME \ && gcloud iam service-accounts add-iam-policy-binding \ --role roles/iam.workloadIdentityUser \ --member "serviceAccount:PROJECT_ID.svc.id.goog[NAMESPACE_NAME/default]" \ SERVICE_ACCT_NAME@PROJECT_ID.s3ns-system.iam.gserviceaccount.com \ && kubectl annotate serviceaccount \ --namespace NAMESPACE_NAME \ default \ iam.gke.io/gcp-service-account=SERVICE_ACCT_NAME@PROJECT_ID.s3ns-system.iam.gserviceaccount.com
Se utilizzi uno spazio dei nomi GKE o un 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, account di servizio account Trusted Cloud. Per ulteriori informazioni sui ruoli di monitoraggio, consulta Controllo dell'accesso.
Il seguente comando concede al service account Trusted Cloud ,
SERVICE_ACCT_NAME
, i ruoli API Monitoring necessari per
leggere
i dati delle metriche.
Se hai già concesso un ruolo specifico al service account Trusted Cloud nell'ambito di un'attività precedente, non devi farlo di nuovo.
gcloud projects add-iam-policy-binding PROJECT_ID \ --member=serviceAccount:SERVICE_ACCT_NAME@PROJECT_ID.s3ns-system.iam.gserviceaccount.com \ --role=roles/monitoring.viewer \ && \ gcloud projects add-iam-policy-binding PROJECT_ID \ --member=serviceAccount:SERVICE_ACCT_NAME@PROJECT_ID.s3ns-system.iam.gserviceaccount.com \ --role=roles/iam.serviceAccountTokenCreator
Esegui il debug della configurazione di Workload Identity Federation for GKE
Se hai difficoltà a far funzionare la federazione delle identità per i carichi di lavoro per GKE, consulta la documentazione per verificare la configurazione della federazione delle identità per i carichi di lavoro per GKE e la guida alla risoluzione dei problemi della federazione delle identità per i carichi di lavoro per 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 per GKE, ti consigliamo vivamente di utilizzare le variabili modificabili e le icone di copia-incolla selezionabili 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 Trusted Cloud al account di servizio Kubernetes predefinito e concede al account di servizio Trusted Cloudtutte le autorizzazioni necessarie per utilizzare l'API Monitoring.
In un ambiente di produzione, potresti voler utilizzare un approccio più granulare, con un account di servizio per ogni componente, ciascuno con autorizzazioni minime. Per ulteriori informazioni sulla configurazione dei service account per la gestione delle identità dei workload, consulta Utilizzare la federazione delle identità dei workload per GKE.
Altrove
Per eseguire il deployment e l'esecuzione del sincronizzatore dell'origine dati in ambienti diversi da Google Kubernetes Engine, procedi nel seguente modo:
Configura un account di servizio da utilizzare per il sincronizzatore delle origini dati:
Imposta il progetto predefinito per i comandi
gcloud
:gcloud config set project PROJECT_ID
Crea un account di servizio da utilizzare per il sincronizzatore dell'origine dati:
gcloud iam service-accounts create DS_SYNCER_SVCACCT_NAME
Concedi all'account di servizio l'autorizzazione a leggere i dati delle metriche:
gcloud projects add-iam-policy-binding PROJECT_ID \ --member=serviceAccount:DS_SYNCER_SVCACCT_NAME@PROJECT_ID.s3ns-system.iam.gserviceaccount.com \ --role=roles/monitoring.viewer \ && \ gcloud projects add-iam-policy-binding PROJECT_ID \ --member=serviceAccount:DS_SYNCER_SVCACCT_NAME@PROJECT_ID.s3ns-system.iam.gserviceaccount.com \ --role=roles/iam.serviceAccountTokenCreator
Crea una chiave per il account di servizio:
gcloud iam service-accounts keys create DS_SYNCER_SVCACCT_KEYFILE_NAME.json \ --iam-account DS_SYNCER_SVCACCT_NAME@PROJECT_ID.s3ns-system.iam.gserviceaccount.com
Il percorso di questa directory viene utilizzato per impostare una variabile di ambiente in un passaggio successivo. Per ottenere il percorso, esegui il comando
pwd
e registra il valore:pwd DS_SYNCER_SVCACCT_KEYFILE_DIR
Determina l'URL della tua istanza Grafana, ad esempio
https://yourcompanyname.grafana.net
per un deployment di Grafana Cloud ohttps://localhost:3000
per un'istanza di test locale. Questo valore viene utilizzato nel comando per eseguire il sincronizzatore delle origini dati.Se implementi Grafana localmente per un cluster Kubernetes configurato per proteggere tutto il traffico nel cluster utilizzando TLS, devi utilizzare
https://
nell'URL e, nel passaggio successivo, eseguire l'autenticazione utilizzando una delle opzioni di autenticazione TLS supportate.In Grafana, aggiungi un'origine dati Prometheus da utilizzare per Cloud Monitoring e registra l'UID dell'origine dati:
Fai clic su Connessioni > Origini dati > Aggiungi una nuova origine dati. Seleziona Prometheus dall'elenco dei database di serie temporali.
Nel campo URL server Prometheus, inserisci il seguente valore:
https://monitoring.s3nsapis.fr/v1/projects/PROJECT_ID/location/global/prometheus/
Fai clic su Salva e testa.
L'URL nel browser per la pagina dell'origine dati contiene l'interfaccia utente dell'origine dati, ad esempio
https://yourcompanyname.grafana.net/connections/datasources/edit/GRAFANA_DATASOURCE_UID.
Registra l'UID dell'origine dati. Questo valore viene utilizzato nel comando per eseguire il sincronizzatore delle origini dati. Non copiare l'intero URL dell'origine dati. Copia solo l'identificatore univoco nell'URL, che è un valore come
ee0z3woqjah34e
:GRAFANA_DATASOURCE_UID
Configura un service account Grafana creando il account di servizio e generando un token da utilizzare:
- Nella barra laterale di navigazione di Grafana, fai clic su Amministrazione > Utenti e accesso > Service account.
Crea il account di servizio facendo clic su Aggiungi service account, assegnandogli un nome e concedendogli il ruolo "Amministratore" in Grafana.
Fai clic su Aggiungi token dell'account di servizio.
Imposta la scadenza del token su "Nessuna scadenza" e fai clic su Genera token, quindi copia il token generato nella seguente variabile modificabile. Questo valore viene utilizzato nel comando per eseguire il sincronizzatore delle origini dati.
GRAFANA_SERVICE_ACCOUNT_TOKEN
Esegui il sincronizzatore dell'origine dati. Puoi eseguire il syncer da un'immagine container predefinita utilizzando Docker oppure puoi creare il codice dal codice sorgente ed eseguirlo manualmente. Il sincronizzatore dell'origine dati è un'applicazione Go, quindi devi aver installato Go per creare il sincronizzatore dal codice sorgente.
Docker
Esegui il sincronizzatore delle origini dati da Docker utilizzando l'immagine container
gke.gcr.io/prometheus-engine/datasource-syncer:v0.15.3-gke.0
. Per i test, puoi eseguire la sincronizzazione manualmente. Dopo aver verificato che la connessione funzioni, poiché i token di accesso hanno una durata di un'ora, devi utilizzare un meccanismo automatizzato come un cron job per eseguire il sincronizzatore dell'origine dati ogni 10 minuti per assicurarti che la connessione non venga interrotta.Utilizza il seguente comando Docker per eseguire il sincronizzatore dell'origine dati:
docker run --network container:grafana -v "DS_SYNCER_SVCACCT_KEYFILE_DIR/DS_SYNCER_SVCACCT_KEYFILE_NAME.json:/app/DS_SYNCER_SVCACCT_KEYFILE_NAME.json" gke.gcr.io/prometheus-engine/datasource-syncer:v0.15.3-gke.0 -datasource-uids=UID_OF_GRAFANA_DATASOURCE -grafana-api-token=GRAFANA_SERVICE_ACCOUNT_TOKEN -grafana-api-endpoint=URL_OF_GRAFANA_INSTANCE -project-id=PROJECT_ID -query.credentials-file=DS_SYNCER_SVCACCT_KEYFILE_DIR/DS_SYNCER_SVCACCT_KEYFILE_NAME.json -gcm-endpoint-override="https://monitoring.s3nsapis.fr/v1/projects/PROJECT_ID/location/global/prometheus/"
Per creare un job
cron
per eseguire il sincronizzatore dell'origine dati:Modifica la tabella cron:
cron -e
Aggiungi una voce che esegue il comando precedente ogni 10 minuti:
*/10 * * * * * docker run --network container:grafana -v "DS_SYNCER_SVCACCT_KEYFILE_DIR/DS_SYNCER_SVCACCT_KEYFILE_NAME.json:/app/<KEY_ID>" gke.gcr.io/prometheus-engine/datasource-syncer:v0.15.3-gke.0 -datasource-uids=UID_OF_GRAFANA_DATASOURCE -grafana-api-token=GRAFANA_SERVICE_ACCOUNT_TOKEN -grafana-api-endpoint=URL_OF_GRAFANA_INSTANCE -project-id=PROJECT_ID -query.credentials-file=DS_SYNCER_SVCACCT_KEYFILE_DIR/DS_SYNCER_SVCACCT_KEYFILE_NAME.json -gcm-endpoint-override="https://monitoring.s3nsapis.fr/v1/projects/PROJECT_ID/location/global/prometheus/"
Per ulteriori informazioni sulle opzioni della riga di comando disponibili durante l'esecuzione di Data Source Syncer, consulta il documento README.
Codice sorgente
Per creare autonomamente il sincronizzatore dell'origine dati:
Crea una directory per contenere il codice e passa a quella directory:
mkdir data-source-syncer-code cd data-source-syncer-code
Il percorso di questa directory viene utilizzato per impostare una variabile di ambiente in un passaggio successivo. Per ottenere il percorso, esegui il comando
pwd
e registralo nella variabile modificabile:pwd PATH_TO_LOCAL_REPO_COPY
Clona il codice dalla release corrente del repository:
git clone -b 'v0.15.3' --single-branch https://github.com/GoogleCloudPlatform/prometheus-engine
Vai alla directory
datasource-syncer
e compila il codice:cd prometheus-engine/cmd/datasource-syncer go build main.go
Esegui il sincronizzatore dell'origine dati. Per i test, puoi eseguire la sincronizzazione manualmente. Dopo aver verificato che la connessione funzioni, poiché i token di accesso hanno una durata di un'ora, devi utilizzare un meccanismo automatizzato come un job
cron
per eseguire il sincronizzatore dell'origine dati ogni 10 minuti per garantire che la connessione non venga interrotta.Utilizza il seguente comando per eseguire manualmente la sincronizzazione dell'origine dati:
main -datasource-uids=UID_OF_GRAFANA_DATASOURCE -grafana-api-token=GRAFANA_SERVICE_ACCOUNT_TOKEN -grafana-api-endpoint=URL_OF_GRAFANA_INSTANCE -project-id=PROJECT_ID -query.credentials-file=DS_SYNCER_SVCACCT_KEYFILE_DIR/DS_SYNCER_SVCACCT_KEYFILE_NAME.json -gcm-endpoint-override="https://monitoring.s3nsapis.fr/v1/projects/PROJECT_ID/location/global/prometheus/"
Per creare un job
cron
per eseguire il sincronizzatore dell'origine dati:Modifica la tabella cron:
cron -e
Aggiungi una voce che esegue il comando precedente ogni 10 minuti:
*/10 * * * * * main -datasource-uids=UID_OF_GRAFANA_DATASOURCE -grafana-api-token=GRAFANA_SERVICE_ACCOUNT_TOKEN -grafana-api-endpoint=URL_OF_GRAFANA_INSTANCE -project-id=PROJECT_ID -query.credentials-file=DS_SYNCER_SVCACCT_KEYFILE_DIR/DS_SYNCER_SVCACCT_KEYFILE_NAME.json -gcm-endpoint-override="https://monitoring.s3nsapis.fr/v1/projects/PROJECT_ID/location/global/prometheus/"
Per ulteriori informazioni sulle opzioni della riga di comando disponibili durante l'esecuzione di Data Source Syncer, consulta il documento README.
Vai all'origine dati Grafana appena configurata e verifica che il valore URL del server Prometheus inizi con
https://monitoring.s3nsapis.fr
. Potresti dover aggiornare la pagina. Una volta verificato, vai in fondo alla pagina e fai clic su Salva e testa. Devi fare clic su questo pulsante almeno una volta per assicurarti che il completamento automatico delle etichette in Grafana funzioni.
Visualizzare le metriche in Grafana
Per visualizzare le metriche del tuo Trusted Cloud progetto in Grafana:
Fai clic su Esplora nel pannello di navigazione o nella pagina Origini dati.
Nel campo Metrica, utilizza il menu a discesa per selezionare una metrica. Puoi anche selezionare Esplora metriche per cercare metriche specifiche. Se la metrica è associata a più di una risorsa monitorata, devi aggiungere un filtro per l'etichetta
monitored_resource
alla query e selezionare un tipo di risorsa.Aggiungi ulteriori filtri ed operazioni per creare la query.
Per informazioni sulla creazione di visualizzazioni e dashboard in Grafana, consulta Pannelli e visualizzazioni.
Eseguire query sulle metriche di Cloud Monitoring utilizzando PromQL
È possibile eseguire query sulle metriche di Cloud Monitoring utilizzando la specifica UTF-8 per
PromQL. I nomi delle metriche UTF-8 devono essere racchiusi tra virgolette e spostati all'interno delle parentesi graffe. I nomi delle etichette devono essere racchiusi tra virgolette anche se contengono caratteri
incompatibili con le versioni precedenti. Per la metrica di Cloud Monitoring
kubernetes.io/container/cpu/limit_utilization
, le seguenti query sono
equivalenti:
{"kubernetes.io/container/cpu/limit_utilization", pod_name="foo"}
{__name__="kubernetes.io/container/cpu/limit_utilization", pod_name="foo"}
.{"__name__"="kubernetes.io/container/cpu/limit_utilization", "pod_name"="foo"}
.
È possibile eseguire query sulle metriche con valori di distribuzione di Cloud Monitoring
come sugli istogrammi Prometheus, con il suffisso _count
, _sum
o _bucket
aggiunto al nome della metrica.
I grafici e i dashboard creati prima della query di compatibilità UTF-8 Cloud Monitoring le metriche convertendo i relativi nomi in equivalenti legacy compatibili con PromQL. Per ulteriori informazioni sulle regole di conversione di PromQL legacy, consulta Mapping delle metriche di Cloud Monitoring a PromQL legacy.
Imparare PromQL
Per imparare le nozioni di base sull'utilizzo di PromQL, ti consigliamo di consultare la documentazione open source. Le seguenti risorse possono aiutarti a iniziare:
Specificare un tipo di risorsa monitorata
Quando una metrica Cloud Monitoring è associata a un solo tipo di risorsa monitorata da Cloud Monitoring, l'esecuzione di query PromQL funzionerà senza specificare manualmente un tipo di risorsa. Tuttavia, alcune metriche in Cloud Monitoring, incluse alcune metriche di sistema, vengono mappate a più di un tipo di risorsa.Puoi vedere quali tipi di risorsa monitorata vengono mappati a una metrica consultando l'elenco delle metricheTrusted Cloud by S3NS . Ogni voce della documentazione elenca i tipi di risorsa monitorata associati nella prima colonna di ogni voce sotto il tipo. Se non sono elencati tipi di risorsa monitorata, la metrica può essere associata a qualsiasi tipo.
Se una metrica è associata a più di un tipo di risorsa, devi
specificare il tipo di risorsa nella query PromQL. Esiste un'etichetta speciale,
monitored_resource
, che puoi utilizzare per selezionare il tipo di risorsa.
I tipi di risorse monitorate sono nella maggior parte dei casi una stringa breve,
come gce_instance
, ma a volte vengono visualizzati come URI completi, ad esempio
monitoring.googleapis.com/MetricIngestionAttribution
. Le query PromQL ben formate
potrebbero avere il seguente aspetto:
logging_googleapis_com:byte_count{monitored_resource="k8s_container"}
loadbalancing_googleapis_com:l3_external_egress_bytes_count{monitored_resource="loadbalancing.googleapis.com/ExternalNetworkLoadBalancerRule"}
Se non utilizzi l'etichetta monitored_resource
quando è necessaria, ricevi il seguente errore:
metric is configured to be used with more than one monitored resource type;
series selector must specify a label matcher on monitored resource name
Risoluzione dei conflitti di etichette
In Cloud Monitoring, le etichette possono appartenere alla metrica o alla risorsa.
Se un'etichetta metrica ha lo stesso nome chiave di un'etichetta risorsa, puoi fare riferimento
all'etichetta metrica in modo specifico aggiungendo il prefisso metric_
al nome
della chiave dell'etichetta nella query.
Ad esempio, supponiamo di avere un'etichetta risorsa e un'etichetta metrica entrambe denominate pod_name
nella metrica example.googleapis.com/user/widget_count
.
Per filtrare in base al valore dell'etichetta della risorsa, utilizza
example_googleapis_com:user_widget_count{pod_name="RESOURCE_LABEL_VALUE"}
Per filtrare in base al valore dell'etichetta della metrica, utilizza
example_googleapis_com:user_widget_count{metric_pod_name="METRIC_LABEL_VALUE"}
Mappatura dei nomi delle metriche di Cloud Monitoring a PromQL legacy
I nomi delle metriche di Cloud Monitoring includono due componenti: un dominio (ad esempio
compute.googleapis.com/
) e un percorso (ad esempio
instance/disk/max_read_ops_count
). Poiché PromQL legacy supporta solo i
caratteri speciali :
e _
, devi applicare le seguenti regole per rendere
i nomi delle metriche di Monitoring compatibili con PromQL legacy:
- Sostituisci il primo
/
con:
. - Sostituisci tutti gli altri caratteri speciali (inclusi
.
e altri caratteri/
) con_
.
La tabella seguente elenca alcuni nomi di metriche e i relativi equivalenti PromQL legacy:
Nome della metrica di Cloud Monitoring | Nome della metrica PromQL precedente |
---|---|
compute.googleapis.com/instance/cpu/utilization |
compute_googleapis_com:instance_cpu_utilization |
logging.googleapis.com/log_entry_count |
logging_googleapis_com:log_entry_count |
È possibile eseguire query sulle metriche con valori di distribuzione di Cloud Monitoring
come sugli istogrammi Prometheus, con il suffisso _count
, _sum
o _bucket
aggiunto al nome della metrica:
Nome della metrica di Cloud Monitoring | Nomi delle metriche PromQL precedenti |
---|---|
networking.googleapis.com/vm_flow/rtt |
networking_googleapis_com:vm_flow_rtt_sum networking_googleapis_com:vm_flow_rtt_count networking_googleapis_com:vm_flow_rtt_bucket
|
Compatibilità con PromQL
PromQL per Cloud Monitoring potrebbe funzionare in modo leggermente diverso rispetto a PromQL upstream.
Le query PromQL in Cloud Monitoring vengono valutate parzialmente nel backend Monarch utilizzando un linguaggio di query interno e sono presenti alcune differenze note nei risultati delle query. A parte le differenze elencate in questa sezione, PromQL in Cloud Monitoring è alla pari con PromQL disponibile in Prometheus versione 2.44.Le funzioni PromQL aggiunte dopo la versione 2.44 di Prometheus potrebbero non essere supportate.
Supporto di UTF-8
PromQL per Cloud Monitoring supporta le query UTF-8.
Se il nome della metrica Prometheus è composto solo da caratteri alfanumerici più i caratteri
_
o :
e se le chiavi delle etichette sono composte solo da caratteri alfanumerici più
il carattere _
, puoi eseguire query utilizzando la sintassi PromQL tradizionale.
Ad esempio, una query valida potrebbe avere il seguente aspetto:
job:my_metric:sum{label_key="label_value"}
.
Tuttavia, se il nome della metrica Prometheus utilizza caratteri speciali
ad eccezione dei caratteri _
o :
oppure se le chiavi delle etichette utilizzano caratteri speciali
ad eccezione del carattere _
, devi creare la query
in base alla specifica UTF-8 per PromQL.
I nomi delle metriche UTF-8 devono essere racchiusi tra virgolette e spostati tra le parentesi graffe. I nomi delle etichette devono essere racchiusi tra virgolette anche se contengono caratteri incompatibili con le versioni precedenti. Le seguenti query valide di esempio sono tutte equivalenti:
{"my.domain.com/metric/name_bucket", "label.key"="label.value"}
{__name__="my.domain.com/metric/name_bucket", "label.key"="label.value"}
{"__name__"="my.domain.com/metric/name_bucket", "label.key"="label.value"}
Corrispondenza in base ai nomi delle metriche
È supportata solo la corrispondenza esatta dei nomi delle metriche. Devi includere una corrispondenza esatta del nome della metrica nella query.
Consigliamo le seguenti soluzioni alternative per gli scenari comuni che utilizzano un matcher di espressioni regolari sull'etichetta __name__
:
- Le configurazioni dell'adattatore Prometheus spesso utilizzano l'operatore
=~
per la corrispondenza con più nomi di metriche. Per correggere questo utilizzo, espandi la configurazione in modo da utilizzare una norma separata per ogni metrica e assegna un nome esplicito a ciascuna metrica. In questo modo si evita anche di scalare automaticamente in base a metriche impreviste. - Le espressioni regolari vengono spesso utilizzate per rappresentare graficamente più metriche non dimensionali
nello stesso grafico. Ad esempio, se hai una metrica come
cpu_servicename_usage
, puoi utilizzare un carattere jolly per rappresentare graficamente tutti i tuoi servizi insieme. L'utilizzo di metriche non dimensionali come questa è una pratica esplicitamente sconsigliata in Cloud Monitoring e porta a prestazioni delle query estremamente scarse. Per correggere questo utilizzo, sposta tutta la dimensionalità nelle etichette delle metriche anziché incorporare le dimensioni nel nome della metrica. - L'esecuzione di query su più metriche viene spesso utilizzata per vedere quali metriche sono disponibili per le query. Ti consigliamo invece di utilizzare la chiamata
/labels/__name__/values
per scoprire le metriche.
Mancato aggiornamento
L'obsolescenza non è supportata nel backend di Monarch.
Calcolo di irate
Quando l'intervallo di ricerca della funzione irate
è inferiore alla dimensione del passo, aumentiamo l'intervallo fino alla dimensione del passo.
Monarch richiede questa modifica per garantire che nessuno dei dati di input
venga completamente ignorato nell'output. Questa differenza si applica anche ai calcoli di
rate
.
Calcolo di rate
e increase
Quando l'intervallo di ricerca della funzione rate
è inferiore alla dimensione del passo, aumentiamo l'intervallo fino alla dimensione del passo.
Monarch richiede questa modifica per garantire che nessuno dei dati di input
venga completamente ignorato nell'output. Questa differenza si applica anche ai calcoli di
irate
.
Esistono differenze nei calcoli di interpolazione ed estrapolazione. Monarch utilizza un algoritmo di interpolazione diverso da Prometheus e questa differenza può portare a risultati leggermente diversi. Ad esempio, i campioni del contatore Monarch vengono archiviati con un intervallo di tempo anziché con il singolo timestamp utilizzato da Prometheus. Pertanto, i campioni del contatore in Monarch possono essere inclusi nel calcolo della velocità anche se il timestamp di Prometheus li escluderebbe. In genere, ciò comporta risultati più precisi, soprattutto quando si eseguono query all'inizio o alla fine della serie temporale sottostante.
Calcolo di histogram_quantile
Un calcolo histogram_quantile
PromQL su un istogramma senza campioni produce un valore NaN. Il calcolo del linguaggio di query interno non produce alcun valore; il punto al timestamp viene eliminato.
Le differenze nel calcolo della tariffa possono influire anche sull'input delle query histogram_quantile
.
Funzioni specifiche per tipo su metriche con tipi diversi
Sebbene Prometheus upstream sia a tipizzazione debole, Monarch è a tipizzazione
forte. Ciò significa che l'esecuzione di funzioni specifiche per un singolo tipo su una metrica di tipo diverso (ad esempio, l'esecuzione di rate()
su una metrica GAUGE o di histogram_quantile()
su una metrica COUNTER o senza tipo) non funziona in Cloud Monitoring, anche se queste funzioni funzionano in Prometheus upstream.