Introduzione alla raccolta di dati con deployment automatico

Questo documento descrive come configurare Google Cloud Managed Service per Prometheus con la raccolta autogestita. Un'applicazione di esempio viene sottoposta a deployment in un cluster Kubernetes e viene monitorata da un server Prometheus che archivia le metriche raccolte in Monarch.

Questo documento mostra come:

  • Configura l'ambiente e gli strumenti a riga di comando.
  • Configura un account di servizio per i cluster abilitati per Workload Identity Federation for GKE.
  • Esegui il binario Prometheus drop-in su Kubernetes.
  • Controlla quali metriche vengono importate in Managed Service for Prometheus.
  • Integra Managed Service per Prometheus con le configurazioni di prometheus-operator.
  • Compila ed esegui manualmente il programma binario Prometheus.

Con la raccolta di dati autodeployata, gestisci 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.53.4-gmp.0-gke.1, anziché il programma binario Prometheus upstream.

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

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

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

Per saperne di più sulla raccolta di dati gestita e con deployment automatico, consulta Raccolta di dati con Managed Service per Prometheus.

Prima di iniziare

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

Configurare progetti e strumenti

Per utilizzare Google Cloud Managed Service per Prometheus, devi disporre delle seguenti risorse:

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

    • Se non hai un Google Cloud progetto, procedi nel seguente modo:

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

        Creare un nuovo progetto

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

      3. Vai a Fatturazione:

        Vai a Fatturazione

      4. Seleziona il progetto appena creato se non è già selezionato nella parte superiore della pagina.

      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 su API e servizi

      2. Seleziona il progetto.

      3. Fai clic su Abilita API e servizi.

      4. Cerca "Monitoraggio".

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

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

  • Un cluster Kubernetes. Se non hai 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 sulla loro installazione, vedi Gestione dei componenti di Google Cloud CLI. Per visualizzare i componenti di gcloud CLI installati, 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 in modo che faccia riferimento all'ID del tuo progettoGoogle Cloud :

      gcloud config set project PROJECT_ID

    • Configura la CLI kubectl per utilizzare il cluster:

      kubectl config set-cluster CLUSTER_NAME

    Per ulteriori informazioni su questi strumenti, consulta quanto segue:

Configurare uno spazio dei nomi

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

kubectl create ns NAMESPACE_NAME

Verificare le credenziali del account di servizio

Se nel tuo cluster Kubernetes è abilitata la federazione delle identità per i carichi di lavoro per GKE, puoi saltare questa sezione.

Quando viene eseguito su GKE, Managed Service per Prometheus recupera automaticamente le credenziali dall'ambiente in base alaccount di serviziont predefinito di Compute Engine. Per impostazione predefinita, il account di servizio predefinito dispone delle autorizzazioni necessarie, monitoring.metricWriter e monitoring.viewer. Se non utilizzi 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.

Managed Service per Prometheus acquisisce i dati delle metriche utilizzando l'API Cloud Monitoring. Se il tuo cluster utilizza Workload Identity Federation for GKE, devi concedere al tuo account di servizio Kubernetes l'autorizzazione per l'API Monitoring. Questa sezione descrive quanto segue:

  • Creazione di un service accountGoogle Cloud dedicato, gmp-test-sa.
  • Associazione del service account Google Cloud al service account Kubernetes predefinito in uno spazio dei nomi di test, NAMESPACE_NAME.
  • Concessione dell'autorizzazione necessaria al service account Google Cloud .

Crea e associa il account di servizio

Questo passaggio viene visualizzato in diversi punti della documentazione di Managed Service per Prometheus. Se hai già eseguito questo passaggio nell'ambito di un'attività precedente, non è necessario ripeterlo. Vai direttamente alla sezione Autorizzare il service account.

La seguente sequenza di comandi crea il account di servizio gmp-test-sa 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 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 account di servizio diverso, modifica i comandi di conseguenza.

Autorizzare il account di servizio

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

