Inizia a utilizzare il raccoglitore OpenTelemetry

Questo documento descrive come configurare il collezionista OpenTelemetry per eseguire lo scraping delle metriche Prometheus standard e segnalarle a Google Cloud Managed Service per Prometheus. Il raccoglitore OpenTelemetry è un agente che puoi eseguire autonomamente e configurare per l'esportazione in Managed Service per Prometheus. La configurazione è simile all'esecuzione di Managed Service per Prometheus con la raccolta con deployment automatico.

Potresti scegliere il raccoglitore OpenTelemetry rispetto alla raccolta con deployment autonomo per i seguenti motivi:

  • OpenTelemetry Collector ti consente di instradare i dati di telemetria su più backend configurando diversi esportatori nella pipeline.
  • Il Collector supporta anche gli indicatori provenienti da metriche, log e tracce, quindi consente di gestire tutti e tre i tipi di indicatori in un unico agente.
  • Il formato di dati di OpenTelemetry indipendente dal fornitore (OpenTelemetry Protocol oOTLP) supporta un solido ecosistema di librerie e componenti del Collector plug-in. Ciò consente una serie di opzioni di personalizzazione per la ricezione, l'elaborazione ed l'esportazione dei dati.

Il compromesso per questi vantaggi è che l'esecuzione di un OpenTelemetry Collector richiede un approccio di deployment e manutenzione autogestito. L'approccio scelto dipenderà dalle tue esigenze specifiche, ma in questo documento offriamo linee guida consigliate per la configurazione del raccoglitore OpenTelemetry utilizzando Managed Service per Prometheus come backend.

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 Google Cloud progetto, procedi nel seguente modo:

      1. Nella Google Cloud console, 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 Google Cloud progetto, 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 Abilita.

  • 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 di 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 Google Cloud progetto:

      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:

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

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 all'account di servizio predefinito di Compute Engine. Per impostazione predefinita, l'account di servizio predefinito dispone delle autorizzazioni necessarie, monitoring.metricWriter e monitoring.viewer. 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.

Configura un account di servizio per Workload Identity Federation for GKE

Se nel tuo cluster Kubernetes non è 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 la federazione delle identità per i carichi di lavoro per GKE, devi concedere all'account di servizio Kubernetes l'autorizzazione all'API Monitoring. Questa sezione descrive quanto segue:

Crea e associa l'account di servizio

Questo passaggio viene visualizzato in diversi punti della documentazione di Managed Service per Prometheus. Se hai già eseguito questo passaggio nell'ambito di un'attività precedente, non devi ripeterlo. Vai a Autorizzare l'account di servizio.

La seguente sequenza di comandi crea l'account di servizio gmp-test-sa e lo associa all'account di servizio Kubernetes predefinito nello spazio dei nomi NAMESPACE_NAME:

gcloud config set project PROJECT_ID \
&&
gcloud iam service-accounts create gmp-test-sa \
&&
gcloud iam service-accounts add-iam-policy-binding \
  --role roles/iam.workloadIdentityUser \
  --member "serviceAccount:PROJECT_ID.svc.id.goog[NAMESPACE_NAME/default]" \
  gmp-test-sa@PROJECT_ID.iam.gserviceaccount.com \
&&
kubectl annotate serviceaccount \
  --namespace NAMESPACE_NAME \
  default \
  iam.gke.io/gcp-service-account=gmp-test-sa@PROJECT_ID.iam.gserviceaccount.com

Se utilizzi uno spazio dei nomi 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 monitoraggio, consulta Controllo dell'accesso.

Il seguente comando assegna all' Google Cloud account di serviziogmp-test-sa i ruoli dell'API Monitoring di cui ha bisogno per scrivere i dati metrici.

Se hai già concesso all' Google Cloud account di servizio 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

Eseguire 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 la verifica della configurazione di Workload Identity Federation for GKE e la guida alla risoluzione dei problemi di Workload Identity Federation for GKE.

Poiché gli errori ortografici e i copia e incolla parziali sono le fonti di errori più comuni durante la configurazione di Workload Identity Federation 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.

Workload Identity Federation for GKE negli ambienti di produzione

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

