PromQL per Cloud Monitoring

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:

  1. 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:

  2. Determina l'URL della tua istanza Grafana, ad esempio https://yourcompanyname.grafana.net per un deployment di Grafana Cloud o http://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.

  3. 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.

  4. Configura un service account Grafana creando il account di servizio e generando un token da utilizzare per l'account:

    1. Nella barra laterale di navigazione di Grafana, fai clic su Amministrazione > Utenti e accesso > Service account.
    2. 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.

    3. Fai clic su Aggiungi token dell'account di servizio.

    4. 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.

  5. 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/"
    
  6. 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 -
    
  7. 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:

  1. Configura un account di servizio da utilizzare per il sincronizzatore delle origini dati:

    1. Imposta il progetto predefinito per i comandi gcloud:

      gcloud config set project PROJECT_ID
      
    2. Crea un account di servizio da utilizzare per il sincronizzatore dell'origine dati:

      gcloud iam service-accounts create DS_SYNCER_SVCACCT_NAME
      
    3. 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
      
    4. 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
      
  2. Determina l'URL della tua istanza Grafana, ad esempio https://yourcompanyname.grafana.net per un deployment di Grafana Cloud o https://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.

  3. In Grafana, aggiungi un'origine dati Prometheus da utilizzare per Cloud Monitoring e registra l'UID dell'origine dati:

    1. Fai clic su Connessioni > Origini dati > Aggiungi una nuova origine dati. Seleziona Prometheus dall'elenco dei database di serie temporali.

    2. Nel campo URL server Prometheus, inserisci il seguente valore:

      https://monitoring.s3nsapis.fr/v1/projects/PROJECT_ID/location/global/prometheus/
      
    3. 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.

    4. 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
      
  4. Configura un service account Grafana creando il account di servizio e generando un token da utilizzare:

    1. Nella barra laterale di navigazione di Grafana, fai clic su Amministrazione > Utenti e accesso > Service account.
    2. Crea il account di servizio facendo clic su Aggiungi service account, assegnandogli un nome e concedendogli il ruolo "Amministratore" in Grafana.

    3. Fai clic su Aggiungi token dell'account di servizio.

    4. 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
      
  5. 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:

    1. Modifica la tabella cron:

      cron -e
      
    2. 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

    1. Per creare autonomamente il sincronizzatore dell'origine dati:

      1. 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
        
      2. Clona il codice dalla release corrente del repository:

        git clone -b 'v0.15.3' --single-branch https://github.com/GoogleCloudPlatform/prometheus-engine
        
      3. Vai alla directory datasource-syncer e compila il codice:

        cd prometheus-engine/cmd/datasource-syncer
        
        go build main.go
        
    2. 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:

      1. Modifica la tabella cron:

         cron -e
        
      2. 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.

  6. 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:

  1. Fai clic su Esplora nel pannello di navigazione o nella pagina Origini dati.

  2. 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.

  3. 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.