Il seguente comando concede al service account Google Cloud , gmp-test-sa, i ruoli API Monitoring necessari per scrivere dati delle metriche.

Se hai già concesso un ruolo specifico al service account Google Cloud nell'ambito di un'attività precedente, non devi farlo di nuovo.

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

Esegui il debug della configurazione di Workload Identity Federation for GKE

Se hai difficoltà a far funzionare Workload Identity Federation for GKE, consulta la documentazione per verificare la configurazione di Workload Identity Federation for GKE e la guida alla risoluzione dei problemi di Workload Identity Federation for GKE.

Poiché gli errori di battitura e i copia-incolla parziali sono le fonti più comuni di errori durante la configurazione di Workload Identity Federation for GKE, ti consigliamo vivamente di utilizzare le variabili modificabili e le icone di copia-incolla 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 Google Cloud al account di servizio Kubernetes predefinito e concede al account di servizio Google Cloudtutte le autorizzazioni necessarie per utilizzare l'API Monitoring.

In un ambiente di produzione, potresti voler utilizzare un approccio più granulare, con unaccount di serviziot per ogni componente, ciascuno con autorizzazioni minime. Per saperne di più sulla configurazione dei service account per la gestione delle identità dei workload, consulta Utilizzare la federazione delle identità dei workload per GKE.

Configurare la raccolta di dati con deployment automatico

Questa sezione descrive come configurare ed eseguire un'applicazione di esempio che utilizza la raccolta autogestita.

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 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.15.3/examples/example-app.yaml

Esegui il programma binario Prometheus sostitutivo

Per importare i dati delle metriche emessi dall'applicazione di esempio, devi eseguire il deployment della versione fork del server Prometheus di Google, configurato per recuperare le metriche del workload e il proprio endpoint delle metriche.

  1. Per eseguire il deployment del server di cui è stato eseguito il fork, esegui questo comando:

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

    Il server Prometheus di cui è stato eseguito il deployment è un fork leggero del binario Prometheus upstream. Si comporta come un server Prometheus standard, ma inserisce anche i dati in Managed Service per Prometheus.

    Il manifest precedente fornisce un esempio di funzionamento di base che invia dati al datastore globale Monarch. Non archivia 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 di Prometheus open source.

    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 o crea autonomamente il binario per Windows.

  2. Verifica che il deployment dei pod per il server Prometheus e l'applicazione di esempio sia andato a buon fine:

    kubectl -n NAMESPACE_NAME get pod

    Se il deployment è andato a buon fine, viene visualizzato un output simile al seguente:

    NAME                            READY   STATUS    RESTARTS   AGE
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 procedere nel seguente modo:

Se l'applicazione non è in esecuzione su 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