In un ambiente di produzione, ti consigliamo di utilizzare un approccio più granulare, con un account di servizio per ogni componente, ciascuno con autorizzazioni minime. Per ulteriori informazioni sulla configurazione dei service account per la gestione delle identità dei carichi di lavoro, consulta Utilizzare la federazione delle identità dei carichi di lavoro per GKE.

Configurare il raccoglitore OpenTelemetry

Questa sezione illustra la configurazione e l'utilizzo di OpenTelemetry Collector per eseguire lo scraping delle metriche da un'applicazione di esempio e inviare i dati a Google Cloud Managed Service per Prometheus. Per informazioni dettagliate sulla configurazione, consulta le seguenti sezioni:

Il raccoglitore OpenTelemetry è analogo al programma binario dell'agente Managed Service per Prometheus. La community di OpenTelemetry pubblica regolarmente release che includono codice sorgente, file binari e immagini container.

Puoi eseguire il deployment di questi elementi sulle VM o sui cluster Kubernetes utilizzando le predefinite delle best practice oppure puoi utilizzare il costruttore del raccoltore per creare il tuo raccoltore composto solo dai componenti di cui hai bisogno. Per creare un raccoglitore da utilizzare con Managed Service per Prometheus, sono necessari i seguenti componenti:

  • L'esportatore di Managed Service per Prometheus, che scrive le metriche in Managed Service per Prometheus.
  • Un destinatario per eseguire lo scraping delle metriche. Questo documento presuppone che tu stia utilizzando il ricolettore Prometheus di OpenTelemetry, ma l'esportatore di Managed Service per Prometheus è compatibile con qualsiasi ricevitore delle metriche OpenTelemetry.
  • Processori per raggruppare e eseguire il markup delle metriche in modo da includere identificatori di risorse importanti, a seconda del tuo ambiente.

Questi componenti vengono attivati utilizzando un file di configurazione che viene passato al Collector con il flag --config.

Le sezioni seguenti illustrano come configurare ognuno di questi componenti in modo più dettagliato. Questo documento descrive come eseguire il collector su GKE e altrove.

Configura ed esegui il deployment del raccoglitore

Che tu esegua la raccolta su Google Cloud o in un altro ambiente, puoi comunque configurare il raccoglitore OpenTelemetry per l'esportazione in Managed Service per Prometheus. La differenza maggiore riguarderà il modo in cui configurerai Collector. Negli ambienti nonGoogle Cloud , potrebbe essere necessaria una formattazione aggiuntiva dei dati delle metriche per renderli compatibili con il servizio gestito per Prometheus. Su Google Cloud, tuttavia, gran parte di questa formattazione può essere rilevata automaticamente dal Collector.

Esegui OpenTelemetry Collector su GKE

Puoi copiare la seguente configurazione in un file denominato config.yaml per configurare il collector OpenTelemetry su GKE:

receivers:
  prometheus:
    config:
      scrape_configs:
      - job_name: 'SCRAPE_JOB_NAME'
        kubernetes_sd_configs:
        - role: pod
        relabel_configs:
        - source_labels: [__meta_kubernetes_pod_label_app_kubernetes_io_name]
          action: keep
          regex: prom-example
        - source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_path]
          action: replace
          target_label: __metrics_path__
          regex: (.+)
        - source_labels: [__address__, __meta_kubernetes_pod_annotation_prometheus_io_port]
          action: replace
          regex: (.+):(?:\d+);(\d+)
          replacement: $$1:$$2
          target_label: __address__
        - action: labelmap
          regex: __meta_kubernetes_pod_label_(.+)

processors:
  resourcedetection:
    detectors: [gcp]
    timeout: 10s

  transform:
    # "location", "cluster", "namespace", "job", "instance", and "project_id" are reserved, and
    # metrics containing these labels will be rejected.  Prefix them with exported_ to prevent this.
    metric_statements:
    - context: datapoint
      statements:
      - set(attributes["exported_location"], attributes["location"])
      - delete_key(attributes, "location")
      - set(attributes["exported_cluster"], attributes["cluster"])
      - delete_key(attributes, "cluster")
      - set(attributes["exported_namespace"], attributes["namespace"])
      - delete_key(attributes, "namespace")
      - set(attributes["exported_job"], attributes["job"])
      - delete_key(attributes, "job")
      - set(attributes["exported_instance"], attributes["instance"])
      - delete_key(attributes, "instance")
      - set(attributes["exported_project_id"], attributes["project_id"])
      - delete_key(attributes, "project_id")

  batch:
    # batch metrics before sending to reduce API usage
    send_batch_max_size: 200
    send_batch_size: 200
    timeout: 5s

  memory_limiter:
    # drop metrics if memory usage gets too high
    check_interval: 1s
    limit_percentage: 65
    spike_limit_percentage: 20

