Introduzione alla raccolta di dati gestita

Questo documento descrive come configurare Google Cloud Managed Service per Prometheus con la raccolta gestita. La configurazione è un esempio minimo di importazione funzionante, che utilizza un deployment di Prometheus che monitora un'applicazione di esempio e memorizza le metriche raccolte in Monarch.

Questo documento illustra come:

• Configura l'ambiente e gli strumenti a riga di comando.
• Configura la raccolta gestita per il cluster.
• Configura una risorsa per lo scraping del target e l'importazione delle metriche.
• Esegui la migrazione delle risorse personalizzate prometheus-operator esistenti.

Ti consigliamo di utilizzare la raccolta gestita, che riduce la complessità di implementazione, scalabilità, partizionamento, configurazione e manutenzione dei collezionisti. La raccolta gestita è supportata per GKE e per tutti gli altri ambienti Kubernetes.

La raccolta gestita esegue i raccoglitori basati su Prometheus come daemonset e garantisce la scalabilità estraendo i target solo su nodi colocalizzati. Configura i collettivi con risorse personalizzate leggere per eseguire lo scraping degli esportatori utilizzando la raccolta pull, quindi i collettivi inviano i dati estratti al datastore Monarch centrale. Google Cloud non accede mai direttamente al tuo cluster per estrarre o estrapolare i dati delle metriche. I tuoi collector inviano i dati a Google Cloud. Per saperne di più sulla raccolta dei dati gestita e con deployment automatico, consulta Raccolta dei dati con Managed Service per Prometheus ed Importazione ed esecuzione di query con raccolte gestite e con deployment automatico.

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, 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, quindi 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 ad 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 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 dellGoogle Cloud CLI. Per informazioni sull'installazione, consulta Gestire i componenti dell'interfaccia a riga di comando Google Cloud. Per visualizzare i componenti gcloud CLI che hai installato, esegui il seguente 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 progetto Google Cloud:

    gcloud config set project PROJECT_ID
    

  • Configura l'interfaccia a riga di comando kubectl in modo da utilizzare il cluster:

    kubectl config set-cluster CLUSTER_NAME
    

  Per ulteriori informazioni su questi strumenti, consulta quanto segue:

  • Panoramica dell'interfaccia a riga di comando gcloud
  • Comandi kubectl

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

Configurare la raccolta gestita

Puoi utilizzare la raccolta gestita sia su cluster Kubernetes GKE che non GKE.

Dopo aver attivato la raccolta gestita, i componenti all'interno del cluster verranno eseguiti, ma non verranno ancora generate metriche. Le risorse PodMonitoring o ClusterPodMonitoring sono necessarie a questi componenti per eseguire correttamente lo scraping degli endpoint delle metriche. Devi eseguire il deployment di queste risorse con endpoint delle metriche validi o attivare uno dei pacchetti di metriche gestite, ad esempio Kube State Metrics, integrato in GKE. Per informazioni sulla risoluzione dei problemi, consulta Problemi relativi all'importazione.

L'abilitazione della raccolta gestita installa i seguenti componenti nel cluster:

• Il deployment gmp-operator, che esegue il deployment dell'operatore Kubernetes per Managed Service per Prometheus.
• Il deployment rule-evaluator, utilizzato per configurare ed eseguire le regole di avviso e registrazione.
• Il DaemonSet collector, che esegue la scalabilità orizzontale della raccolta estraendo le metriche solo dai pod in esecuzione sullo stesso nodo di ciascun raccoglitore.
• Il StatefulSet alertmanager, configurato per inviare avvisi attivati ai tuoi canali di notifica preferiti.

Per la documentazione di riferimento sull'operatore Managed Service per Prometheus, consulta la pagina dei manifest.

Abilita raccolta gestita: GKE

La raccolta gestita è attiva per impostazione predefinita per:

• Cluster GKE Autopilot che eseguono GKE versione 1.25 o successive.

• Cluster GKE Standard che eseguono GKE 1.27 o versioni successive. Puoi sostituire questo valore predefinito durante la creazione del cluster; consulta Disattivare la raccolta gestita.

Se utilizzi un ambiente GKE che non attiva la raccolta gestita per impostazione predefinita, consulta Abilitare manualmente la raccolta gestita.

La raccolta gestita su GKE viene sottoposta ad upgrade automatico quando vengono rilasciate nuove versioni dei componenti in cluster.

La raccolta gestita su GKE utilizza le autorizzazioni concesse all'account di servizio Compute Engine predefinito. Se hai un criterio che modifica le autorizzazioni standard dell'account di servizio del nodo predefinito, potresti dover aggiungere il ruolo Monitoring Metric Writer per continuare.

Attivare manualmente la raccolta gestita

Se esegui l'operazione in un ambiente GKE che non attiva la raccolta gestita per impostazione predefinita, puoi attivarla utilizzando quanto segue:

• La dashboard Cluster GKE in Cloud Monitoring.
• La pagina Kubernetes Engine nella console Google Cloud.
• Google Cloud CLI. Per utilizzare gcloud CLI, devi eseguire GKE 1.21.4-gke.300 o versioni successive.

• Terraform per Google Kubernetes Engine. Per utilizzare Terraform per abilitare Managed Service per Prometheus, devi eseguire GKE versione 1.21.4-gke.300 o successive.

