Introduzione alla raccolta di dati con deployment automatico

Questo documento descrive come configurare Google Cloud Managed Service per Prometheus con di cui è stato eseguito il deployment autonomo. Un'applicazione di esempio viene dispiattata in un cluster Kubernetes ed è monitorata da un server Prometheus che memorizza le metriche raccolte in Monarch.

Questo documento illustra come:

  • Configura il tuo ambiente e gli strumenti a riga di comando.
  • Configura un account di servizio per i cluster con la federazione delle identità per i carichi di lavoro per GKE abilitata.
  • Esegui il programma binario Prometheus del drop-in su Kubernetes.
  • Controlla quali metriche vengono importate in Managed Service per Prometheus.
  • Integra Managed Service per Prometheus con le configurazioni dell'operatore Prometheus.
  • Compila ed esegui manualmente il programma binario Prometheus.

Con la raccolta dei dati di cui è stato eseguito il deployment autonomo, puoi gestire l'installazione di Prometheus come abbiamo sempre fatto. L'unica differenza è che eseguirai Managed Service per il programma binario sostitutivo drop-in di Prometheus, gke.gcr.io/prometheus-engine/prometheus:v2.45.3-gmp.9-gke.0, anziché il file binario Prometheus upstream.

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

Il servizio gestito per Prometheus non supporta l'esportazione delle metriche da un server federato o da un server utilizzato come destinatario di scrittura remota. Puoi riprodurre tutte le funzionalità del server di federazione, inclusa la riduzione del volume di importazione aggregando i dati prima di inviarli a Monarch, utilizzando filtri e aggregazioni locali.

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

Per ulteriori informazioni sulla raccolta dei dati gestita e con deployment automatico, 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, segui questi passaggi:

      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 fai clic su Crea.

      3. Vai a Fatturazione:

        Vai a Fatturazione

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

      5. Ti viene chiesto di scegliere un profilo pagamenti esistente per 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 a 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 "API abilitata" non viene visualizzato, fai clic sul pulsante Attiva.

  • Un cluster Kubernetes. Se non hai un cluster Kubernetes, segui le istruzioni riportate nella guida rapida per GKE.

Sono inoltre necessari i seguenti strumenti a riga di comando:

  • gcloud
  • kubectl

Gli strumenti gcloud e kubectl fanno parte Google Cloud CLI. Per informazioni sull'installazione, consulta Gestire i componenti dell'interfaccia a riga di comando Google Cloud. Per vedere le 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, eseguire la configurazione seguente:

  • Configura gli strumenti a riga di comando come segue:

    • Configura Google Cloud CLI in modo che faccia 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 tuo cluster:

      kubectl config set-cluster CLUSTER_NAME

    Per ulteriori informazioni su questi strumenti, consulta quanto segue:

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

Verificare le credenziali dell'account di servizio

Puoi saltare questa sezione se nel tuo cluster Kubernetes è attivata la federazione delle identità per i carichi di lavoro per GKE.

In esecuzione su GKE, Managed Service per Prometheus recupera automaticamente le credenziali dall'ambiente in base Account di servizio predefinito Compute Engine. L'account di servizio predefinito ha le autorizzazioni necessarie, monitoring.metricWriter e monitoring.viewer, per impostazione predefinita. Se non utilizzi la federazione delle identità di lavoro per GKE e hai precedentemente rimosso uno di questi ruoli dall'account di servizio del nodo predefinito, dovrai aggiungere di nuovo le autorizzazioni mancanti prima di continuare.

Se non esegui l'operazione su GKE, consulta Fornire le credenziali in modo esplicito.

Configura un account di servizio per la federazione delle identità per i carichi di lavoro per GKE

Puoi saltare questa sezione se il tuo cluster Kubernetes non dispone Federazione delle identità dei carichi di lavoro per GKE abilitata.

Managed Service per Prometheus 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 all'API Monitoring. In questa sezione vengono descritte le seguenti informazioni:

Crea e associa l'account di servizio

Questo passaggio viene visualizzato in diverse posizioni all'interno di Managed Service per Prometheus documentazione. Se hai già eseguito questo passaggio come parte di una dell'attività, così non dovrai ripeterla. Vai avanti e vai alla sezione Autorizzare dell'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 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 o un account di servizio GKE diverso, aggiusta i comandi di conseguenza.