# Note that the googlemanagedprometheus exporter block is intentionally blank
exporters:
  googlemanagedprometheus:

service:
  pipelines:
    metrics:
      receivers: [prometheus]
      processors: [batch, memory_limiter, resourcedetection, transform]
      exporters: [googlemanagedprometheus]

La configurazione precedente utilizza il ricevitore Prometheus e l'esportatore Managed Service per Prometheus per eseguire lo scraping degli endpoint delle metriche sui pod Kubernetes ed esportare queste metriche in Managed Service per Prometheus. Gli elaboratori della pipeline formattano e raggruppano i dati.

Per ulteriori dettagli sulle funzionalità di ogni parte di questa configurazione, nonché sulle configurazioni per piattaforme diverse, consulta le sezioni seguenti dettagliate sulle metriche di scraping e sull'aggiunta di processori.

Quando utilizzi una configurazione Prometheus esistente con il ricevitoreprometheus di OpenTelemetry Collector, sostituisci eventuali caratteri del simbolo del dollaro singolo,, con caratteri doppi, , per evitare di attivare la sostituzione variabile di ambiente. Per ulteriori informazioni, consulta Eseguire lo scraping delle metriche Prometheus.

Puoi modificare questa configurazione in base al tuo ambiente, al provider e alle metriche che vuoi estrarre, ma la configurazione di esempio è un punto di partenza consigliato per l'esecuzione su GKE.

Esegui OpenTelemetry Collector all'esterno Google Cloud

L'esecuzione del Collector OpenTelemetry all'esterno Google Cloud, ad esempio on-premise o su altri provider cloud, è simile all'esecuzione del Collector su GKE. Tuttavia, è meno probabile che le metriche che esegui lo scraping includano automaticamente i dati che le formattano al meglio per il servizio gestito per Prometheus. Pertanto, devi prestare particolare attenzione a configurare il raccoglitore in modo che formatti le metriche in modo che siano compatibili con Managed Service per Prometheus.

Puoi inserire la seguente configurazione in un file denominato config.yaml per configurare il Collector OpenTelemetry per il deployment in un cluster Kubernetes non GKE:

receivers:
  prometheus:
    config:
      scrape_configs:
      - job_name: 'SCRAPE_JOB_NAME'
        kubernetes_sd_configs:
        - role: pod
        relabel_configs:
        - source_labels: [__meta_kubernetes_pod_label_app_kubernetes_io_name]
          action: keep
          regex: prom-example
        - source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_path]
          action: replace
          target_label: __metrics_path__
          regex: (.+)
        - source_labels: [__address__, __meta_kubernetes_pod_annotation_prometheus_io_port]
          action: replace
          regex: (.+):(?:\d+);(\d+)
          replacement: $$1:$$2
          target_label: __address__
        - action: labelmap
          regex: __meta_kubernetes_pod_label_(.+)

processors:
  resource:
    attributes:
    - key: "cluster"
      value: "CLUSTER_NAME"
      action: upsert
    - key: "namespace"
      value: "NAMESPACE_NAME"
      action: upsert
    - key: "location"
      value: "REGION"
      action: upsert

  transform:
    # "location", "cluster", "namespace", "job", "instance", and "project_id" are reserved, and
    # metrics containing these labels will be rejected.  Prefix them with exported_ to prevent this.
    metric_statements:
    - context: datapoint
      statements:
      - set(attributes["exported_location"], attributes["location"])
      - delete_key(attributes, "location")
      - set(attributes["exported_cluster"], attributes["cluster"])
      - delete_key(attributes, "cluster")
      - set(attributes["exported_namespace"], attributes["namespace"])
      - delete_key(attributes, "namespace")
      - set(attributes["exported_job"], attributes["job"])
      - delete_key(attributes, "job")
      - set(attributes["exported_instance"], attributes["instance"])
      - delete_key(attributes, "instance")
      - set(attributes["exported_project_id"], attributes["project_id"])
      - delete_key(attributes, "project_id")

  batch:
    # batch metrics before sending to reduce API usage
    send_batch_max_size: 200
    send_batch_size: 200
    timeout: 5s

  memory_limiter:
    # drop metrics if memory usage gets too high
    check_interval: 1s
    limit_percentage: 65
    spike_limit_percentage: 20