gcloud config set project PROJECT_ID

gcloud container clusters create CLUSTER_NAME --zone ZONE --enable-managed-prometheus

Disattivare la raccolta gestita

Se vuoi disattivare la raccolta gestita nei tuoi cluster, puoi utilizzare uno dei seguenti metodi:

gcloud config set project PROJECT_ID

gcloud container clusters create CLUSTER_NAME --zone ZONE --no-enable-managed-prometheus

Abilita la raccolta gestita: Kubernetes non GKE

Se esegui l'operazione in un ambiente non GKE, puoi attivare la raccolta gestita utilizzando quanto segue:

• L'interfaccia a riga di comando kubectl.

• La soluzione in bundle inclusa nei deployment di GKE Enterprise che eseguono la versione 1.12 o successive.

kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/prometheus-engine/v0.13.0/manifests/setup.yaml

kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/prometheus-engine/v0.13.0/manifests/operator.yaml

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 per l'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

Configurare una risorsa PodMonitoring

Per importare i dati delle metriche emessi dall'applicazione di esempio, Managed Service per Prometheus utilizza lo scraping del target. Lo scraping del target e l'importazione delle metriche sono configurati utilizzando le risorse personalizzate di Kubernetes. Il servizio gestito utilizza le risorse personalizzate (RP) di PodMonitoring.

Un'entità di controllo dei pod esegue lo scraping dei target solo nello spazio dei nomi in cui è dipiattaforma. Per eseguire lo scraping dei target in più spazi dei nomi, esegui il deployment della stessa risorsa personalizzata PodMonitoring in ogni spazio dei nomi. Puoi verificare che la risorsa PodMonitoring sia installata nello spazio dei nomi previsto eseguendo kubectl get podmonitoring -A.

Per la documentazione di riferimento su tutte le risorse gestite di Managed Service per Prometheus, consulta la documentazione di riferimento di prometheus-engine/doc/api.

Il seguente manifest definisce una risorsa PodMonitoring, prom-example, nello spazio dei nomi NAMESPACE_NAME. La risorsa utilizza un selettore di etichette Kubernetes per trovare tutti i pod nello spazio dei nomi che hanno l'etichetta app.kubernetes.io/name con il valore prom-example. I pod corrispondenti vengono sottoposti a scraping su una porta denominata metrics ogni 30 secondi sul percorso HTTP /metrics.

apiVersion: monitoring.googleapis.com/v1
kind: PodMonitoring
metadata:
  name: prom-example
spec:
  selector:
    matchLabels:
      app.kubernetes.io/name: prom-example
  endpoints:
  - port: metrics
    interval: 30s

Per applicare questa risorsa, esegui il seguente comando:

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

Il tuo collector gestito ora esegue lo scraping dei pod corrispondenti. Puoi visualizzare lo stato del target di scansione attivando la funzionalità di stato del target.

Per configurare la raccolta orizzontale che si applica a un intervallo di pod in tutti gli spazi dei nomi, utilizza la risorsa ClusterPodMonitoring. La risorsa ClusterPodMonitoring fornisce la stessa interfaccia della risorsa PodMonitoring, ma non limita i pod rilevati a un determinato spazio dei nomi.

Se esegui GKE, puoi procedere nel seguente modo:

• Per eseguire query sulle metriche importate dall'applicazione di esempio utilizzando PromQL in Cloud Monitoring, consulta Eseguire query utilizzando Cloud Monitoring.
• Per eseguire query sulle metriche importate dall'applicazione di esempio utilizzando Grafana, consulta Eseguire query utilizzando Grafana o qualsiasi consumatore dell'API Prometheus.
• Per informazioni su come filtrare le metriche esportate e adattare le risorse dell'operatore promozionale, consulta Argomenti aggiuntivi per la raccolta gestita.

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

Quando viene eseguito su GKE, il server Prometheus di raccolta recupera automaticamente le credenziali dall'ambiente in base all'account di servizio del nodo. Nei cluster Kubernetes non GKE, le credenziali devono essere fornite esplicitamente tramite la risorsa OperatorConfig nello spazio dei nomi gmp-public.

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
   

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 gmp-public create secret generic gmp-test-sa \
     --from-file=key.json=gmp-test-sa-key.json
   

