Introduzione alla raccolta di dati con deployment automatico

Questo documento descrive come configurare Google Cloud Managed Service per Prometheus con una raccolta con deployment autonomo. Il deployment di un'applicazione di esempio in un cluster Kubernetes viene monitorata da un server Prometheus che archivia le metriche raccolte in Monarch.

Questo documento spiega come effettuare le seguenti operazioni:

  • Configura il tuo ambiente e gli strumenti a riga di comando.
  • Configura un account di servizio per i cluster abilitati per Workload Identity.
  • Eseguire il programma binario di Prometheus disponibile su Kubernetes.
  • Controlla quali metriche vengono importate in Managed Service per Prometheus.
  • Integra Managed Service per Prometheus con configurazioni dell'operatore Prometheus.
  • Compila ed esegui manualmente il programma binario di Prometheus.

Con la raccolta dei dati con deployment autonomo, puoi gestire l'installazione di Prometheus come hai sempre fatto. L'unica differenza è che esegui il programma binario di sostituzione drop-in di Managed Service per Prometheus, gke.gcr.io/prometheus-engine/prometheus:v2.43.1-gmp.0-gke.0, anziché il programma binario di Prometheus a monte.

Il programma binario del drop-in fornisce opzioni di configurazione aggiuntive con i flag --export.*. Per ulteriori informazioni, consulta l'output dell'opzione --help. Questo documento evidenzia le opzioni più importanti.

Managed Service per Prometheus non supporta l'esportazione delle metriche da un server federazione o da un server utilizzato come ricevitore di scrittura remota. Puoi replicare tutte le funzionalità dei server federazione, inclusa la riduzione del volume di importazione aggregando i dati prima dell'invio a Monarch, utilizzando filtri e aggregazioni locali.

Il flusso di dati in Managed Service per Prometheus consuma risorse aggiuntive. Se esegui il deployment dei raccoglitori autonomamente, ti consigliamo di aumentare i limiti di CPU e memoria di 5 volte e di regolarli in base all'utilizzo effettivo.

Per maggiori informazioni sulla raccolta dei dati gestita e con deployment autonomo, consulta Raccolta dei dati con Managed Service per Prometheus.

Prima di iniziare

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

Configura progetti e strumenti

Per utilizzare Google Cloud Managed Service per Prometheus, sono necessarie le seguenti risorse:

  • Un progetto Google Cloud con l'API Cloud Monitoring abilitata.

    • Se non hai un progetto Google Cloud:

      1. Nella console Google Cloud, vai a Nuovo progetto:

        Crea un nuovo progetto

      2. Nel campo Nome progetto, inserisci un nome per il progetto e fai clic su Crea.

      3. Vai a Fatturazione:

        Vai a Fatturazione

      4. Seleziona il progetto appena creato, se non è già selezionato in alto.

      5. Ti viene chiesto di scegliere un profilo pagamenti esistente o di crearne uno nuovo.

      L'API Monitoring è abilitata per impostazione predefinita per i nuovi progetti.

    • Se hai già un progetto Google Cloud, assicurati che l'API Monitoring sia abilitata:

      1. Vai ad API e servizi:

        Vai ad API e servizi

      2. Seleziona il progetto.

      3. Fai clic su Abilita API e servizi.

      4. Cerca "Monitoring".

      5. Nei risultati di ricerca, fai clic su "API Cloud Monitoring".

      6. Se non viene visualizzato "API abilitata", fai clic sul pulsante Abilita.

  • Un cluster Kubernetes. Se non disponi di un cluster Kubernetes, segui le istruzioni riportate nella Guida rapida per GKE.

Sono necessari anche i seguenti strumenti a riga di comando:

  • gcloud
  • kubectl

Gli strumenti gcloud e kubectl fanno parte di Google Cloud CLI. Per informazioni su come installarli, consulta Gestione dei componenti di Google Cloud CLI. Per visualizzare i componenti gcloud CLI che hai installato, esegui questo comando:

gcloud components list

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

      kubectl config set-cluster CLUSTER_NAME

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

Configura uno spazio dei nomi

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