exporters:
  googlemanagedprometheus:
    project: "PROJECT_ID"

service:
  pipelines:
    metrics:
      receivers: [prometheus]
      processors: [batch, memory_limiter, resource, transform]
      exporters: [googlemanagedprometheus]

Questa configurazione esegue le seguenti operazioni:

  • Configura una configurazione di scansione del Service Discovery Kubernetes per Prometheus. Per ulteriori informazioni, consulta la sezione Scrape delle metriche Prometheus.
  • Imposta manualmente gli attributi delle risorse cluster, namespace e location. Per ulteriori informazioni sugli attributi delle risorse, incluso il rilevamento delle risorse per Amazon EKS e Azure AKS, consulta Rileva gli attributi delle risorse.
  • Imposta l'opzione project nell'esportatore googlemanagedprometheus. Per ulteriori informazioni sull'esportatore, consulta Configurare l'esportatore googlemanagedprometheus.

Quando utilizzi una configurazione Prometheus esistente con il ricevitoreprometheus di OpenTelemetry Collector, sostituisci eventuali caratteri del simbolo del dollaro singolo,, con caratteri doppi, , per evitare di attivare la sostituzione variabile di ambiente. Per ulteriori informazioni, consulta Eseguire lo scraping delle metriche Prometheus.

Per informazioni sulle best practice per la configurazione del Collector su altri cloud, consulta Amazon EKS o Azure AKS.

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

Crea la configurazione del tuo collector come ConfigMap

Dopo aver creato la configurazione e averla inserita in un file denominato config.yaml, utilizza questo file per creare un ConfigMap Kubernetes in base al file config.yaml. Quando il raccoglitore viene disegnato, monta il ConfigMap e carica il file.

Per creare un ConfigMap denominato otel-config con la tua configurazione, utilizza il seguente comando:

kubectl -n NAMESPACE_NAME create configmap otel-config --from-file config.yaml

Esegui il deployment del raccoglitore

Crea un file denominato collector-deployment.yaml con i seguenti contenuti:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: NAMESPACE_NAME:prometheus-test
rules:
- apiGroups: [""]
  resources:
  - pods
  verbs: ["get", "list", "watch"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: NAMESPACE_NAME:prometheus-test
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: NAMESPACE_NAME:prometheus-test
subjects:
- kind: ServiceAccount
  namespace: NAMESPACE_NAME
  name: default
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: otel-collector
spec:
  replicas: 1
  selector:
    matchLabels:
      app: otel-collector
  template:
    metadata:
      labels:
        app: otel-collector
    spec:
      containers:
      - name: otel-collector
        image: otel/opentelemetry-collector-contrib:0.128.0
        args:
        - --config
        - /etc/otel/config.yaml
        - --feature-gates=exporter.googlemanagedprometheus.intToDouble
        volumeMounts:
        - mountPath: /etc/otel/
          name: otel-config
      volumes:
      - name: otel-config
        configMap:
          name: otel-config

Crea il deployment del Collector nel tuo cluster Kubernetes eseguendo il seguente comando:

kubectl -n NAMESPACE_NAME create -f collector-deployment.yaml

Dopo l'avvio, il pod esegue lo scraping dell'applicazione di esempio e genera report sulle metriche in Managed Service per Prometheus.

Per informazioni sui modi per eseguire query sui dati, consulta Eseguire query utilizzando Cloud Monitoring o Eseguire query utilizzando Grafana.

Fornisci le credenziali in modo esplicito

Quando viene eseguito su GKE, OpenTelemetry Collector recupera automaticamente le credenziali dall'ambiente in base al account di servizio del nodo. Nei cluster Kubernetes non GKE, le credenziali devono essere fornite esplicitamente al Collector OpenTelemetry 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 for 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 di deployment di OpenTelemetry per la modifica:

    kubectl -n NAMESPACE_NAME edit deployment otel-collector

  1. Aggiungi il testo in grassetto alla risorsa:

    apiVersion: apps/v1
kind: Deployment
metadata:
  namespace: NAMESPACE_NAME
  name: otel-collector
spec:
  template
    spec:
      containers:
      - name: otel-collector
        env:
        - name: "GOOGLE_APPLICATION_CREDENTIALS"
          value: "/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 metrico con l'account di servizio specificato.

Estrarre le metriche di Prometheus

Questa sezione e la sezione successiva forniscono ulteriori informazioni sulla personalizzazione per l'utilizzo del Collector OpenTelemetry. Queste informazioni possono essere utili in determinate situazioni, ma non sono necessarie per eseguire l'esempio descritto in Configurare OpenTelemetry Collector.

Se le tue applicazioni espongono già endpoint Prometheus, il Collector OpenTelemetry può eseguire lo scraping di questi endpoint utilizzando lo stesso formato della configurazione di scraping che utilizzeresti con qualsiasi configurazione Prometheus standard. Per farlo, attiva il ricolettore Prometheus nella configurazione del raccoglitore.

Una configurazione del ricevitore Prometheus per i pod Kubernetes potrebbe avere il seguente aspetto:

receivers:
  prometheus:
    config:
      scrape_configs:
      - job_name: 'kubernetes-pods'
        kubernetes_sd_configs:
        - role: pod
        relabel_configs:
        - source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_scrape]
          action: keep
          regex: true
        - source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_path]
          action: replace
          target_label: __metrics_path__
          regex: (.+)
        - source_labels: [__address__, __meta_kubernetes_pod_annotation_prometheus_io_port]
          action: replace
          regex: (.+):(?:\d+);(\d+)
          replacement: $$1:$$2
          target_label: __address__
        - action: labelmap
          regex: __meta_kubernetes_pod_label_(.+)