6. Apri la risorsa OperatorConfig per la modifica:

   kubectl -n gmp-public edit operatorconfig config
   

   1. Aggiungi il testo in grassetto alla risorsa:

      apiVersion: monitoring.googleapis.com/v1
      kind: OperatorConfig
      metadata:
        namespace: gmp-public
        name: config
      collection:
        credentials:
          name: gmp-test-sa
          key: key.json
      

      Assicurati inoltre di aggiungere queste credenziali alla sezione rules in modo che la valutazione delle regole gestite funzioni.

   2. Salva il file e chiudi l'editor. Una volta applicata la modifica, i pod vengono ricreati e iniziano l'autenticazione al backend metrico con l'account di servizio specificato.

   Argomenti aggiuntivi per la raccolta gestita

   Questa sezione descrive come:

   • Attiva la funzionalità di stato del target per semplificare il debug.
   • Configura lo scraping del target utilizzando Terraform.
   • Filtra i dati esportati nel servizio gestito.
   • Esegui lo scraping delle metriche Kubelet e cAdvisor.
   • Converti le risorse prom-operator esistenti per utilizzarle con il servizio gestito.
   • Esegui la raccolta gestita al di fuori di GKE.

   Attivazione della funzionalità di stato del target

   Managed Service per Prometheus fornisce un modo per verificare se i tuoi target vengono rilevati e sottoposti a scraping correttamente dai raccoglitori. Questo report sullo stato del target è pensato come uno strumento per il debug di problemi acuti. Ti consigliamo vivamente di attivare questa funzionalità solo per esaminare i problemi immediati. Se lasci attivo il reporting sullo stato del target in cluster di grandi dimensioni, l'operatore potrebbe esaurire la memoria e causare un arresto anomalo.

   Puoi controllare lo stato dei target nelle risorse PodMonitoring o ClusterPodMonitoring impostando il valore features.targetStatus.enabled nella risorsa OperatorConfig su true, come mostrato di seguito:

       apiVersion: monitoring.googleapis.com/v1
       kind: OperatorConfig
       metadata:
         namespace: gmp-public
         name: config
       features:
         targetStatus:
           enabled: true
   

   Dopo alcuni secondi, il campo Status.Endpoint Statuses viene visualizzato in ogni risorsa PodMonitoring o ClusterPodMonitoring valida, se configurata.

   Se hai una risorsa PodMonitoring con il nome prom-example nello spazio dei nomi NAMESPACE_NAME, puoi verificarne lo stato eseguendo il seguente comando:

   kubectl -n NAMESPACE_NAME describe podmonitorings/prom-example
   

   L'output è il seguente:

   API Version:  monitoring.googleapis.com/v1
   Kind:         PodMonitoring
   ...
   Status:
     Conditions:
       ...
       Status:                True
       Type:                  ConfigurationCreateSuccess
     Endpoint Statuses:
       Active Targets:       3
       Collectors Fraction:  1
       Last Update Time:     2023-08-02T12:24:26Z
       Name:                 PodMonitoring/custom/prom-example/metrics
       Sample Groups:
         Count:  3
         Sample Targets:
           Health:  up
           Labels:
             Cluster:                     CLUSTER_NAME
             Container:                   prom-example
             Instance:                    prom-example-589ddf7f7f-hcnpt:metrics
             Job:                         prom-example
             Location:                    REGION
             Namespace:                   NAMESPACE_NAME
             Pod:                         prom-example-589ddf7f7f-hcnpt
             project_id:                  PROJECT_ID
           Last Scrape Duration Seconds:  0.020206416
           Health:                        up
           Labels:
             ...
           Last Scrape Duration Seconds:  0.054189485
           Health:                        up
           Labels:
             ...
           Last Scrape Duration Seconds:  0.006224887
   

   L'output include i seguenti campi di stato:

   • Status.Conditions.Status è true quando Managed Service per Prometheus conferma ed elabora PodMonitoring o ClusterPodMonitoring.
   • Status.Endpoint Statuses.Active Targets mostra il numero di target di scansione che Managed Service per Prometheus conteggia in tutti i raccoglitori per questa risorsa PodMonitoring. Nell'applicazione di esempio, il deployment prom-example ha tre repliche con un singolo target metrico, quindi il valore è 3. Se sono presenti target non funzionanti, viene visualizzato il campo Status.Endpoint Statuses.Unhealthy Targets.
   • Status.Endpoint Statuses.Collectors Fraction mostra un valore 1 (ovvero il 100%) se tutti i raccoglitori gestiti sono raggiungibili da Managed Service per Prometheus.
   • Status.Endpoint Statuses.Last Update Time mostra l'ora dell'ultimo aggiornamento. Quando la data e l'ora dell'ultimo aggiornamento sono molto più lunghe dell'intervallo di scansione preferito, la differenza potrebbe indicare problemi con il target o con il cluster.
   • Il campo Status.Endpoint Statuses.Sample Groups mostra i target di esempio raggruppati in base alle etichette target comuni iniettate dal collector. Questo valore è utile per il debugging delle situazioni in cui i target non vengono rilevati. Se tutti i target sono attivi e vengono raccolti, il valore previsto per il campo Health è up e il valore per il campo Last Scrape Duration Seconds è la durata consueta per un target tipico.

   Per ulteriori informazioni su questi campi, consulta il documento dell'API Managed Service per Prometheus.

   Qualsiasi delle seguenti condizioni potrebbe indicare un problema con la configurazione:

   • Nella risorsa PodMonitoring non è presente il campo Status.Endpoint Statuses.
   • Il valore del campo Last Scrape Duration Seconds è troppo vecchio.
   • Non vedi abbastanza target.
   • Il valore del campo Health indica che la destinazione è down.

   Per ulteriori informazioni sul debug dei problemi di rilevamento dei target, consulta la sezione Problemi relativi all'importazione nella documentazione sulla risoluzione dei problemi.

   Configurazione di un endpoint di scansione autorizzato

   Se la destinazione dello scraping richiede l'autorizzazione, puoi configurare il raccoglitore in modo che utilizzi il tipo di autorizzazione corretto e fornisca eventuali secret pertinenti.

   Google Cloud Managed Service per Prometheus supporta i seguenti tipi di autorizzazione:

   • mTLS
   • BasicAuth
   • Intestazione di autorizzazione HTTP
   • OAuth 2

   mTLS

   mTLS viene comunemente configurato in ambienti zero trust, come il mesh di servizi Istio o Cloud Service Mesh.

   Per abilitare lo scraping degli endpoint protetti tramite mTLS, imposta il campo Spec.Endpoints[].Scheme nella risorsa PodMonitoring su https. Anche se non è consigliato, puoi impostare il campo Spec.Endpoints[].insecureSkipVerify nella risorsa PodMonitoring su true per saltare la verifica dell'autorità di certificazione. In alternativa, puoi configurare Managed Service per Prometheus in modo da caricare certificati e chiavi dalle risorse segrete.

   Ad esempio, la seguente risorsa Secret contiene le chiavi per i certificati del client (cert), della chiave privata (key) e dell'autorità di certificazione (ca):

   kind: Secret
   metadata:
     name: secret-example
   stringData:
     cert: ********
     key: ********
     ca: ********
   

   Concedi al raccoglitore di Managed Service per Prometheus l'autorizzazione per accedere alla risorsa secret:

   apiVersion: rbac.authorization.k8s.io/v1
   kind: Role
   metadata:
     name: secret-example-read
   rules:
   - resources:
     - secrets
     apiGroups: [""]
     verbs: ["get", "list", "watch"]
     resourceNames: ["secret-example"]
   ---
   apiVersion: rbac.authorization.k8s.io/v1
   kind: RoleBinding
   metadata:
     name: gmp-system:collector:secret-example-read
     namespace: default
   roleRef:
     name: secret-example-read
     kind: Role
     apiGroup: rbac.authorization.k8s.io
   subjects:
   - name: collector
     namespace: gmp-system
     kind: ServiceAccount
   

   Nei cluster GKE Autopilot, il codice è simile al seguente:

   apiVersion: rbac.authorization.k8s.io/v1
   kind: Role
   metadata:
     name: secret-example-read
   rules:
   - resources:
     - secrets
     apiGroups: [""]
     verbs: ["get", "list", "watch"]
     resourceNames: ["secret-example"]
   ---
   apiVersion: rbac.authorization.k8s.io/v1
   kind: RoleBinding
   metadata:
     name: gmp-system:collector:secret-example-read
     namespace: default
   roleRef:
     name: secret-example-read
     kind: Role
     apiGroup: rbac.authorization.k8s.io
   subjects:
   - name: collector
     namespace: gke-gmp-system
     kind: ServiceAccount
   

   Per configurare una risorsa PodMonitoring che utilizza la risorsa Secret precedente, modifica la risorsa aggiungendo una sezione scheme e tls:

   apiVersion: monitoring.googleapis.com/v1
   kind: PodMonitoring
   metadata:
     name: prom-example
   spec:
     selector:
       matchLabels:
         app.kubernetes.io/name: prom-example
     endpoints:
     - port: metrics
       interval: 30s
       scheme: https
       tls:
         ca:
           secret:
             name: secret-example
             key: ca
         cert:
           secret:
             name: secret-example
             key: cert
         key:
           secret:
             name: secret-example
             key: key
   

   Per la documentazione di riferimento su tutte le opzioni mTLS di Managed Service per Prometheus, consulta la documentazione di riferimento dell'API.

   BasicAuth

   Per abilitare lo scraping degli endpoint protetti utilizzando l'autenticazione di base, imposta il campo Spec.Endpoints[].BasicAuth nella risorsa PodMonitoring con il tuo nome utente e la tua password. Per altri tipi di intestazioni di autorizzazione HTTP, consulta Intestazione di autorizzazione HTTP.

   Ad esempio, la seguente risorsa Secret contiene una chiave per archiviare la password:

   kind: Secret
   metadata:
     name: secret-example
   stringData:
     password: ********
   

   Concedi al raccoglitore di Managed Service per Prometheus l'autorizzazione per accedere alla risorsa secret:

   apiVersion: rbac.authorization.k8s.io/v1
   kind: Role
   metadata:
     name: secret-example-read
   rules:
   - resources:
     - secrets
     apiGroups: [""]
     verbs: ["get", "list", "watch"]
     resourceNames: ["secret-example"]
   ---
   apiVersion: rbac.authorization.k8s.io/v1
   kind: RoleBinding
   metadata:
     name: gmp-system:collector:secret-example-read
     namespace: default
   roleRef:
     name: secret-example-read
     kind: Role
     apiGroup: rbac.authorization.k8s.io
   subjects:
   - name: collector
     namespace: gmp-system
     kind: ServiceAccount
   

   Nei cluster GKE Autopilot, il codice è simile al seguente:

   apiVersion: rbac.authorization.k8s.io/v1
   kind: Role
   metadata:
     name: secret-example-read
   rules:
   - resources:
     - secrets
     apiGroups: [""]
     verbs: ["get", "list", "watch"]
     resourceNames: ["secret-example"]
   ---
   apiVersion: rbac.authorization.k8s.io/v1
   kind: RoleBinding
   metadata:
     name: gmp-system:collector:secret-example-read
     namespace: default
   roleRef:
     name: secret-example-read
     kind: Role
     apiGroup: rbac.authorization.k8s.io
   subjects:
   - name: collector
     namespace: gke-gmp-system
     kind: ServiceAccount
   

   Per configurare una risorsa PodMonitoring che utilizzi la risorsa Secret precedente e un nome utente foo, modifica la risorsa aggiungendo una sezione basicAuth:

   apiVersion: monitoring.googleapis.com/v1
   kind: PodMonitoring
   metadata:
     name: prom-example
   spec:
     selector:
       matchLabels:
         app.kubernetes.io/name: prom-example
     endpoints:
     - port: metrics
       interval: 30s
       basicAuth:
         username: foo
         password:
           secret:
             name: secret-example
             key: password
   

   Per la documentazione di riferimento su tutte le opzioni di autenticazione di base di Managed Service per Prometheus, consulta la documentazione di riferimento dell'API.

   Intestazione di autorizzazione HTTP

   Per abilitare lo scraping degli endpoint protetti utilizzando le intestazioni di autorizzazione HTTP, imposta il campo Spec.Endpoints[].Authorization nella risorsa PodMonitoring con il tipo e le credenziali. Per gli endpoint BasicAuth, utilizza la configurazione BasicAuth.

   Ad esempio, la seguente risorsa Secret contiene una chiave per memorizzare le credenziali:

   kind: Secret
   metadata:
     name: secret-example
   stringData:
     credentials: ********
   

   Concedi al raccoglitore di Managed Service per Prometheus l'autorizzazione per accedere alla risorsa secret:

   apiVersion: rbac.authorization.k8s.io/v1
   kind: Role
   metadata:
     name: secret-example-read
   rules:
   - resources:
     - secrets
     apiGroups: [""]
     verbs: ["get", "list", "watch"]
     resourceNames: ["secret-example"]
   ---
   apiVersion: rbac.authorization.k8s.io/v1
   kind: RoleBinding
   metadata:
     name: gmp-system:collector:secret-example-read
     namespace: default
   roleRef:
     name: secret-example-read
     kind: Role
     apiGroup: rbac.authorization.k8s.io
   subjects:
   - name: collector
     namespace: gmp-system
     kind: ServiceAccount
   

   Nei cluster GKE Autopilot, il codice è simile al seguente:

   apiVersion: rbac.authorization.k8s.io/v1
   kind: Role
   metadata:
     name: secret-example-read
   rules:
   - resources:
     - secrets
     apiGroups: [""]
     verbs: ["get", "list", "watch"]
     resourceNames: ["secret-example"]
   ---
   apiVersion: rbac.authorization.k8s.io/v1
   kind: RoleBinding
   metadata:
     name: gmp-system:collector:secret-example-read
     namespace: default
   roleRef:
     name: secret-example-read
     kind: Role
     apiGroup: rbac.authorization.k8s.io
   subjects:
   - name: collector
     namespace: gke-gmp-system
     kind: ServiceAccount
   

   Per configurare una risorsa PodMonitoring che utilizzi la risorsa Secret precedente e un tipo di Bearer, modifica la risorsa aggiungendo una sezione authorization:

   apiVersion: monitoring.googleapis.com/v1
   kind: PodMonitoring
   metadata:
     name: prom-example
   spec:
     selector:
       matchLabels:
         app.kubernetes.io/name: prom-example
     endpoints:
     - port: metrics
       interval: 30s
       authorization:
         type: Bearer
         credentials:
           secret:
             name: secret-example
             key: credentials
   

   Per la documentazione di riferimento su tutte le opzioni dell'intestazione di autorizzazione HTTP di Managed Service per Prometheus, consulta la documentazione di riferimento dell'API.

   OAuth 2

   Per abilitare lo scraping degli endpoint protetti tramite OAuth 2, devi impostare il campo Spec.Endpoints[].OAuth2 nella risorsa PodMonitoring.

   Ad esempio, la seguente risorsa Secret contiene una chiave per archiviare il segreto del client:

   kind: Secret
   metadata:
     name: secret-example
   stringData:
     clientSecret: ********
   

   Concedi al raccoglitore di Managed Service per Prometheus l'autorizzazione per accedere alla risorsa secret:

   apiVersion: rbac.authorization.k8s.io/v1
   kind: Role
   metadata:
     name: secret-example-read
   rules:
   - resources:
     - secrets
     apiGroups: [""]
     verbs: ["get", "list", "watch"]
     resourceNames: ["secret-example"]
   ---
   apiVersion: rbac.authorization.k8s.io/v1
   kind: RoleBinding
   metadata:
     name: gmp-system:collector:secret-example-read
     namespace: default
   roleRef:
     name: secret-example-read
     kind: Role
     apiGroup: rbac.authorization.k8s.io
   subjects:
   - name: collector
     namespace: gmp-system
     kind: ServiceAccount
   

   Nei cluster GKE Autopilot, il codice è simile al seguente:

   apiVersion: rbac.authorization.k8s.io/v1
   kind: Role
   metadata:
     name: secret-example-read
   rules:
   - resources:
     - secrets
     apiGroups: [""]
     verbs: ["get", "list", "watch"]
     resourceNames: ["secret-example"]
   ---
   apiVersion: rbac.authorization.k8s.io/v1
   kind: RoleBinding
   metadata:
     name: gmp-system:collector:secret-example-read
     namespace: default
   roleRef:
     name: secret-example-read
     kind: Role
     apiGroup: rbac.authorization.k8s.io
   subjects:
   - name: collector
     namespace: gke-gmp-system
     kind: ServiceAccount
   

   Per configurare una risorsa PodMonitoring che utilizzi la risorsa Secret precedente con un ID client foo e un URL token example.com/token, modifica la risorsa per aggiungere una sezione oauth2:

   apiVersion: monitoring.googleapis.com/v1
   kind: PodMonitoring
   metadata:
     name: prom-example
   spec:
     selector:
       matchLabels:
         app.kubernetes.io/name: prom-example
     endpoints:
     - port: metrics
       interval: 30s
       oauth2:
         clientID: foo
         clientSecret:
           secret:
             name: secret-example
             key: password
         tokenURL: example.com/token
   

   Per la documentazione di riferimento su tutte le opzioni OAuth 2 di Managed Service per Prometheus, consulta la documentazione di riferimento dell'API.

   Configurazione dello scraping dei target utilizzando Terraform

   Puoi automatizzare la creazione e la gestione delle risorse PodMonitoring e ClusterPodMonitoring utilizzando il kubernetes_manifest tipo di risorsa Terraform o il kubectl_manifest tipo di risorsa Terraform, entrambi consente di specificare risorse personalizzate arbitrarie.

   Per informazioni generali sull'utilizzo di Google Cloud con Terraform, consulta Terraform con Google Cloud.

   Filtrare le metriche esportate

   Se raccogli molti dati, ti consigliamo di impedire l'invio di alcune serie temporali a Managed Service per Prometheus per ridurre i costi. Puoi farlo utilizzando le regole di rinominazione di Prometheus con un'azione keep per una lista consentita o un'azione drop per una lista vietata. Per la raccolta gestita, questa regola va nella sezione metricRelabeling della risorsa PodMonitoring o ClusterPodMonitoring.

   Ad esempio, la seguente regola di rinominazione delle metriche escluderà tutte le metriche che iniziano con foo_bar_, foo_baz_ o foo_qux_:

     metricRelabeling:
     - action: drop
       regex: foo_(bar|baz|qux)_.+
       sourceLabels: [__name__]
   

   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.
   • Tasso 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 ulteriori informazioni sulla pagina Gestione delle metriche, consulta Visualizzare e gestire l'utilizzo delle metriche.

   Per ulteriori suggerimenti su come ridurre i costi, consulta Controllo dei costi e attribuzione.

   Scraping delle metriche Kubelet e cAdvisor

   Kubelet espone le metriche su se stesso, nonché le metriche di cAdvisor sui contenuti in esecuzione sul suo nodo. Puoi configurare la raccolta gestita per eseguire lo scraping delle metriche di Kubelet e cAdvisor modificando la risorsa OperatorConfig. Per le istruzioni, consulta la documentazione dell'esportatore per Kubelet e cAdvisor.

   Converti le risorse prometheus-operator esistenti

   In genere, puoi convertire le risorse prometheus-operator esistenti nelle risorse PodMonitoring e ClusterPodMonitoring della raccolta gestita di Managed Service per Prometheus.

   Ad esempio, la risorsa ServiceMonitor definisce il monitoraggio di un insieme di servizi. La risorsa PodMonitoring fornisce un sottoinsieme degli annunci della risorsa ServiceMonitor. Puoi convertire un'istanza di risorsa di controllo servizio in un'istanza di risorsa di monitoraggio dei pod mappando i campi come descritto nella tabella seguente:

   monitoring.coreos.com/v1 ServiceMonitor	Compatibilità	monitoring.googleapis.com/v1 PodMonitoring
   .ServiceMonitorSpec.Selector	Identico	.PodMonitoringSpec.Selector
   .ServiceMonitorSpec.Endpoints[]	.TargetPort corrisponde a .Port .Path: compatible .Interval: compatible .Timeout: compatible	.PodMonitoringSpec.Endpoints[]
   .ServiceMonitorSpec.TargetLabels	PodMonitor deve specificare: .FromPod[].From etichetta pod .FromPod[].To etichetta target	.PodMonitoringSpec.TargetLabels

   Di seguito è riportato un esempio di RP ServiceMonitor. I contenuti in grassetto vengono sostituiti durante la conversione, mentre quelli in corsivo vengono mappati direttamente:

   apiVersion: monitoring.coreos.com/v1
   kind: ServiceMonitor
   metadata:
     name: example-app
   spec:
     selector:
       matchLabels:
         app: example-app
     endpoints:
     - targetPort: web
       path: /stats
       interval: 30s
     targetLabels:
     - foo
   

   Di seguito è riportata la risorsa di controllo PodMonitoring analoga, supponendo che il servizio e i relativi pod siano etichettati con app=example-app. Se questa ipotesi non si applica, devi utilizzare i selettori di etichetta della risorsa Service di base.

   I contenuti in grassetto sono stati sostituiti nella conversione:

   apiVersion: monitoring.googleapis.com/v1
   kind: PodMonitoring
   metadata:
     name: example-app
   spec:
     selector:
       matchLabels:
         app: example-app
     endpoints:
     - port: web
       path: /stats
       interval: 30s
     targetLabels:
       fromPod:
       - from: foo # pod label from example-app Service pods.
         to: foo
   

   Puoi sempre continuare a utilizzare le risorse prometheus-operator esistenti e le configurazioni di deployment utilizzando i raccoglitori di cui è stato eseguito il deployment autonomo anziché i raccoglitori gestiti. Puoi eseguire query sulle metriche inviate da entrambi i tipi di raccoglitori, quindi potresti utilizzare i raccoglitori con deployment automatico per i deployment Prometheus esistenti e i raccoglitori gestiti per i nuovi deployment Prometheus.

   Etichette riservate

   Managed Service per Prometheus aggiunge automaticamente le seguenti etichette a tutte le metriche raccolte. Queste etichette vengono utilizzate per identificare in modo univoco una risorsa in Monarch:

   • project_id: l'identificatore del progetto Google Cloud associato alla metrica.
   • 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.
   • cluster: il nome del cluster Kubernetes associato alla metrica.
   • namespace: il nome dello spazio dei nomi Kubernetes associato alla metrica.
   • job: l'etichetta del job del target Prometheus, se nota; potrebbe essere vuota per i risultati della valutazione delle regole.
   • instance: l'etichetta dell'istanza del target Prometheus, se nota; potrebbe essere vuota per i risultati della valutazione delle regole.

   Sebbene non sia consigliato quando viene eseguito su Google Kubernetes Engine, puoi sostituire le etichette project_id, location e cluster aggiungendole come args alla risorsa Deployment all'interno di operator.yaml. Se utilizzi etichette riservate come etichette delle metriche, Managed Service per Prometheus le rinomina automaticamente aggiungendo il prefisso exported_. Questo comportamento corrisponde al modo in cui Prometheus a monte gestisce i conflitti con le etichette riservate.

   Configurazioni di compressione

   Se hai molte risorse PodMonitoring, potresti esaurire lo spazio ConfigMap. Per risolvere il problema, attiva la compressione gzip nella risorsa OperatorConfig:

     apiVersion: monitoring.googleapis.com/v1
     kind: OperatorConfig
     metadata:
       namespace: gmp-public
       name: config
     features:
       config:
         compression: gzip
   

   Abilita la scalabilità automatica del pod verticale (VPA) per la raccolta gestita

   Se riscontri errori di OOM (Out of Memory) per i pod di raccolta nel tuo cluster o se le richieste e i limiti di risorse predefiniti per i collector altrimenti non soddisfano le tue esigenze, puoi utilizzare la scalabilità automatica pod verticale per allocare dinamicamente le risorse.

   Quando imposti il campo scaling.vpa.enabled: true nella risorsa OperatorConfig, l'operatore esegue il deployment di un manifest VerticalPodAutoscaling nel cluster che consente di impostare automaticamente le richieste e i limiti delle risorse dei pod di raccolta in base all'utilizzo.

   Per abilitare la VPA per i pod di raccolta in Managed Service per Prometheus, esegui il seguente comando:

   kubectl -n gmp-public patch operatorconfig/config -p '{"scaling":{"vpa":{"enabled":true}}}' --type=merge
   

   Se il comando viene completato correttamente, l'operatore configura la scalabilità automatica dei pod verticali per i pod di raccolta. Gli errori di memoria insufficiente comportano un aumento immediato dei limiti delle risorse. Se non si verificano errori OOM, in genere il primo aggiustamento delle richieste e dei limiti di risorse dei pod di raccolta avviene entro 24 ore.

   Quando provi ad attivare la VPA, potresti ricevere questo errore:

   vertical pod autoscaling is not available - install vpa support and restart the operator

   Per risolvere questo errore, devi prima attivare la scalabilità automatica dei pod verticali a livello di cluster:

   1. Vai alla pagina Kubernetes Engine - Cluster nella console Google Cloud.

      Nella console Google Cloud, vai alla pagina Cluster Kubernetes:

      Vai a Cluster Kubernetes

      Se utilizzi la barra di ricerca per trovare questa pagina, seleziona il risultato con il sottotitolo Kubernetes Engine.

   2. Seleziona il cluster da modificare.

   3. Nella sezione Automazione, modifica il valore dell'opzione Scalabilità automatica pod verticale.

   4. Seleziona la casella di controllo Abilita scalabilità automatica dei pod verticali e poi fai clic su Salva modifiche. Questa modifica riavvia il cluster. L'operatore si riavvia nell'ambito di questa procedura.

   5. Riprova con il seguente comando: kubectl -n gmp-public patch operatorconfig/config -p '{"scaling":{"vpa":{"enabled":true}}}' --type=merge per attivare VPA per Managed Service per Prometheus.

   Per verificare che la risorsa OperatorConfig sia stata modificata correttamente, apri la utilizzando il comando kubectl -n gmp-public edit operatorconfig config. In caso di esito positivo, OperatorConfig include la seguente sezione in grassetto:

   apiVersion: monitoring.googleapis.com/v1
   kind: OperatorConfig
   metadata:
     namespace: gmp-public
     name: config
   scaling:
     vpa:
       enabled: true
   

   La scalabilità automatica dei pod verticali funziona al meglio quando importi numeri costanti di campioni, suddivisi equamente tra i nodi. Se il carico delle metriche è irregolare o presenta picchi o se il carico delle metriche varia notevolmente tra i nodi, il VPA potrebbe non essere una soluzione efficace.

   Per ulteriori informazioni, consulta la sezione sulla scalabilità automatica pod verticale in GKE.

   Smontaggio

   Per disattivare la raccolta gestita di cui è stato eseguito il deployment utilizzando gcloud o l'interfaccia utente GKE, puoi procedere in uno dei seguenti modi:

   • Esegui questo comando:

     gcloud container clusters update CLUSTER_NAME --disable-managed-prometheus
     

   • Utilizza l'interfaccia utente di GKE:

     1. Seleziona Kubernetes Engine nella console Google Cloud, quindi seleziona Cluster.

     2. Individua il cluster per cui vuoi disattivare la raccolta gestita e fai clic sul nome.

     3. Nella scheda Dettagli, scorri verso il basso fino a Funzionalità e imposta lo stato su Disattivato utilizzando il pulsante di modifica.

   Per disattivare la raccolta gestita di cui è stato eseguito il deployment utilizzando Terraform, specifica enabled = false nella sezione managed_prometheus della risorsa google_container_cluster.

   Per disattivare la raccolta gestita di cui è stato eseguito il deployment utilizzando kubectl, esegui il seguente comando:

   kubectl delete -f https://raw.githubusercontent.com/GoogleCloudPlatform/prometheus-engine/v0.13.0/manifests/operator.yaml
   

   La disattivazione della raccolta gestita fa sì che il cluster interrompa l'invio di nuovi dati a Managed Service per Prometheus. Questa azione non elimina i dati delle metriche esistenti già memorizzati nel sistema.

   La disattivazione della raccolta gestita comporta anche l'eliminazione dello spazio dei nomi gmp-public e di tutte le risorse al suo interno, inclusi eventuali esportatori installati in quello spazio dei nomi.

   Esegui la raccolta gestita al di fuori di GKE

   Negli ambienti GKE, puoi eseguire la raccolta gestita senza ulteriore configurazione. In altri ambienti Kubernetes, devi fornire esplicitamente le credenziali, un valore project-id per contenere le metriche, un valore location (regione Google Cloud) in cui verranno memorizzate le metriche e un valore cluster per salvare il nome del cluster in cui è in esecuzione il collettore.

   Poiché gcloud non funziona al di fuori degli ambienti Google Cloud, devi eseguire il deployment utilizzando kubectl. A differenza di gcloud, l'implementazione della raccolta gestita utilizzando kubectl non esegue automaticamente l'upgrade del cluster quando è disponibile una nuova versione. Ricorda di controllare la pagina delle release per verificare la presenza di nuove versioni ed esegui l'upgrade manualmente eseguendo di nuovo i comandi kubectl con la nuova versione.

   Puoi fornire una chiave dell'account di servizio modificando la risorsa OperatorConfig in operator.yaml come descritto in Fornire le credenziali in modo esplicito. Puoi fornire valori project-id, location e cluster aggiungendoli come args alla risorsa di deployment in operator.yaml.

   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 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. Maggiore è la distanza della regione Google Cloud scelta dal tuo deployment, maggiore sarà la latenza di scrittura e più saranno probabili i 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 utilizzare global come posizione.

   Per cluster, ti consigliamo di scegliere il nome del cluster in cui è disegnato l'operatore.

   Se configurato correttamente, OperatorConfig dovrebbe avere il seguente aspetto:

       apiVersion: monitoring.googleapis.com/v1
       kind: OperatorConfig
       metadata:
         namespace: gmp-public
         name: config
       collection:
         credentials:
           name: gmp-test-sa
           key: key.json
       rules:
         credentials:
           name: gmp-test-sa
           key: key.json
   

   La risorsa di deployment dovrebbe avere il seguente aspetto:

   apiVersion: apps/v1
   kind: Deployment
   ...
   spec:
     ...
     template:
       ...
       spec:
         ...
         containers:
         - name: operator
           ...
           args:
           - ...
           - "--project-id=PROJECT_ID"
           - "--cluster=CLUSTER_NAME"
           - "--location=REGION"
   

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

   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 Cloud e potresti dover pagare delle tariffe per il trasferimento dei dati da un altro cloud. Puoi ridurre al minimo questi costi attivando la compressione gzip sulla rete tramite OperatorConfig. Aggiungi il testo in grassetto alla risorsa:

       apiVersion: monitoring.googleapis.com/v1
       kind: OperatorConfig
       metadata:
         namespace: gmp-public
         name: config
       collection:
         compression: gzip
         ...
   

   Ulteriori informazioni sulle risorse personalizzate delle raccolte gestite

   Per la documentazione di riferimento su tutte le risorse personalizzate di Managed Service per Prometheus, consulta la sezione prometheus-engine/doc/api reference.

   Passaggi successivi

   • Utilizza PromQL in Cloud Monitoring per eseguire query sulle metriche Prometheus.
   • Utilizza Grafana per eseguire query sulle metriche Prometheus.
   • Utilizza gli avvisi PromQL in Cloud Monitoring.
   • Configura la valutazione delle regole gestite.
   • Configura gli esportatori di uso comune.