kubectl create ns NAMESPACE_NAME

Verifica le credenziali dell'account di servizio

Puoi saltare questa sezione se per il tuo 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 ha le 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 riaggiungere le autorizzazioni mancanti prima di continuare.

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

Configura un account di servizio per Workload Identity

Puoi saltare questa sezione se per il tuo 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 al tuo account di servizio Kubernetes l'autorizzazione all'API Monitoring. Questa sezione descrive quanto segue:

Crea e associa l'account di servizio

Questo passaggio viene visualizzato in diverse sezioni della documentazione di Managed Service per Prometheus. Se hai già eseguito questo passaggio come parte di un'attività precedente, non è necessario ripeterlo. Vai avanti per 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 di conseguenza.

Autorizza l'account di servizio

I gruppi di autorizzazioni correlate vengono raccolti in ruoli e 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 scrivere i dati delle metriche.

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

gcloud projects add-iam-policy-binding PROJECT_ID\
  --member=serviceAccount:gmp-test-sa@PROJECT_ID.iam.gserviceaccount.com \
  --role=roles/monitoring.metricWriter

Esegui il debug della configurazione di Workload Identity

Se hai difficoltà a utilizzare 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 gli errori di copia-incolla parziali sono le fonti di errore più comuni 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 negli ambienti di produzione

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

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

Configura una raccolta con deployment autonomo

Questa sezione descrive come configurare ed eseguire un'applicazione di esempio che utilizza una raccolta di cui è stato eseguito il deployment autonomo.

Esegui il deployment dell'applicazione di esempio

L'applicazione di esempio emette la metrica del contatore example_requests_total e la metrica dell'istogramma example_random_numbers (tra le altre) sulla sua porta metrics. Il manifest per l'applicazione definisce tre repliche.

Per eseguire il deployment dell'applicazione di esempio, esegui questo comando:

kubectl -n NAMESPACE_NAME apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/prometheus-engine/v0.10.0/examples/example-app.yaml

Esegui il programma binario di Prometheus sostitutivo

Per importare i dati delle metriche emessi dall'applicazione di esempio, esegui il deployment della versione del server Prometheus di cui Google ha eseguito il fork, che è configurato per eseguire lo scraping delle metriche del carico di lavoro e del proprio endpoint delle metriche.

  1. Per eseguire il deployment del server fork, esegui questo comando:

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

    Questo server Prometheus di cui è stato eseguito il deployment è un fork thin del file binario Prometheus a monte. Si comporta come un server Prometheus standard, ma importa anche i dati in Managed Service per Prometheus.

    Il file manifest riportato sopra fornisce un esempio funzionante di base che invia dati al datastore globale Monarch. Non memorizza in modo permanente una copia locale dei dati. Per informazioni su come funziona questa configurazione predefinita e su come estenderla, consulta la documentazione sulla configurazione open source di Prometheus.

    L'immagine predefinita funziona solo sui nodi Linux. Per eseguire lo scraping dei target in esecuzione sui nodi Windows, esegui il deployment del server su un nodo Linux e configuralo per eseguire lo scraping degli endpoint sui nodi Windows oppure crea manualmente il programma binario per Windows.

  2. Verifica che il deployment dei pod per il server Prometheus e dell'applicazione di esempio sia stato eseguito correttamente:

    kubectl -n NAMESPACE_NAME get pod

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

    NAME                            READY   STATUS    RESTARTS   AGE
prom-example-84c6f547f5-fglbr   1/1     Running   0          5m
prom-example-84c6f547f5-jnjp4   1/1     Running   0          5m
prom-example-84c6f547f5-sqdww   1/1     Running   0          5m
prometheus-test-0               2/2     Running   1          3m

Se utilizzi GKE, puoi fare quanto segue:

Se esegui l'esecuzione al di fuori di GKE, devi creare un account di servizio e autorizzarlo a scrivere i dati delle metriche, come descritto nella sezione seguente.

Fornisci le credenziali in modo esplicito