service:
  pipelines:
    metrics:
      receivers: [prometheus]

Si tratta di una configurazione di scansione basata sul Service Discovery che puoi modificare come necessario per eseguire lo scraping delle tue applicazioni.

Quando utilizzi una configurazione Prometheus esistente con il ricevitoreprometheus di OpenTelemetry Collector, sostituisci eventuali caratteri del simbolo del dollaro singolo,, con caratteri doppi, , per evitare di attivare la sostituzione variabile di ambiente. Questo è particolarmente importante per il valore replacement nella sezione relabel_configs. Ad esempio, se hai la seguente sezione relabel_config:

- source_labels: [__address__, __meta_kubernetes_pod_annotation_prometheus_io_port]
  action: replace
  regex: (.+):(?:\d+);(\d+)
  replacement: $1:$2
  target_label: __address__

Quindi riscrivilo come segue:

- source_labels: [__address__, __meta_kubernetes_pod_annotation_prometheus_io_port]
  action: replace
  regex: (.+):(?:\d+);(\d+)
  replacement: $$1:$$2
  target_label: __address__

Per ulteriori informazioni, consulta la documentazione di OpenTelemetry.

Ti consigliamo vivamente di utilizzare i processori per formattare le metriche. In molti casi, è necessario utilizzare i processori per formattare correttamente le metriche.

Aggiungere processori

I processori OpenTelemetry modificano i dati di telemetria prima che vengano esportati. Puoi utilizzare i seguenti elaboratori per assicurarti che le metriche vengano scritte in un formato compatibile con Managed Service per Prometheus.

Rileva gli attributi delle risorse

L'esportatore Managed Service per Prometheus per OpenTelemetry utilizza la prometheus_target risorsa monitorata per identificare in modo univoco i punti dati delle serie temporali. L'esportatore analizza i campi obbligatori della risorsa monitorata dagli attributi della risorsa nei punti dati della metrica. I campi e gli attributi da cui vengono estratti i valori sono:

  • project_id: rilevato automaticamente dalle credenziali predefinite per le applicazioni,gcp.project.id o project nella configurazione dell'esportatore (vedi Configurazione dell'esportatore)
  • location: location, cloud.availability_zone, cloud.region
  • cluster: cluster, k8s.cluster_name
  • namespace: namespace, k8s.namespace_name
  • job: service.name + service.namespace
  • instance: service.instance.id