Quando viene eseguito su GKE, il server Prometheus di raccolta recupera automaticamente le credenziali dall'ambiente in base all'account di servizio del nodo o alla configurazione della federazione delle identità per i carichi di lavoro per GKE. Nei cluster Kubernetes non GKE, le credenziali devono essere fornite in modo esplicito al server Prometheus di raccolta utilizzando flag o la variabile di ambiente GOOGLE_APPLICATION_CREDENTIALS.

  1. Imposta il contesto sul 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 il account di servizio che potresti aver già creato nelle istruzioni per Workload Identity Federation for GKE.

  3. Concedi le autorizzazioni richieste al account di servizio:

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

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

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

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

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

  6. Apri la risorsa StatefulSet di Prometheus 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. Una volta applicata la modifica, i pod vengono ricreati e iniziano l'autenticazione al backend delle metriche con iaccount di serviziont specificato.

    In alternativa, anziché utilizzare i flag impostati in questo esempio, puoi impostare il percorso del file delle chiavi utilizzando la variabile di ambiente GOOGLE_APPLICATION_CREDENTIALS.

    Altri argomenti per la raccolta con deployment autonomo

    Questa sezione descrive come:

    • Filtra i dati che esporti nel servizio gestito.
    • Converti le configurazioni di deployment esistenti.
    • Esegui il binario 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.

    Filtrare le metriche esportate

    Se raccogli molti dati, potresti voler impedire l'invio di alcune serie temporali a Managed Service for Prometheus per contenere i costi.

    Puoi utilizzare le configurazioni di rietichettatura delle metriche standard nella configurazione di scraping di Prometheus. Con le configurazioni di rietichettatura, 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 di serie PromQL e può essere utilizzato più volte. Una serie temporale viene esportata in Managed Service for Prometheus se soddisfa tutti i selettori in almeno uno dei flag; ovvero, quando si determina l'idoneità, le condizioni all'interno di un singolo flag vengono combinate con l'operatore AND, mentre le condizioni in flag separati vengono combinate con l'operatore OR. L'esempio seguente utilizza due istanze del flag:

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

    Questa modifica fa sì che vengano esportate solo le metriche per il job "prometheus", nonché le metriche prodotte dalle regole di registrazione che vengono aggregate a livello di job (quando vengono seguite le best practice di denominazione). I campioni per tutte le altre serie vengono filtrati. Per impostazione predefinita, non vengono specificati selettori e vengono esportate tutte le serie temporali.

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

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

    Se utilizzi la libreria prometheus-operator, imposta i flag --export.match utilizzando la variabile di ambiente EXTRA_ARGS del container. Per ulteriori informazioni, consulta la sezione Utilizzo con prometheus-operator.

    Puoi combinare i flag di filtro con le regole di registrazione eseguite localmente per "aggregare" i dati prima di inviarli a Monarch, riducendo 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 che spendi per le metriche fatturabili senza influire sull'osservabilità. La pagina Gestione delle metriche riporta le seguenti informazioni:

    • Volumi di importazione per la fatturazione basata su byte e campioni, in tutti i domini delle metriche e per le singole metriche.
    • Dati su etichette e cardinalità delle metriche.
    • Numero di letture per ogni metrica.
    • Utilizzo delle metriche nelle policy di avviso e nelle dashboard personalizzate.
    • Tasso di errori di scrittura delle metriche.

    Puoi anche utilizzare la pagina Gestione metriche per escludere le metriche non necessarie, eliminando il costo della loro importazione. Per saperne di più sulla pagina Gestione metriche, consulta Visualizzare e gestire l'utilizzo delle metriche.

    Utilizzo con prometheus-operator

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

    Per utilizzare il 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.53.4-gmp.0-gke.1
    ...
    replicas: 1
    serviceAccountName: default
    version: v2.35.0
    ...

    Se ti trovi in un cluster Workload Identity Federation for GKE e lo spazio dei nomi o il service account nella tua risorsa sono diversi, ripeti le istruzioni per Workload Identity Federation for GKE per la coppia aggiuntiva di spazio dei nomi e account di servizio Kubernetes.

    Quando viene eseguito su un cluster Kubernetes non GKE, devi fornire manualmente le credenziali. Per fornire le credenziali:

    1. Aggiungi un file della chiave del 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: NAMESPACE_NAME
    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 container per aggiungere flag aggiuntivi, ad esempio i flag di filtro delle metriche. Questa operazione viene eseguita tramite una variabile di ambiente perché la sezione args della specifica del container è gestita da Prometheus Operator.

    Utilizzo con kube-prometheus

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

    Kube-prometheus ha alcune strette dipendenze interne dai suoi spazi dei nomi e service account predefiniti, pertanto consigliamo di modificare solo il numero minimo di campi necessario per inviare dati a Managed Service for 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.53.4-gmp.0-gke.1
      ...
      replicas: 1
      version: v2.35.0
      ...

    Se esegui GKE e non hai modificato il account di servizio predefinito sul nodo, l'applicazione dei manifest modificati dovrebbe iniziare immediatamente a inviare dati a Managed Service for Prometheus. In caso contrario, potresti dover configurare e applicare un account di servizio. Quando esegui su GKE e utilizzi l'identità del workload, potresti dover creare e autorizzare il account di servizio prometheus-k8s all'interno dello spazio dei nomi monitoring. Quando viene eseguito su un cluster Kubernetes non GKE, segui le istruzioni nella sezione prometheus-operator.

    Tieni presente che kube-prometheus raccoglie molte metriche per impostazione predefinita, la maggior parte delle quali spesso non sono necessarie in un ambiente Kubernetes gestito come GKE. Per risparmiare sui costi di importazione, puoi personalizzare kube-prometheus in modo che recuperi solo le metriche che ti interessano e filtri in modo aggressivo le metriche esportate.

    Per altri suggerimenti, consulta Controllo dei costi e attribuzione.

    Deployment ad alta disponibilità

    Il programma binario Prometheus sostitutivo include il supporto integrato per la raccolta a disponibilità elevata tramite l'utilizzo della selezione del leader. I server Prometheus replicati in modalità ad alta disponibilità raccolgono le metriche e valutano le regole come di consueto, ma solo uno di loro invia i dati a Google Cloud Managed Service per Prometheus.

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

    Il server API Kubernetes è un backend di selezione del 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 tramite la quale avviene la selezione del leader. Tutti i server Prometheus che puntano alla stessa risorsa appartengono allo stesso set di repliche. Il account di servizio Kubernetes del deployment di Prometheus deve disporre dell'autorizzazione per leggere e scrivere la rispettiva risorsa Lease. Quando esegui il server Prometheus al di fuori di un cluster Kubernetes, puoi fornire una configurazione esplicita utilizzando il flag --export.ha.kube.config.

    Dopo averlo fatto, puoi aumentare il valore di replicas a 2 o più.

    Etichette riservate

    Managed Service per Prometheus utilizza sei etichette riservate per identificare in modo univoco una risorsa in Monarch:

    • project_id: L'identificatore del progetto Google Cloud associato alla metrica. Obbligatorio.
    • location: la posizione fisica (regioneGoogle Cloud ) in cui vengono archiviati i dati. Questo valore è in genere la regione del tuo cluster GKE. Se i dati vengono raccolti da un deployment AWS o on-premise, il valore potrebbe essere la regione Google Cloud più vicina. Obbligatorio.
    • cluster: il nome del cluster Kubernetes associato alla metrica. Se non viene eseguito su Kubernetes, può essere utilizzato come livello gerarchico arbitrario come un gruppo di istanze. Facoltativo, ma vivamente consigliato.
    • namespace: il nome dello spazio dei nomi Kubernetes associato alla metrica. Se non viene eseguito su Kubernetes, può essere utilizzato come livello gerarchico arbitrario, ad esempio un sottogruppo di istanze. Facoltativo, ma vivamente consigliato.
    • job: l'etichetta del job della destinazione Prometheus, se nota; potrebbe essere vuota per i risultati della valutazione delle regole. Obbligatorio e in genere aggiunto automaticamente da Prometheus.
    • instance: l'etichetta dell'istanza della destinazione Prometheus, se nota; potrebbe essere vuota per i risultati della valutazione delle regole. Obbligatorio e in genere aggiunto automaticamente da Prometheus. Se impostati o etichettati nuovamente manualmente, non utilizzare valori hardcoded come localhost, in quanto ciò causa conflitti tra le serie temporali.

    Quando viene eseguito su Google Cloud, le etichette project_id, location e cluster vengono aggiunte automaticamente a ogni metrica.

    Sebbene non sia consigliato durante l'esecuzione su Google Cloud, puoi ignorare le etichette project_id, location, cluster e namespace utilizzando la sezione global.external_labels della configurazione di Prometheus. Per ulteriori informazioni, consulta Eseguire la raccolta autodeploy al di fuori di Google Cloud.

    Se utilizzi etichette riservate come etichette delle metriche, la raccolta autogestita utilizzerà l'etichetta della metrica come valore per l'etichetta riservata. Ciò può offrire una certa flessibilità, ma può anche portare a errori se, ad esempio, utilizzi l'etichetta location per fare riferimento a qualcosa di diverso da una regioneGoogle Cloud .

    Configura statsd_exporter e altri esportatori che segnalano le metriche centralmente

    Se utilizzi statsd_exporter per Prometheus, Envoy per Istio, SNMP exporter, Prometheus Pushgateway, kube-state-metrics o hai un altro exporter simile che intermedia e segnala le metriche per conto di altre risorse in esecuzione nel tuo ambiente, devi apportare alcune piccole modifiche affinché l'exporter funzioni con Managed Service per Prometheus.

    Per istruzioni sulla configurazione di questi esportatori, consulta questa nota nella sezione Risoluzione dei problemi.

    Deployment binari

    Se vuoi eseguire l'operazione in un ambiente non containerizzato, puoi creare direttamente il binario Prometheus sostitutivo.

    Creazione dell'origine

    Se hai un processo esistente per compilare Prometheus autonomamente, puoi sostituire in modo trasparente il nostro repository GitHub nel tuo processo. Managed Service per Prometheus ha una propria estensione del tag di versione per distinguere le sue release da quelle upstream.

    Per creare il file binario semplice, sulla macchina devono essere installati la toolchain Go e le versioni recenti di NPM/Yarn. Per maggiori informazioni, consulta le istruzioni per la build upstream.

    1. Clona il repository:

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

    2. Controlla il tag della versione che ti interessa:

      git checkout v2.53.4-gmp.0

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

      make build && make tarball

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

    Limiti per la creazione e l'aggiornamento di metriche ed etichette

    Managed Service per Prometheus applica un limite di frequenza al minuto per la creazione di nuove metriche e per l'aggiunta di nuove etichette delle metriche a quelle esistenti. Questo limite di frequenza viene in genere raggiunto solo durante l'integrazione iniziale con Managed Service per Prometheus, ad esempio quando esegui la migrazione di un deployment Prometheus esistente e maturo per utilizzare la raccolta con deployment automatico. Questo non è un limite di frequenza per l'importazione dei punti dati. Questo limite di frequenza si applica solo quando vengono create metriche mai viste prima o quando vengono aggiunte nuove etichette a metriche esistenti.

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

    Per saperne di più, vedi Risoluzione dei problemi.

    Esegui la 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 la raccolta autodeploy senza ulteriore configurazione. Al di fuori di Google Cloud, devi fornire esplicitamente le credenziali, un project_id per contenere le metriche e un location (regioneGoogle Cloud ) in cui archiviarle. Devi impostare anche le etichette cluster e namespace, anche se l'esecuzione avviene in un ambiente non Kubernetes.

    Puoi fornire una chiave 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 modello di tenancy pianificato per le letture. Scegli un progetto in cui archiviare le metriche in base a come prevedi di organizzare le letture successive 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ù la Google Cloud regione scelta è lontana dal tuo deployment, maggiore sarà la latenza di scrittura e maggiore sarà l'impatto di potenziali problemi di rete. Ti consigliamo di consultare questo elenco di regioni in più cloud. Se non ti interessa, puoi inserire tutto in una Google Cloud regione. Non puoi utilizzare global come posizione.

    Se l'applicazione viene eseguita in un ambiente Kubernetes, imposta i valori cluster e namespace sul cluster e sullo spazio dei nomi locali. Se vengono eseguiti al di fuori di Kubernetes, impostali su valori che abbiano senso gerarchicamente. 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 riassegnazione delle etichette che chiama il server di metadati locale.

    Per un esempio di funzionamento minimo, puoi eseguire un binario Prometheus locale e automonitorato con il seguente comando:

    ./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, ad esempio.

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

    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 costi per il trasferimento dei dati. Sono previste tariffe per il trasferimento dei dati in Google Cloude potresti incorrere in tariffe per il trasferimento dei dati da un altro cloud. Puoi ridurre al minimo questo costo attivando la compressione con il flag --export.compression=gzip.

    Passaggi successivi