Durante l'esecuzione su GKE, il server Prometheus di raccolta 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 server Prometheus che li raccoglie utilizzando i flag o la variabile di ambiente GOOGLE_APPLICATION_CREDENTIALS.

  1. Imposta il contesto per il progetto di destinazione:

    gcloud config set project PROJECT_ID

  2. Crea un account di servizio:

    gcloud iam service-accounts create gmp-test-sa

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

  3. Concedi le autorizzazioni richieste all'account di servizio:

    gcloud projects add-iam-policy-binding PROJECT_ID\
  --member=serviceAccount:gmp-test-sa@PROJECT_ID.iam.gserviceaccount.com \
  --role=roles/monitoring.metricWriter

  4. Crea e scarica una chiave per l'account di servizio:

    gcloud iam service-accounts keys create gmp-test-sa-key.json \
  --iam-account=gmp-test-sa@PROJECT_ID.iam.gserviceaccount.com

  5. Aggiungi il file della chiave come secret al cluster non GKE:

    kubectl -n NAMESPACE_NAME create secret generic gmp-test-sa \
  --from-file=key.json=gmp-test-sa-key.json

  6. Apri la risorsa Prometheus StatefulSet per la modifica:

    kubectl -n NAMESPACE_NAME edit statefulset prometheus-test

    1. Aggiungi il testo mostrato in grassetto alla risorsa:

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

    2. Salva il file e chiudi l'editor. Dopo l'applicazione della modifica, i pod vengono ricreati e iniziano l'autenticazione 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 della chiave utilizzando la variabile di ambiente GOOGLE_APPLICATION_CREDENTIALS.

    Argomenti aggiuntivi per la raccolta con deployment autonomo

    In questa sezione viene descritto come:

    • Filtra i dati che esporti nel servizio gestito.
    • Converti le configurazioni di deployment esistenti.
    • Esegui il programma binario di Prometheus in modalità ad alta disponibilità.
    • Crea ed esegui il programma binario Prometheus sostitutivo.
    • Esegui Managed Service per Prometheus al di fuori di Google Cloud.

    Filtra le metriche esportate

    Se raccogli molti dati, è consigliabile evitare che alcune serie temporali vengano inviate a Managed Service per Prometheus per contenere i costi.

    Puoi utilizzare le normali configurazioni di rietichettatura delle metriche nella configurazione di scraping di Prometheus. Con la rietichettatura delle configurazioni, puoi eliminare le metriche in base alle corrispondenze delle etichette al momento dell'importazione.

    A volte, potresti voler importare i dati localmente, ma non esportarli in Managed Service per Prometheus. Per filtrare le metriche esportate, puoi utilizzare il flag --export.match.

    Il flag specifica uno o più selettori della serie PromQL e può essere utilizzato più volte. Una serie temporale viene esportata in Managed Service per Prometheus se soddisfa tutti i selettori in almeno uno dei flag; ovvero, quando si determina l'idoneità, le condizioni in un singolo flag vengono associate con l'operatore AND, mentre le condizioni in flag separati vengono impostate tramite OR. L'esempio seguente utilizza due istanze del flag:

    ./prometheus \
  --export.match='{job="prometheus"}' \
  --export.match='{__name__=~"job:.+"}' \
  ...

    Questa modifica comporta l'esportazione solo delle metriche per il job "Prometheus" e delle metriche prodotte dalle regole di registrazione che vengono aggregate a livello di job (quando si seguono le best practice di denominazione). I campioni delle altre serie vengono filtrati. Per impostazione predefinita, non viene specificato alcun selettore e vengono esportate tutte le serie temporali.

    Il flag --export.match ha la stessa semantica del parametro match[] per la federazione di Prometheus. Di conseguenza, puoi eseguire la migrazione delle configurazioni della federazione a Managed Service per Prometheus utilizzando i selettori del server della federazione direttamente come flag sui server Prometheus estratti dal server Prometheus della federazione. L'esportazione delle metriche da un server di federazione al servizio gestito non è supportata.

    Per includere metriche di tipo histogram in un filtro, devi specificare le metriche _count, _sum e _bucket. Puoi farlo anche con un matcher con caratteri jolly, ad esempio il selettore {__name__=~"histogram_metric_.+"}.

    Se utilizzi la libreria prometheus-operator, imposta qualsiasi flag --export.match utilizzando la variabile di ambiente EXTRA_ARGS del container. Per ulteriori informazioni, vedi Utilizzare con prometheus-operator.

    Puoi combinare i flag dei filtri con regole di registrazione eseguite localmente per "aggregare" i dati prima di inviarli a Monarch, riducendo così la cardinalità e i costi. Per ulteriori informazioni, consulta Controllo dei costi e attribuzione.

    La pagina Gestione delle metriche di Cloud Monitoring fornisce informazioni che possono aiutarti a controllare l'importo speso per le metriche addebitabili senza influire sull'osservabilità. La pagina Gestione delle metriche riporta le seguenti informazioni:

    • Volumi di importazione per la fatturazione basata su byte e campioni, nei domini delle metriche e per le singole metriche.
    • Dati su etichette e cardinalità delle metriche.
    • Utilizzo delle metriche nei criteri di avviso e nelle dashboard personalizzate.
    • Percentuale di errori di scrittura delle metriche.
    Per saperne di più sulla pagina Gestione delle metriche, consulta Visualizzare e gestire l'utilizzo delle metriche.

    Utilizza con l'operatore Prometheus

    Il programma binario di Managed Service per Prometheus Prometheus può essere utilizzato anche con un deployment di GKE Prometheus esistente gestito da prometheus-operator.

    Per utilizzare il programma binario del servizio gestito, sostituisci la specifica dell'immagine nella risorsa Prometheus:

      apiVersion: monitoring.coreos.com/v1
  kind: Prometheus
  metadata:
    name: NAMESPACE_NAME
    namespace: gmp-system
  spec:
    image: gke.gcr.io/prometheus-engine/prometheus:v2.43.1-gmp.0-gke.0
    ...
    replicas: 1
    serviceAccountName: default
    version: v2.35.0
    ...

    Se ti trovi in un cluster Workload Identity e lo spazio dei nomi o l'account di servizio nella tua risorsa è diverso, ripeti le istruzioni di Workload Identity per la coppia aggiuntiva di spazio dei nomi e account di servizio Kubernetes.

    Quando esegui l'esecuzione su un cluster Kubernetes non GKE, devi fornire manualmente le credenziali. Per fornire le credenziali:

    1. Aggiungi un file della chiave dell'account di servizio appropriato come secret, come descritto in Fornire le credenziali in modo esplicito.

    2. Modifica la risorsa Prometheus per aggiungere il testo mostrato in grassetto:

        apiVersion: monitoring.coreos.com/v1
  kind: Prometheus
  metadata:
    namespace: gmp-test
    name: example
  spec:
    ...
    secrets:
    - gmp-test-sa
    containers:
    - name: prometheus
      env:
      - name: GOOGLE_APPLICATION_CREDENTIALS
        value: /gmp/key.json
      volumeMounts:
      - name: secret-gmp-test-sa
        mountPath: /gmp
        readOnly: true

    Puoi impostare la variabile di ambiente EXTRA_ARGS del contenitore per aggiungere ulteriori flag, ad esempio i flag di filtro delle metriche. Questo viene fatto tramite una variabile di ambiente perché la sezione args della specifica del container è gestita dall'operatore Prometheus.

    Utilizza con kube-prometheus

    Puoi configurare i deployment creati utilizzando la popolare libreria kube-prometheus per utilizzare Managed Service per Prometheus.

    kube-prometheus ha alcune dipendenze interne strette negli spazi dei nomi predefiniti e negli account di servizio, quindi ti consigliamo di modificare solo il numero minimo di campi necessari per inviare dati a Managed Service per Prometheus.

    In manifests/prometheus-prometheus.yaml, sostituisci la specifica dell'immagine e disattiva la raccolta ad alta disponibilità riducendo replicas a 1:

        apiVersion: monitoring.coreos.com/v1
    kind: Prometheus
    ...
    spec:
      image: gke.gcr.io/prometheus-engine/prometheus:v2.43.1-gmp.0-gke.0
      ...
      replicas: 1
      version: v2.35.0
      ...

    Se sei in esecuzione su GKE e non hai modificato l'account di servizio predefinito sul nodo, l'applicazione dei manifest modificati dovrebbe iniziare immediatamente a inviare dati a Managed Service per Prometheus. In caso contrario, potresti dover configurare e applicare un account di servizio. Durante l'esecuzione su GKE e l'utilizzo di Workload Identity, potrebbe essere necessario creare e autorizzare l'account di servizio prometheus-k8s all'interno dello spazio dei nomi monitoring. Quando esegui l'esecuzione su un cluster Kubernetes non GKE, segui le istruzioni riportate nella sezione Prometheus-Operator.

    Tieni presente che kube-prometheus raccoglie molte metriche per impostazione predefinita, la maggior parte delle quali spesso non è necessaria in un ambiente Kubernetes gestito come GKE. Per risparmiare sui costi di importazione, puoi personalizzare kube-prometheus in modo che esegua lo scraping solo delle metriche che ti interessano e filtra quelle esportate in modo aggressivo.

    Per ulteriori suggerimenti, consulta Controllo dei costi e attribuzione.

    Deployment ad alta disponibilità

    Il programma binario di Prometheus sostitutivo offre il supporto integrato per una raccolta ad alta disponibilità mediante l'elezione dei leader. I server Prometheus replicati in modalità ad alta disponibilità raccolgono sia metriche sia valutano le regole come di consueto, ma solo uno di questi invia dati a Google Cloud Managed Service per Prometheus.

    Le repliche dello stesso server Prometheus devono avere sempre configurazioni identiche, incluso lo stesso external_labels. Questo requisito è diverso da altri sistemi, che si basano su un'etichetta esterna speciale, come __replica__, per rendere le repliche esplicitamente diverse.

    Il server API Kubernetes è un backend per l'elezione leader supportato e può essere abilitato impostando i seguenti flag:

    ./prometheus
  ...
  --export.ha.backend=kube \
  --export.ha.kube.namespace=LEASE_NAMESPACE \
  --export.ha.kube.name=LEASE_NAME

    I valori LEASE_NAMESPACE e LEASE_NAME identificano la risorsa Lease attraverso la quale avvengono le elezioni dei leader. Tutti i server Prometheus che puntano alla stessa risorsa appartengono allo stesso set di replica. L'account di servizio Kubernetes del deployment di Prometheus richiede l'autorizzazione per leggere e scrivere la rispettiva risorsa Lease. Quando esegui il server Prometheus all'esterno di un cluster Kubernetes, puoi fornire una configurazione esplicita utilizzando il flag --export.ha.kube.config.

    Dopodiché puoi aumentare il valore di replicas impostandolo su 2 o su un valore superiore.

    Deployment binari

    Se vuoi eseguirlo in un ambiente non containerizzato, puoi creare direttamente il programma binario di Prometheus di sostituzione.

    Creazione del codice sorgente

    Se hai già un processo per la compilazione di Prometheus, puoi sostituire in modo trasparente il nostro repository GitHub nel processo. Managed Service per Prometheus ha una propria estensione tag di versione per distinguere le sue release da quelle upstream.

    Per creare il programma binario semplice, è necessario installare sulla macchina la toolchain Go e le versioni recenti di NPM/Yarn. Per ulteriori informazioni, consulta le istruzioni di creazione upstream.

    1. Clona il repository:

      git clone https://github.com/GoogleCloudPlatform/prometheus &&