La mancata impostazione di questi valori su valori univoci può comportare errori di "serie temporali duplicate" durante l'esportazione in Managed Service per Prometheus. In molti casi, i valori possono essere rilevati automaticamente per queste etichette, ma in alcuni casi potresti doverli mappare autonomamente. Il resto di questa sezione descrive questi scenari.

Il ricevitore Prometheus imposta automaticamente l'attributo service.name in base a job_name nella configurazione dello scraping e l'attributo service.instance.id in base a instance del target di scraping. Il ricevitore imposta anche k8s.namespace.name quando si utilizza role: pod nella configurazione dello scraping.

Se possibile, compila gli altri attributi automaticamente utilizzando il processore di rilevamento delle risorse. Tuttavia, a seconda dell'ambiente, alcuni attributi potrebbero non essere rilevati automaticamente. In questo caso, puoi utilizzare altri elaboratori per inserire manualmente questi valori o analizzarli dalle etichette delle metriche. Le seguenti sezioni illustrano le configurazioni per il rilevamento delle risorse su varie piattaforme.

GKE

Quando esegui OpenTelemetry su GKE, devi attivare il processore di rilevamento delle risorse per compilare le etichette delle risorse. Assicurati che le tue metriche non contengano già le etichette delle risorse riservate. Se questo accade, consulta Evitare collisioni degli attributi delle risorse rinominando gli attributi.

processors:
  resourcedetection:
    detectors: [gcp]
    timeout: 10s

Questa sezione può essere copiata direttamente nel file di configurazione, sostituendo la sezione processors se esiste già.

Amazon EKS

Il rilevatore di risorse EKS non compila automaticamente gli attributi cluster o namespace. Puoi fornire questi valori manualmente utilizzando il processore di risorse, come mostrato nell'esempio seguente:

processors:
  resourcedetection:
    detectors: [eks]
    timeout: 10s

  resource:
    attributes:
    - key: "cluster"
      value: "my-eks-cluster"
      action: upsert
    - key: "namespace"
      value: "my-app"
      action: upsert

Puoi anche convertire questi valori dalle etichette delle metriche utilizzando il groupbyattrs processore (vedi spostare le etichette delle metriche nelle etichette delle risorse di seguito).

Azure AKS

Il rilevatore di risorse AKS non compila automaticamente gli attributi cluster o namespace. Puoi fornire questi valori manualmente utilizzando il processore delle risorse, come mostrato nell'esempio seguente:

processors:
  resourcedetection:
    detectors: [aks]
    timeout: 10s

  resource:
    attributes:
    - key: "cluster"
      value: "my-eks-cluster"
      action: upsert
    - key: "namespace"
      value: "my-app"
      action: upsert

Puoi anche convertire questi valori dalle etichette delle metriche utilizzando il groupbyattrs processore; consulta Spostare le etichette delle metriche nelle etichette delle risorse.

Ambienti on-premise e non cloud

Con gli ambienti on-premise o non cloud, probabilmente non puoi rilevare automaticamente nessuno degli attributi delle risorse necessari. In questo caso, puoi emettere queste etichette nelle metriche e spostarle negli attributi delle risorse (vedi Spostare le etichette delle metriche nelle etichette delle risorse) oppure impostare manualmente tutti gli attributi delle risorse come mostrato nell'esempio seguente:

processors:
  resource:
    attributes:
    - key: "cluster"
      value: "my-on-prem-cluster"
      action: upsert
    - key: "namespace"
      value: "my-app"
      action: upsert
    - key: "location"
      value: "us-east-1"
      action: upsert

L'articolo Creare la configurazione del raccoglitore come ConfigMap descrive come utilizzare la configurazione. Questa sezione presuppone che tu abbia inserito la configurazione in un file chiamato config.yaml.

L'attributo della risorsa project_id può comunque essere impostato automaticamente quando viene eseguito il Raccoglitore con le credenziali predefinite dell'applicazione. Se il tuo Collector non ha accesso alle Credenziali predefinite dell'applicazione, consulta Impostazione project_id.

In alternativa, puoi impostare manualmente gli attributi delle risorse di cui hai bisogno in una variabile di ambiente, OTEL_RESOURCE_ATTRIBUTES, con un elenco separato da virgole di coppie chiave-valore, ad esempio:

export OTEL_RESOURCE_ATTRIBUTES="cluster=my-cluster,namespace=my-app,location=us-east-1"

Quindi, utilizza il processore del rilevatore di risorse env per impostare gli attributi della risorsa:

processors:
  resourcedetection:
    detectors: [env]

Evitare collisioni di attributi delle risorse rinominando gli attributi

Se le metriche contengono già etichette in conflitto con gli attributi delle risorse richiesti (ad esempio location, cluster o namespace), rinominale per evitare la collisione. La convenzione di Prometheus è aggiungere il prefisso exported_ al nome dell'etichetta. Per aggiungere questo prefisso, utilizza il processore delle trasformazioni.

La seguente configurazione processors rinomina eventuali potenziali collisioni e risolve eventuali chiavi in conflitto della metrica:

processors:
  transform:
    # "location", "cluster", "namespace", "job", "instance", and "project_id" are reserved, and
    # metrics containing these labels will be rejected.  Prefix them with exported_ to prevent this.
    metric_statements:
    - context: datapoint
      statements:
      - set(attributes["exported_location"], attributes["location"])
      - delete_key(attributes, "location")
      - set(attributes["exported_cluster"], attributes["cluster"])
      - delete_key(attributes, "cluster")
      - set(attributes["exported_namespace"], attributes["namespace"])
      - delete_key(attributes, "namespace")
      - set(attributes["exported_job"], attributes["job"])
      - delete_key(attributes, "job")
      - set(attributes["exported_instance"], attributes["instance"])
      - delete_key(attributes, "instance")
      - set(attributes["exported_project_id"], attributes["project_id"])
      - delete_key(attributes, "project_id")

Spostare le etichette delle metriche nelle etichette delle risorse

In alcuni casi, le metriche potrebbero riportare intenzionalmente etichette come namespace perché l'esportatore monitora più spazi dei nomi. Ad esempio, quando esegui l'esportatore kube-state-metrics.

In questo scenario, queste etichette possono essere spostate negli attributi della risorsa utilizzando il processore groupbyattrs:

processors:
  groupbyattrs:
    keys:
    - namespace
    - cluster
    - location

Nell'esempio precedente, data una metrica con le etichette namespace, cluster o location, queste etichette verranno convertite negli attributi della risorsa corrispondenti.

Limita le richieste API e l'utilizzo della memoria

Altri due processori, il processore per i batch e il processore per il limitatore di memoria ti consentono di limitare il consumo di risorse del tuo collector.

Elaborazione dei dati in modalità batch

Le richieste batch ti consentono di definire il numero di punti dati da inviare in un'unica richiesta. Tieni presente che Cloud Monitoring ha un limite di 200 serie temporali per richiesta. Attiva l'elaborazione collettiva utilizzando le seguenti impostazioni:

processors:
  batch:
    # batch metrics before sending to reduce API usage
    send_batch_max_size: 200
    send_batch_size: 200
    timeout: 5s

Limitazione della memoria

Ti consigliamo di attivare il processore del limitatore di memoria per evitare che il tuo collector si arresti in modo anomalo in periodi di elevato throughput. Attiva l'elaborazione utilizzando le seguenti impostazioni:

processors:
  memory_limiter:
    # drop metrics if memory usage gets too high
    check_interval: 1s
    limit_percentage: 65
    spike_limit_percentage: 20

Configura l'esportatore googlemanagedprometheus

Per impostazione predefinita, l'utilizzo dell'esportatore googlemanagedprometheus su GKE non richiede alcuna configurazione aggiuntiva. Per molti casi d'uso, devi solo attivarla con un blocco vuoto nella sezione exporters:

exporters:
  googlemanagedprometheus:

Tuttavia, l'esportatore fornisce alcune impostazioni di configurazione facoltative. Le sezioni seguenti descrivono le altre impostazioni di configurazione.

Configurazione di project_id in corso…

Per associare le serie temporali a un Google Cloud progetto, la prometheus_target risorsa monitorata deve avere project_id impostato.

Quando esegui OpenTelemetry su Google Cloud, l'esportatore Managed Service per Prometheus imposta per impostazione predefinita questo valore in base alle credenziali predefinite dell'applicazione che trova. Se non sono disponibili credenziali o se vuoi ignorare il progetto predefinito, hai due opzioni:

  • Imposta project nella configurazione dell'esportatore
  • Aggiungi un attributo della risorsa gcp.project.id alle metriche.