Autorizza l'account di servizio

I gruppi di autorizzazioni correlate vengono raccolti in ruoli e li concedi 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 l'account di servizio Google Cloud, gmp-test-sa, i ruoli dell'API Monitoring necessari scrittura dati delle metriche.

Se hai già concesso all'account di servizio Google Cloud un ruolo specifico nell'ambito di un'attività precedente, non devi ripetere l'operazione.

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 della federazione delle identità per i carichi di lavoro per GKE

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

Poiché gli errori ortografici e i copia e incolla parziali sono le fonti di errori più comuni durante la configurazione della federazione delle identità per i carichi di lavoro per GKE, ti consigliamo vivamente di utilizzare le variabili modificabili e le icone di copia e incolla cliccabili incorporate negli esempi di codice in queste istruzioni.

Federazione delle identità per i carichi di lavoro per GKE in ambienti di produzione

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

In un ambiente di produzione, conviene usare un approccio più granulare, con un account di servizio per ogni componente, ognuno con autorizzazioni minime. Per ulteriori informazioni sulla configurazione degli account di servizio per la gestione delle identità dei carichi di lavoro, consulta Utilizzare la federazione delle identità per i carichi di lavoro per GKE.

Configurare la 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 porta metrics. Il file manifest dell'applicazione definisce tre repliche.

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

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

Esegui il programma binario Prometheus sostitutivo

Per importare i dati delle metriche emessi dall'applicazione di esempio, esegui il deployment della versione forkata di Google del server Prometheus, 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 creato mediante fork, esegui questo comando:

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

    Questo server Prometheus di cui è stato eseguito il deployment è un fork sottile del codice binario di Prometheus upstream. Si comporta come un server Prometheus standard, ma consente anche di importare i dati in Managed Service per Prometheus.

    Il manifest riportato sopra fornisce un esempio di funzionamento di base che invia i dati al data store globale Monarch. Non archivia in modo permanente copia locale dei dati. Per informazioni su come vengono applicati la configurazione open source e come estenderla, documentazione sulla configurazione di Prometheus.

    L'immagine predefinita funziona solo su 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 per creare il file binario per Windows autonomamente.

  2. Verifica che i pod per il server Prometheus e l'applicazione di esempio deployment eseguito correttamente:

    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 esegui GKE, puoi procedere nel seguente modo:

Se esegui l'operazione 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 che raccoglie recupera automaticamente le credenziali dall'ambiente in base all'account di servizio del nodo o la configurazione della federazione delle identità per i carichi di lavoro per GKE. Nei cluster Kubernetes non GKE, le credenziali devono essere fornite esplicitamente al server Prometheus di raccolta utilizzando i 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 l'account di servizio che potresti aver già creato nelle istruzioni di Workload Identity Federation per GKE.

  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 StatefulSet di Prometheus per la modifica:

    kubectl -n NAMESPACE_NAME edit statefulset prometheus-test

    1. Aggiungi il testo visualizzato 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, vengono ricreati e avviano l'autenticazione nella metrica con l'account di servizio specificato.

    In alternativa, anziché 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 di cui è stato eseguito il deployment autonomo

    In questa sezione viene descritto come effettuare le seguenti operazioni:

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

    Filtra metriche esportate

    Se raccogli molti dati, potresti voler evitare che alcune serie temporali a Managed Service per Prometheus per contenere i costi.

    Puoi usare la normale rietichettatura delle metriche configurate in Prometheus configurazione di scraping. 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 --export.match flag.

    Il flag specifica uno o più selettori della serie PromQL e il flag può può essere usato più volte. Una serie temporale viene esportata in Managed Service per Prometheus se soddisfa tutti i selettori in almeno uno dei flag. In altre parole, per determinare 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. La 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 aggregate a livello di job (se vengono seguite le best practice per la denominazione). Esempi per tutti gli altri serie vengono escluse. Per impostazione predefinita, non viene specificato nessun selettore e vengono esportate tutte le serie temporali.

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

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

    Se utilizzi la libreria prometheus-operator, imposta qualsiasi valore --export.match che utilizzano la variabile di ambiente EXTRA_ARGS della containerizzato. Per ulteriori informazioni, consulta Utilizzo con prometheus-operator.

    Puoi combinare i flag di filtro con le regole di registrazione eseguite localmente per "riepilogare" i dati prima di inviarli a Monarch, riducendo la cardinalità e i costi. Per ulteriori informazioni, consulta Controlli dei costi e attribuzione.

    La pagina Gestione delle metriche di Cloud Monitoring fornisce informazioni che possono aiutarti a controllare la spesa per le metriche fatturabili senza influire sull'osservabilità. La pagina Gestione delle metriche riporta le seguenti informazioni:

    • Volumi di importazione sia per la fatturazione basata su byte che su sample, per 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 nei criteri di avviso e nelle dashboard personalizzate.
    • Percentuale di errori di scrittura delle metriche.

    Puoi anche utilizzare la pagina Gestione delle metriche per escludere le metriche non necessarie, eliminando il costo di importazione. Per saperne di più sulla pagina Gestione delle metriche, consulta Visualizza e gestisci 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 file 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.45.3-gmp.9-gke.0
    ...
    replicas: 1
    serviceAccountName: default
    version: v2.35.0
    ...

    Se ti trovi in un cluster Workload Identity Federation per GKE e lo spazio dei nomi o il servizio account nella tua risorsa è diverso, ripeti Istruzioni per la federazione delle identità per i carichi di lavoro per GKE per le altre e la coppia di account di servizio Kubernetes.

    Quando esegui l'operazione 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 altri flag, ad esempio i flag di filtro delle metriche. Questo viene fatto tramite una variabile di ambiente perché la sezione args del la specifica del container è gestita dall'operatore Prometheus.

    Utilizzo 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 account di servizio, perciò consigliamo di modificare solo il numero minimo di campi necessarie 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.45.3-gmp.9-gke.0
      ...
      replicas: 1
      version: v2.35.0
      ...

    Se esegui l'operazione su GKE e non hai modificato l'account di servizio predefinito sul nodo, l'applicazione dei manifest modificati dovrebbe avviare immediatamente l'invio dei dati a Managed Service per Prometheus. In caso contrario, potresti dover configurare e applicare un account di servizio. Quando esegui il servizio su GKE e utilizzi Workload Identity, potresti dover creare e autorizzare l'account di servizio prometheus-k8s nello spazio dei nomi monitoring. Durante l'esecuzione su un ambiente Kubernetes non GKE segui le istruzioni riportate nella sezione dell'operatore prometheus.

    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 esegua lo scraping solo delle metriche che ti interessano e filtri in modo aggressivo le metriche esportate.

    Per ulteriori suggerimenti, consulta la sezione Controllo dei costi e attribuzione.

    Deployment ad alta disponibilità

    Il file binario Prometheus sostitutivo è dotato di supporto integrato per raccolta disponibile usando le elezioni dei leader. I server Prometheus replicati in modalità di alta disponibilità raccolgono le metriche e valutano le regole come di consueto, ma solo uno di questi invia i dati a Google Cloud Managed Service per Prometheus.

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

    Il server dell'API Kubernetes è un backend di elezione del leader supportato e può essere attivato 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 Risorsa di locazione utilizzata per l'elezione dei leader posto. Tutti i server Prometheus che rimandano alla stessa risorsa appartengono allo stesso set di repliche. L'account di servizio Kubernetes del deployment Prometheus deve l'autorizzazione a 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 replicas a 2 o superiore.

    Etichette riservate

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

    • project_id: l'identificatore del progetto Google Cloud associato al tuo o una metrica di valutazione. Obbligatorio.
    • location: la posizione fisica (regione Google Cloud) in cui vengono memorizzati i dati. Questo valore è in genere la regione del 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 tua metrica. Se non in esecuzione su Kubernetes, può essere usato come livello gerarchico arbitrario ad esempio 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. come un sottogruppo di istanze. Facoltativo, ma vivamente consigliato.
    • job: l'etichetta del job del target Prometheus, se nota; potrebbe essere vuota per i risultati della valutazione delle regole. Obbligatorio e solitamente aggiunto automaticamente da Prometheus.
    • instance: l'etichetta dell'istanza del target Prometheus, se nota; potrebbe essere vuota per i risultati della valutazione delle regole. Obbligatorio e solitamente aggiunto automaticamente da Prometheus. Se impostato manualmente o con una nuova etichetta, non utilizzare valori hardcoded come localhost, in quanto ciò causa collisioni delle serie temporali.

    Durante l'esecuzione su Google Cloud, project_id, location e cluster vengono aggiunte automaticamente a ogni metrica.

    Sebbene non sia consigliato per l'esecuzione su Google Cloud, puoi eseguire l'override project_id, location, cluster e namespace utilizzando i valori global.external_labels della configurazione Prometheus. Per ulteriori informazioni, consulta Eseguire la raccolta di cui è stato eseguito il deployment automatico all'esterno di Google Cloud.

    Se utilizzi etichette riservate come etichette delle metriche, la raccolta di cui è stato eseguito il deployment autonomo utilizzerà l'etichetta della metrica come valore per l'etichetta riservata. Questo può fornire una certa flessibilità, ma può anche generare errori se, ad esempio, Ad esempio, utilizzi l'etichetta location per fare riferimento a qualcosa di diverso da regione Google Cloud.

    Deployment binari

    Se vuoi eseguire il servizio in un ambiente non containerizzato, puoi compilare direttamente il codice binario di Prometheus sostitutivo.

    Creazione dell'origine

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

    Per compilare il file binario normale, sulla macchina devono essere installati la toolchain Go e le versioni recenti di NPM/Yarn. Per ulteriori informazioni, consulta la sezione sulla creazione di un modello istruzioni.

    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.45.3-gmp.9

    3. Per creare un tarball Managed Service per Prometheus, esegui questo comando :

      make build && make tarball

    Il file tarball e i file 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 nuove metriche e sull'aggiunta di nuove etichette alle metriche esistenti. Questo limite di frequenza di solito viene colpito solo alla prima integrazione Managed Service per Prometheus, ad esempio quando esegui la migrazione di un maturo di Prometheus per utilizzare la raccolta con deployment autonomo. Questo non è un limite di frequenza per l'importazione di punti dati. Questo limite di frequenza si applica solo quando si creano metriche mai viste prima o quando si aggiungono nuove etichette a metriche di valutazione.

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

    Per ulteriori informazioni, consulta la sezione Risoluzione dei problemi.

    Esegui raccolta di cui è stato eseguito il deployment autonomo al di fuori di Google Cloud

    Negli ambienti Compute Engine, negli ambienti GKE o macchina su cui hai eseguito gcloud login con un account sufficientemente autorizzato, può eseguire una raccolta di cui è stato eseguito il deployment autonomo senza ulteriore configurazione. Al di fuori di Google Cloud, devi fornire esplicitamente le credenziali, un project_id per contenere le tue metriche e un location (regione Google Cloud) in cui archiviarle. Devi anche impostare le etichette cluster e namespace, anche se l'applicazione viene eseguita 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 esplicitamente.

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

    Per location, ti consigliamo di scegliere la regione Google Cloud più vicina al tuo e deployment continuo. Più la regione Google Cloud scelta è lontana dal tuo deployment, maggiore è la latenza di scrittura che avrai e più sarai influenzato da potenziali problemi di rete. Ti consigliamo di consultare questo elenco di regioni su più cloud. Se non ti interessa, puoi mettere tutto in una regione Google Cloud. Non puoi usa global come posizione.

    Se viene eseguito in un ambiente Kubernetes, imposta i valori cluster e namespace al cluster e allo spazio dei nomi locali. Se esegui l'operazione all'esterno di Kubernetes, impostali su valori gerarchici significativi. Ad esempio, in un ambiente basato su VM in esecuzione su AWS, imposta il valore cluster su __aws__ e il valore namespace all'ID istanza. Puoi compilare dinamicamente l'ID istanza utilizzando una regola di rinominazione che chiama il server di metadati locale.

    Per un esempio di funzionamento minimo, puoi eseguire un file binario Prometheus locale con monitoraggio autonomo 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 \

    In questo esempio si presuppone che tu abbia impostato la variabile REGION su un valore simile a us-central1, ad esempio.

    Tuttavia, ti consigliamo di impostare le export etichette target per la campagna gestita nella sezione global.external_labels del tuo Configurazione Prometheus. Ad esempio, in ambienti Kubernetes potresti utilizzare 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 costi per il trasferimento dei dati. Sono previste delle tariffe per trasferire i dati in Google Cloud. ti potrebbero venire addebitati dei costi per trasferire i dati da un altro cloud. Puoi minimizzare questo costo attivando la compressione con il flag --export.compression=gzip.

    Passaggi successivi