In diesem Dokument wird beschrieben, wie Sie den OpenTelemetry Collector einrichten, um Standard-Prometheus-Messwerte zu erfassen und an Google Cloud Managed Service for Prometheus zu melden. Der OpenTelemetry Collector ist ein Agent, den Sie selbst bereitstellen und so konfigurieren können, dass er nach Managed Service for Prometheus exportiert. Die Einrichtung ähnelt dem Ausführen von Managed Service for Prometheus mit selbst bereitgestellter Sammlung.
Sie können den OpenTelemetry Collector aus folgenden Gründen gegenüber einer selbst bereitgestellten Sammlung auswählen:
- Mit dem OpenTelemetry Collector können Sie Ihre Telemetriedaten an mehrere Back-Ends weiterleiten, indem Sie verschiedene Exporteure in Ihrer Pipeline konfigurieren.
- Der Collector unterstützt auch Signale aus Messwerten, Protokollen und Traces. So können Sie alle drei Signaltypen in einem Agenten verarbeiten.
- Das anbieterunabhängige Datenformat von OpenTelemetry (OpenTelemetry Protocol, OTLP) unterstützt ein umfangreiches Ökosystem von Bibliotheken und Plug-in-Collector-Komponenten. So haben Sie verschiedene Möglichkeiten, Ihre Daten zu empfangen, zu verarbeiten und zu exportieren.
Im Gegenzug zu diesen Vorteilen erfordert die Ausführung eines OpenTelemetry Collectors eine selbstverwaltete Bereitstellung und Wartung. Welchen Ansatz Sie wählen, hängt von Ihren konkreten Bedürfnissen ab, aber in diesem Dokument bieten wir Ihnen empfohlene Richtlinien für die Konfiguration des OpenTelemetry Collector mit Managed Service for Prometheus als Backend.
Hinweise
In diesem Abschnitt wird die Konfiguration beschrieben, die für die in diesem Dokument beschriebenen Aufgaben erforderlich ist.
Projekte und Tools einrichten
Zum Verwenden von Google Cloud Managed Service for Prometheus benötigen Sie folgende Ressourcen:
Ein Google Cloud-Projekt mit aktivierter Cloud Monitoring API.
Wenn Sie kein Google Cloud-Projekt haben, gehen Sie so vor:
Wechseln Sie in der Google Cloud Console zu Neues Projekt:
Geben Sie im Feld Projektname einen Namen für Ihr Projekt ein und klicken Sie dann auf Erstellen.
Wechseln Sie zu Billing (Abrechnung):
Wählen Sie das Projekt aus, das Sie gerade erstellt haben, falls es nicht bereits oben auf der Seite ausgewählt wurde.
Sie werden aufgefordert, ein vorhandenes Zahlungsprofil auszuwählen oder ein neues Zahlungsprofil zu erstellen.
Die Monitoring API ist für neue Projekte standardmäßig aktiviert.
Wenn Sie bereits ein Google Cloud-Projekt haben, muss die Monitoring API aktiviert sein:
Gehen Sie zu APIs & Dienste:
Wählen Sie Ihr Projekt aus.
Klicken Sie auf APIs und Dienste aktivieren.
Suchen Sie nach „Monitoring“.
Klicken Sie in den Suchergebnissen auf "Cloud Monitoring API".
Wenn "API aktiviert" nicht angezeigt wird, klicken Sie auf die Schaltfläche Aktivieren.
Einen Kubernetes-Cluster. Wenn Sie keinen Kubernetes-Cluster haben, folgen Sie der Anleitung in der Kurzanleitung für GKE.
Sie benötigen außerdem die folgenden Befehlszeilentools:
gcloud
kubectl
Die Tools gcloud
und kubectl
sind Teil der Google Cloud CLI. Informationen zur Installation finden Sie unter Komponenten der Google Cloud-Befehlszeile verwalten. Führen Sie den folgenden Befehl aus, um die installierten gloud CLI-Komponenten aufzurufen:
gcloud components list
Konfigurierung Ihrer Umgebung
Führen Sie die folgende Konfiguration aus, um zu vermeiden, dass Sie Ihre Projekt-ID oder den Clusternamen wiederholt eingeben müssen:
Konfigurieren Sie die Befehlszeilentools so:
Konfigurieren Sie die gcloud CLI so, dass sie auf die ID Ihres Google Cloud-Projekts verweist:
gcloud config set project PROJECT_ID
Konfigurieren Sie die
kubectl
-Befehlszeile für die Verwendung Ihres Clusters:kubectl config set-cluster CLUSTER_NAME
Weitere Informationen zu diesen Tools finden Sie hier:
Namespace einrichten
Erstellen Sie den Kubernetes-Namespace NAMESPACE_NAME
für Ressourcen, die Sie als Teil der Beispielanwendung erstellen:
kubectl create ns NAMESPACE_NAME
Anmeldedaten für das Dienstkonto prüfen
Sie können diesen Abschnitt überspringen, wenn in Ihrem Kubernetes-Cluster die Workload Identity Federation for GKE aktiviert ist.
Bei Ausführung in GKE ruft Managed Service for Prometheus automatisch Anmeldedaten aus der Umgebung anhand des Compute Engine-Standarddienstkontos ab. Das Standarddienstkonto hat standardmäßig die erforderlichen Berechtigungen monitoring.metricWriter
und monitoring.viewer
. Wenn Sie Workload Identity Federation for GKE nicht verwenden und zuvor eine dieser Rollen aus dem Standardknotendienstkonto entfernt haben, müssen Sie diese fehlenden Berechtigungen wieder hinzufügen, bevor Sie fortfahren.
Wenn Sie nicht GKE ausführen, finden Sie weitere Informationen unter Anmeldedaten explizit angeben.
Dienstkonto für die Workload Identity Federation for GKE konfigurieren
Sie können diesen Abschnitt überspringen, wenn in Ihrem Kubernetes-Cluster die Workload Identity Federation for GKE nicht aktiviert ist.
Managed Service for Prometheus erfasst Messwertdaten mithilfe der Cloud Monitoring API. Wenn in Ihrem Cluster die Workload Identity Federation for GKE verwendet wird, müssen Sie Ihrem Kubernetes-Dienstkonto die Berechtigung für die Monitoring API erteilen. In diesem Abschnitt wird Folgendes beschrieben:
- Dediziertes Google Cloud-Dienstkonto
gmp-test-sa
erstellen - Google Cloud-Dienstkonto an das Standard-Kubernetes-Dienstkonto im Test-Namespace
NAMESPACE_NAME
binden - Dem Google Cloud-Dienstkonto die erforderliche Berechtigung gewähren
Dienstkonto erstellen und binden
Dieser Schritt wird an mehreren Stellen in der Dokumentation zu Managed Service for Prometheus aufgeführt. Wenn Sie diesen Schritt bereits als Teil einer vorherigen Aufgabe ausgeführt haben, müssen Sie ihn nicht wiederholen. Fahren Sie mit Dienstkonto autorisieren fort.
Mit der folgenden Befehlssequenz wird das Dienstkonto gmp-test-sa
erstellt und an das Standard-Kubernetes-Dienstkonto im Namespace NAMESPACE_NAME
gebunden:
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
Wenn Sie einen anderen GKE-Namespace oder ein anderes GKE-Dienstkonto verwenden, passen Sie die Befehle entsprechend an.
Dienstkonto autorisieren
Gruppen zusammengehöriger Berechtigungen werden in Rollen zusammengefasst und Sie weisen die Rollen einem Hauptkonto zu, in diesem Beispiel dem Google Cloud-Dienstkonto. Weitere Informationen zu Monitoring-Rollen finden Sie unter Zugriffssteuerung.
Mit dem folgenden Befehl werden dem Google Cloud-Dienstkonto gmp-test-sa
die Monitoring API-Rollen zugewiesen, die zum Schreiben von Messwertdaten erforderlich sind.
Wenn Sie dem Google Cloud-Dienstkonto im Rahmen der vorherigen Aufgabe bereits eine bestimmte Rolle zugewiesen haben, müssen Sie dies nicht noch einmal tun.
gcloud projects add-iam-policy-binding PROJECT_ID\ --member=serviceAccount:gmp-test-sa@PROJECT_ID.iam.gserviceaccount.com \ --role=roles/monitoring.metricWriter
Fehlerbehebung der Konfiguration von Workload Identity Federation for GKE
Wenn Sie Probleme mit der Workload Identity Federation for GKE haben, lesen Sie die Dokumentation zum Prüfen der Workload Identity Federation for GKE-Einrichtung und zur Fehlerbehebung bei der Workload Identity Federation for GKE.
Da Tippfehler und partielle Kopierfunktionen die häufigsten Fehlerquellen bei der Konfiguration von Workload Identity Federation for GKE sind, empfehlen wir dringend die bearbeitbaren Variablen und anklickbaren Symbole, die in die Codebeispiele in dieser Anleitung eingebettet sind.
Workload Identity Federation for GKE in Produktionsumgebungen
Das in diesem Dokument beschriebene Beispiel bindet das Google Cloud-Dienstkonto an das Standard-Kubernetes-Dienstkonto und gewährt dem Google Cloud-Dienstkonto alle erforderlichen Berechtigungen zur Verwendung der Monitoring API.
In einer Produktionsumgebung können Sie einen feiner abgestimmten Ansatz mit einem Dienstkonto für jede Komponente nutzen, das jeweils nur minimale Berechtigungen hat. Weitere Informationen zum Konfigurieren von Dienstkonten für die Verwaltung von Workload Identity finden Sie unter Workload Identity Federation for GKE verwenden.
OpenTelemetry Collector einrichten
In diesem Abschnitt werden beschrieben, wie Sie den OpenTelemetry-Collector einrichten und verwenden, um Messwerte aus einer Beispielanwendung zu extrahieren und die Daten an Google Cloud Managed Service for Prometheus zu senden. Ausführliche Informationen zur Konfiguration finden Sie in den folgenden Abschnitten:
- Prometheus-Messwerte extrahieren
- Prozessoren hinzufügen
googlemanagedprometheus
-Exporter konfigurieren
Der OpenTelemetry Collector entspricht dem Binärprogramm des Managed Service for Prometheus-Agents. Die OpenTelemetry-Community veröffentlicht regelmäßig Releases, einschließlich Quellcode, Binärprogramme und Container-Images.
Sie können diese Artefakte entweder auf VMs oder Kubernetes-Clustern mit den Best-Practices-Standardeinstellungen bereitstellen oder den Collector-Builder verwenden, um einen eigenen Collector zu erstellen, der nur aus den Komponenten besteht, die Sie benötigen. Zum Erstellen eines Collectors für die Verwendung mit Managed Service for Prometheus benötigen Sie die folgenden Komponenten:
- Der Managed Service for Prometheus-Exporter, der Ihre Messwerte in Managed Service for Prometheus schreibt.
- Einen Empfänger zum Scrapen Ihrer Messwerte. In diesem Dokument wird davon ausgegangen, dass Sie den OpenTelemetry Prometheus-Empfänger verwenden. Der Managed Service for Prometheus-Exporter ist jedoch mit jedem OpenTelemetry-Messwertempfänger kompatibel.
- Prozessoren zum Batching und Markup von Messwerten, um je nach Umgebung wichtige Ressourcenkennungen zu enthalten.
Diese Komponenten werden mithilfe einer Konfigurationsdatei aktiviert, die mit dem Flag --config
an den Collector übergeben wird.
In den folgenden Abschnitten wird die Konfiguration der einzelnen Komponenten genauer erläutert. In diesem Dokument wird beschrieben, wie Sie den Profiler in GKE und anderswo ausführen.
Collector konfigurieren und bereitstellen
Unabhängig davon, ob Sie die Erfassung in Google Cloud oder in einer anderen Umgebung ausführen, können Sie den OpenTelemetry Collector so konfigurieren, dass er in Managed Service for Prometheus exportiert. Der größte Unterschied besteht in der Konfiguration des Collectors. In Umgebungen, die nicht zu Google Cloud gehören, sind möglicherweise zusätzliche Formatierungen von Messdaten erforderlich, damit sie mit Managed Service for Prometheus kompatibel sind. In Google Cloud kann ein Großteil dieser Formatierungen jedoch automatisch vom Collector erkannt werden.
OpenTelemetry Collector in GKE ausführen
Sie können die folgende Konfiguration in eine Datei namens config.yaml
kopieren, um den OpenTelemetry Collector in GKE einzurichten:
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]
In der vorherigen Konfiguration werden der Prometheus-Empfänger und der Managed Service for Prometheus-Exporter verwendet, um die Messwertendpunkte auf Kubernetes-Pods zu extrahieren und diese Messwerte nach Managed Service for Prometheus zu exportieren. Die Pipelineprozessoren formatieren und verarbeiten die Daten im Batch.
Weitere Informationen zur Funktionsweise der einzelnen Teile dieser Konfiguration sowie Konfigurationen für verschiedene Plattformen finden Sie in den folgenden Abschnitten unter Messwerte extrahieren undProzessoren hinzufügen.
Wenn Sie eine vorhandene Prometheus-Konfiguration mit dem prometheus
-Empfänger des OpenTelemetry-Collectors verwenden, ersetzen Sie alle $
-Zeichen durch $$
to avoid
triggering environment variable substitution. For more information, see
Scrape Prometheus metrics.
You can modify this config based on your environment, provider, and the metrics you want to scrape, but the example config is a recommended starting point for running on GKE.
Run the OpenTelemetry Collector outside Google Cloud
Running the OpenTelemetry Collector outside Google Cloud, such as on-premises or on other cloud providers, is similar to running the Collector on GKE. However, the metrics you scrape are less likely to automatically include data that best formats it for Managed Service for Prometheus. Therefore, you must take extra care to configure the collector to format the metrics so they are compatible with Managed Service for Prometheus.
You can the following config into a file called config.yaml
to set up the
OpenTelemetry Collector for deployment on a non-GKE Kubernetes
cluster:
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]
This config does the following:
- Sets up a Kubernetes service discovery scrape config for Prometheus. For more information, see scraping Prometheus metrics.
- Manually sets
cluster
,namespace
, andlocation
resource attributes. For more information about resource attributes, including resource detection for Amazon EKS and Azure AKS, see Detect resource attributes. - Sets the
project
option in thegooglemanagedprometheus
exporter. For more information about the exporter, see Configure thegooglemanagedprometheus
exporter.
When using an existing Prometheus configuration with the OpenTelemetry
Collector's prometheus
receiver, replace any $
characters with $$
, um das Auslösen der Umgebungsvariablen zu vermeiden. Weitere Informationen finden Sie unter Prometheus-Messwerte extrahieren.
Informationen zu Best Practices für die Konfiguration des Collectors in anderen Clouds finden Sie unter Amazon EKS oder Azure AKS.
Beispielanwendung bereitstellen
Die Beispielanwendung gibt Folgendes aus: den Zählermesswert example_requests_total
und den example_random_numbers
-Histogrammmesswert (unter anderem) am Port metrics
.
Das Manifest für dieses Beispiel definiert drei Replikate.
Führen Sie den folgenden Befehl aus, um die Beispielanwendung bereitzustellen:
kubectl -n NAMESPACE_NAME apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/prometheus-engine/v0.13.0/examples/example-app.yaml
ConfigMap für die Erfassungsdatei erstellen
Nachdem Sie die Konfiguration erstellt und in der Datei config.yaml
abgelegt haben, verwenden Sie diese Datei, um eine Kubernetes-ConfigMap basierend auf der Datei config.yaml
zu erstellen.
Wenn der Collector bereitgestellt wird, wird die ConfigMap bereitgestellt und die Datei geladen.
Mit dem folgenden Befehl erstellen Sie eine ConfigMap mit dem Namen otel-config
und Ihrer Konfiguration:
kubectl -n NAMESPACE_NAME create configmap otel-config --from-file config.yaml
Collector bereitstellen
Erstellen Sie eine Datei mit dem Namen collector-deployment.yaml
und mit folgendem Inhalt:
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.106.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
Erstellen Sie die Collector-Bereitstellung in Ihrem Kubernetes-Cluster mit dem folgenden Befehl:
kubectl -n NAMESPACE_NAME create -f collector-deployment.yaml
Nachdem der Pod gestartet wurde, extrahiert er die Beispielanwendung und meldet Messwerte an Managed Service for Prometheus.
Informationen zum Abfragen Ihrer Daten finden Sie unter Abfrage mit Cloud Monitoring oder Abfrage mit Grafana.
Anmeldedaten explizit angeben
Bei der Ausführung in GKE ruft der OpenTelemetry Collector automatisch Anmeldedaten aus der Umgebung anhand des Dienstkontos des Knotens ab.
In Nicht-GKE-Kubernetes-Clustern müssen Anmeldedaten explizit mit Flags oder der Umgebungsvariablen GOOGLE_APPLICATION_CREDENTIALS
für den OpenTelemetry Collector bereitgestellt werden.
Legen Sie den Kontext auf Ihr Zielprojekt fest:
gcloud config set project PROJECT_ID
Erstellen Sie ein Dienstkonto:
gcloud iam service-accounts create gmp-test-sa
Mit diesem Schritt wird das Dienstkonto erstellt, das Sie möglicherweise bereits in der Anleitung für Workload Identity Federation for GKE erstellt haben.
Gewähren Sie die erforderlichen Berechtigungen für das Dienstkonto:
gcloud projects add-iam-policy-binding PROJECT_ID\ --member=serviceAccount:gmp-test-sa@PROJECT_ID.iam.gserviceaccount.com \ --role=roles/monitoring.metricWriter
Erstellen Sie einen Schlüssel für das Dienstkonto und laden Sie ihn herunter:
gcloud iam service-accounts keys create gmp-test-sa-key.json \ --iam-account=gmp-test-sa@PROJECT_ID.iam.gserviceaccount.com
Fügen Sie dem Nicht-GKE-Cluster die Schlüsseldatei als Secret hinzu:
kubectl -n NAMESPACE_NAME create secret generic gmp-test-sa \ --from-file=key.json=gmp-test-sa-key.json
Öffnen Sie die OpenTelemetry-Deployment-Ressource zur Bearbeitung:
kubectl -n NAMESPACE_NAME edit deployment otel-collector
Fügen Sie der Ressource den fett formatierten Text hinzu:
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 ...
Speichern Sie die Datei und schließen Sie den Editor. Nachdem die Änderung angewendet wurde, werden die Pods neu erstellt und beginnen mit der Authentifizierung beim Messwert-Backend mit dem angegebenen Dienstkonto.
Prometheus-Messwerte extrahieren
In diesem und dem folgenden Abschnitt finden Sie weitere Informationen zur Anpassung der Verwendung des OpenTelemetry-Collectors. Diese Informationen können in bestimmten Situationen hilfreich sein, aber nichts davon ist erforderlich, um das unter OpenTelemetry Collector einrichten beschriebene Beispiel auszuführen.
Wenn Ihre Anwendungen bereits Prometheus-Endpunkte bereitstellen, kann der OpenTelemetry Collector diese Endpunkte mit demselben Scraping-Konfigurationsformat wie bei einer Standard-Prometheus-Konfiguration abrufen. Aktivieren Sie dazu den Prometheus-Empfänger in der Collector-Konfiguration.
Eine einfache Prometheus-Empfängerkonfiguration für Kubernetes-Pods könnte so aussehen:
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]
Dies ist eine einfache Service Discovery-basierte Extraktionskonfiguration, die Sie nach Bedarf ändern können.
Wenn Sie eine vorhandene Prometheus-Konfiguration mit dem prometheus
-Empfänger des OpenTelemetry-Collectors verwenden, ersetzen Sie alle $
-Zeichen durch $$
to avoid
triggering environment variable substitution. This is especially important to do
for the replacement
value within your relabel_configs
section. For example,
if you have the following relabel_config
section:
- source_labels: [__address__, __meta_kubernetes_pod_annotation_prometheus_io_port] action: replace regex: (.+):(?:\d+);(\d+) replacement: $1:$2 target_label: __address__
Then rewrite it to be:
- source_labels: [__address__, __meta_kubernetes_pod_annotation_prometheus_io_port] action: replace regex: (.+):(?:\d+);(\d+) replacement: $$1:$$2 target_label: __address__ .
For more information, see the OpenTelemetry documentation.
Next, we strongly recommend that you use processors to format your metrics. In many cases, processors must be used to properly format your metrics.
Add processors
OpenTelemetry processors modify telemetry data before it is exported. You can use the processors below to ensure that your metrics are written in a format compatible with Managed Service for Prometheus.
Detect resource attributes
The Managed Service for Prometheus exporter for OpenTelemetry uses the
prometheus_target
monitored resource to uniquely identify time series data points. The exporter parses the required monitored-resource fields from resource attributes on the metric data points. The fields and the attributes from which the values are scraped are:
- project_id: auto-detected by Application Default Credentials,
gcp.project.id
, orproject
in exporter config (see configuring the exporter)- 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
Failure to set these labels to unique values can result in "duplicate timeseries" errors when exporting to Managed Service for Prometheus.
The Prometheus receiver automatically sets the
service.name
attribute based on thejob_name
in the scrape config, andservice.instance.id
attribute based on the scrape target'sinstance
. The receiver also setsk8s.namespace.name
when usingrole: pod
in the scrape config.We recommend populating the other attributes automatically using the resource detection processor. However, depending on your environment, some attributes might not be automatically detectable. In this case, you can use other processors to either manually insert these values or parse them from metric labels. The following sections illustration configurations for doing this processing on various platforms
GKE
When running OpenTelemetry on GKE, you only need to enable the resource-detection processor to fill out the resource labels. Be sure that your metrics don't already contain any of the reserved resource labels. If this is unavoidable, see Avoid resource attribute collisions by renaming attributes.
processors: resourcedetection: detectors: [gcp] timeout: 10sThis section can be copied directly into your config file, replacing the
processors
section if it already exists.Amazon EKS
The EKS resource detector does not automatically fill in the
cluster
ornamespace
attributes. You can provide these values manually by using the resource processor, as shown in the following example: processors: resourcedetection: detectors: [eks] timeout: 10s resource: attributes: - key: "cluster" value: "my-eks-cluster" action: upsert - key: "namespace" value: "my-app" action: upsertYou can also convert these values from metric labels using the
groupbyattrs
processor (see move metric labels to resource labels below).Azure AKS
The AKS resource detector does not automatically fill in the
cluster
ornamespace
attributes. You can provide these values manually by using the resource processor, as shown in the following example: processors: resourcedetection: detectors: [aks] timeout: 10s resource: attributes: - key: "cluster" value: "my-eks-cluster" action: upsert - key: "namespace" value: "my-app" action: upsertYou can also convert these values from metric labels by using the
groupbyattrs
processor; see Move metric labels to resource labels.On-premises and non-cloud environments
With on-premises or non-cloud environments, you probably can't detect any of the necessary resource attributes automatically. In this case, you can emit these labels in your metrics and move them to resource attributes (see Move metric labels to resource labels), or manually set all of the resource attributes as shown in the following example:
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: upsertCreate your collector config as a ConfigMap describes how to use the config. That section assumes you have put your config in a file called
config.yaml
.The
project_id
resource attribute can still be automatically set when running the Collector with Application Default Credentials. If your Collector does not have access to Application Default Credentials, see Settingproject_id
.Alternatively, you can manually set the resource attributes you need in an environment variable,
OTEL_RESOURCE_ATTRIBUTES
, with a comma-separated list of key/value pairs, for example: export OTEL_RESOURCE_ATTRIBUTES="cluster=my-cluster,namespace=my-app,location=us-east-1"Then use the
env
resource detector processor to set the resource attributes: processors: resourcedetection: detectors: [env]Avoid resource attribute collisions by renaming attributes
If your metrics already contain labels that collide with the required resource attributes (such as
location
,cluster
, ornamespace
), rename them to avoid the collision. The Prometheus convention is to add the prefixexported_
to the label name. To add this prefix, use the transform processor.The following
processors
config renames any potential collisions and resolves any conflicting keys from the metric: 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")Move metric labels to resource labels
In some cases, your metrics might be intentionally reporting labels such as
namespace
because your exporter is monitoring multiple namespaces. For example, when running the kube-state-metrics exporter.In this scenario, these labels can be moved to resource attributes using the groupbyattrs processor:
processors: groupbyattrs: keys: - namespace - cluster - locationIn the above example, given a metric with the labels
namespace
,cluster
, and/orlocation
, those labels will be converted to the matching resource attributes.Limit API requests and memory usage
Two other processors, the batch processor and memory limiter processor allow you to limit the resource consumption of your collector.
Batch processing
Batching requests lets you define how many data points to send in a single request. Note that Cloud Monitoring has a limit of 200 time series per request. Enable the batch processor by using the following settings:
processors: batch: # batch metrics before sending to reduce API usage send_batch_max_size: 200 send_batch_size: 200 timeout: 5sMemory limiting
We recommend enabling the memory-limiter processor to prevent your collector from crashing at times of high throughput. Enable the processing by using the following settings:
processors: memory_limiter: # drop metrics if memory usage gets too high check_interval: 1s limit_percentage: 65 spike_limit_percentage: 20Configure the
googlemanagedprometheus
exporterBy default, using the
googlemanagedprometheus
exporter on GKE requires no additional configuration. For many use cases you only need to enable it with an empty block in theexporters
section: exporters: googlemanagedprometheus:However, the exporter does provide some optional configuration settings. The following sections describe the other configuration settings.
Setting
project_id
To associate your time series with a Google Cloud project, the
prometheus_target
monitored resource must haveproject_id
set.When running OpenTelemetry on Google Cloud, the Managed Service for Prometheus exporter defaults to setting this value based on the Application Default Credentials it finds. If no credentials are available, or you want to override the default project, you have two options:
- Set
project
in the exporter config- Add a
gcp.project.id
resource attribute to your metrics.We strongly recommend using the default (unset) value for
project_id
rather than explicitly setting it, when possible.Set
project
in the exporter configThe following config excerpt sends metrics to Managed Service for Prometheus in the Google Cloud project
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]The only change from previous examples is the new line
project: MY_PROJECT
. This setting is useful if you know that every metric coming through this Collector should be sent toMY_PROJECT
.Set
gcp.project.id
resource attributeYou can set project association on a per-metric basis by adding a
gcp.project.id
resource attribute to your metrics. Set the value of the attribute to the name of the project the metric should be associated with.For example, if your metric already has a label
project
, this label can be moved to a resource attribute and renamed togcp.project.id
by using processors in the Collector config, as shown in the following example: 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]Setting client options
The
googlemanagedprometheus
exporter uses gRPC clients for Managed Service for Prometheus. Therefore, optional settings are available for configuring the gRPC client:
compression
: Enables gzip compression for gRPC requests, which is useful for minimizing data transfer fees when sending data from other clouds to Managed Service for Prometheus (valid values:gzip
).user_agent
: Overrides the user-agent string sent on requests to Cloud Monitoring; only applies to metrics. Defaults to the build and version number of your OpenTelemetry Collector, for example,opentelemetry-collector-contrib 0.106.0
.endpoint
: Sets the endpoint to which metric data is going to be sent.use_insecure
: If true, uses gRPC as the communication transport. Has an effect only when theendpoint
value is not "".grpc_pool_size
: Sets the size of the connection pool in the gRPC client.prefix
: Configures the prefix of metrics sent to Managed Service for Prometheus. Defaults toprometheus.googleapis.com
. Don't change this prefix; doing so causes metrics to not be queryable with PromQL in the Cloud Monitoring UI.In most cases, you don't need to change these values from their defaults. However, you can change them to accommodate special circumstances.
All of these settings are set under a
metric
block in thegooglemanagedprometheus
exporter section, as shown in the following example: receivers: prometheus: config: ... processors: resourcedetection: detectors: [gcp] timeout: 10s exporters: googlemanagedprometheus: metric: compression: gzip user_agent: opentelemetry-collector-contrib 0.106.0 endpoint: "" use_insecure: false grpc_pool_size: 1 prefix: prometheus.googleapis.com service: pipelines: metrics: receivers: [prometheus] processors: [resourcedetection] exporters: [googlemanagedprometheus]What's next
- Use PromQL in Cloud Monitoring to query Prometheus metrics.
- Use Grafana to query Prometheus metrics.
- Set up the OpenTelemetry Collector as a sidecar agent in Cloud Run.
The Cloud Monitoring Metrics Management page provides information that can help you control the amount you spend on billable metrics without affecting observability. The Metrics Management page reports the following information:
- Ingestion volumes for both byte- and sample-based billing, across metric domains and for individual metrics.
- Data about labels and cardinality of metrics.
- Number of reads for each metric.
- Use of metrics in alerting policies and custom dashboards.
- Rate of metric-write errors.
You can also use the Metrics Management to exclude unneeded metrics, eliminating the cost of ingesting them. For more information about the Metrics Management page, see View and manage metric usage.