Ti consigliamo vivamente di utilizzare il valore predefinito (non impostato) per project_id anziché impostarlo esplicitamente, se possibile.

Imposta project nella configurazione dell'esportatore

Il seguente estratto di configurazione invia le metriche a Managed Service per Prometheus nel Google Cloud progetto MY_PROJECT:

receivers:
  prometheus:
    config:
    ...

processors:
  resourcedetection:
    detectors: [gcp]
    timeout: 10s

exporters:
  googlemanagedprometheus:
    project: MY_PROJECT

service:
  pipelines:
    metrics:
      receivers: [prometheus]
      processors: [resourcedetection]
      exporters: [googlemanagedprometheus]

L'unica differenza rispetto agli esempi precedenti è la nuova riga project: MY_PROJECT. Questa impostazione è utile se sai che tutte le metriche generate da questo collector devono essere inviate a MY_PROJECT.

Impostare l'attributo della risorsa gcp.project.id

Puoi impostare l'associazione dei progetti in base alle metriche aggiungendo un attributo della risorsa gcp.project.id alle metriche. Imposta il valore dell'attributo sul nome del progetto a cui deve essere associata la metrica.

Ad esempio, se la metrica ha già un'etichetta project, questa può essere trasferita a un attributo della risorsa e rinominata in gcp.project.id utilizzando i processori nella configurazione del Collector, come mostrato nell'esempio seguente:

receivers:
  prometheus:
    config:
    ...

processors:
  resourcedetection:
    detectors: [gcp]
    timeout: 10s

  groupbyattrs:
    keys:
    - project

  resource:
    attributes:
    - key: "gcp.project.id"
      from_attribute: "project"
      action: upsert

exporters:
  googlemanagedprometheus:

service:
  pipelines:
    metrics:
      receivers: [prometheus]
      processors: [resourcedetection, groupbyattrs, resource]
      exporters: [googlemanagedprometheus]

Impostazione delle opzioni del client

L'esportatore googlemanagedprometheus utilizza i client gRPC per Managed Service per Prometheus. Pertanto, sono disponibili impostazioni facoltative per la configurazione del client gRPC:

  • compression: attiva la compressione gzip per le richieste gRPC, utile per minimizzare le commissioni di trasferimento dei dati quando si inviano dati da altri cloud a Managed Service per Prometheus (valori validi: gzip).
  • user_agent: sostituisce la stringa user-agent inviata nelle richieste a Cloud Monitoring. Si applica solo alle metriche. Il valore predefinito è il numero di build e di versione del tuo OpenTelemetry Collector, ad esempio opentelemetry-collector-contrib 0.128.0.
  • endpoint: imposta l'endpoint a cui verranno inviati i dati delle metriche.
  • use_insecure: se true, utilizza gRPC come protocollo di trasporto delle comunicazioni. Ha effetto solo quando il valore endpoint non è "".
  • grpc_pool_size: imposta la dimensione del pool di connessioni nel client gRPC.
  • prefix: configura il prefisso delle metriche inviate a Managed Service per Prometheus. Il valore predefinito è prometheus.googleapis.com. Non modificare questo prefisso, altrimenti le metriche non saranno queryable con PromQL nell'interfaccia utente di Cloud Monitoring.

Nella maggior parte dei casi, non è necessario modificare questi valori rispetto ai valori predefiniti. Tuttavia, puoi modificarli in base a circostanze speciali.

Tutte queste impostazioni sono impostate in un blocco metric nella sezione dell'esportatore googlemanagedprometheus, come mostrato nell'esempio seguente:

receivers:
  prometheus:
    config:
    ...

processors:
  resourcedetection:
    detectors: [gcp]
    timeout: 10s

exporters:
  googlemanagedprometheus:
    metric:
      compression: gzip
      user_agent: opentelemetry-collector-contrib 0.128.0
      endpoint: ""
      use_insecure: false
      grpc_pool_size: 1
      prefix: prometheus.googleapis.com

service:
  pipelines:
    metrics:
      receivers: [prometheus]
      processors: [resourcedetection]
      exporters: [googlemanagedprometheus]

Passaggi successivi