cd prometheus

    2. Controlla il tag di versione desiderato:

      git checkout v2.43.1-gmp.0

    3. Per creare un tarball di Managed Service per Prometheus, esegui questi comandi:

      make build && make tarball

    Il tarball e i file binari risultanti sono completamente compatibili con le varianti upstream in termini di struttura e funzionalità delle directory.

    Limiti relativi alla creazione e all'aggiornamento di metriche ed etichette

    Managed Service per Prometheus applica un limite di frequenza al minuto per la creazione di nuove metriche e l'aggiunta di nuove etichette delle metriche alle metriche esistenti. Questo limite di frequenza viene generalmente raggiunto solo la prima volta che si integra con Managed Service per Prometheus, ad esempio quando esegui la migrazione di un deployment Prometheus matura esistente per utilizzare una raccolta con deployment autonomo. Questo non è un limite di frequenza per l'importazione di punti dati. Questo limite di frequenza si applica solo durante la creazione di metriche mai viste prima o quando si aggiungono nuove etichette a metriche esistenti.

    Questa quota è corretta, ma gli eventuali problemi dovrebbero risolversi automaticamente man mano che vengono create nuove metriche ed etichette delle metriche entro il limite al minuto.

    Per ulteriori informazioni, consulta la sezione Risoluzione dei problemi.

    Esegui una raccolta con deployment autonomo al di fuori di Google Cloud

    Negli ambienti Compute Engine, negli ambienti GKE o su una macchina in cui hai eseguito gcloud login con un account sufficientemente autorizzato, puoi eseguire una raccolta di cui è stato eseguito il deployment autonomamente senza ulteriori configurazioni. Al di fuori di Google Cloud, devi fornire esplicitamente le credenziali, un project_id per contenere le metriche e un location (regione di Google Cloud) in cui archiviare le metriche. Devi inoltre impostare le etichette cluster e namespace, anche se in esecuzione in un ambiente non Kubernetes.

    Puoi fornire una chiave dell'account di servizio utilizzando il flag --export.credentials-file o la variabile di ambiente GOOGLE_APPLICATION_CREDENTIALS come descritto in Fornire le credenziali in modo esplicito.

    Ti consigliamo di scegliere project_id in base al tuo modello di tenancy pianificato per le letture. Scegli un progetto in cui archiviare le metriche in base a come prevedi di organizzare le letture in un secondo momento con gli ambiti delle metriche. Se non ti interessa, puoi inserire tutto in un unico progetto.

    Per location, ti consigliamo di scegliere la regione Google Cloud più vicina al tuo deployment. Più si trova la regione Google Cloud scelta dal deployment, maggiore sarà la latenza di scrittura che avrai e più riguarderanno potenziali problemi di rete. Potresti consultare questo elenco di regioni in più cloud. Se non ti interessa, puoi inserire tutto in un'unica regione Google Cloud. Non puoi usare global come località.

    Se in esecuzione in un ambiente Kubernetes, imposta i valori cluster e namespace sullo spazio dei nomi e cluster locali. Se vengono eseguite al di fuori di Kubernetes, impostale su valori gerarchici. Ad esempio, in un ambiente basato su VM in esecuzione su AWS, imposta il valore cluster su __aws__ e il valore namespace sull'ID istanza. Puoi compilare dinamicamente l'ID istanza utilizzando una regola di rietichettatura che chiami il server di metadati locale.

    Per un esempio di funzionamento minimo, puoi eseguire un file binario Prometheus locale con auto-monitoraggio con il comando seguente:

    ./prometheus \
  --config.file=documentation/examples/prometheus.yaml \
  --export.label.project-id=PROJECT_ID \
  --export.label.location=REGION \
  --export.label.cluster=CLUSTER_NAME \

    Questo esempio presuppone che tu abbia impostato la variabile REGION su un valore come us-central1.

    Tuttavia, ti consigliamo di impostare le etichette di destinazione export per il servizio gestito nella sezione global.external_labels della configurazione di Prometheus. Ad esempio, negli ambienti Kubernetes potresti utilizzare la configurazione seguente:

    global:
  external_labels:
    project_id: PROJECT_ID
    location: REGION
    cluster: CLUSTER_NAME
    namespace: local-testing

scrape_configs:
  ...

    L'esecuzione di Managed Service per Prometheus al di fuori di Google Cloud comporta tariffe per il trasferimento di dati. Il trasferimento dei dati in Google Cloud è a pagamento, così come per il trasferimento dei dati al di fuori di un altro cloud. Puoi ridurre al minimo questo costo attivando la compressione con il flag --export.compression=gzip.

    Passaggi successivi