Verwaltetes OpenTelemetry für GKE

In diesem Dokument wird Managed OpenTelemetry für Google Kubernetes Engine (GKE) beschrieben. Damit können Sie OpenTelemetry Protocol (OTLP)-Traces, -Messwerte und -Logs von Anwendungen, die in GKE ausgeführt werden, an Google Cloud Observability senden. Managed OpenTelemetry ist die einzige verwaltete Lösung von Google Cloud zum Erfassen von Tracedaten in GKE.

Damit Managed OpenTelemetry für Google Kubernetes Engine (GKE) verwendet werden kann, müssen Anwendungen bereits instrumentiert sein, um Signale mit dem OpenTelemetry-Protokoll zu generieren. Weitere Informationen finden Sie unter Unterstützte Arbeitslasten.

Verwaltetes OpenTelemetry für GKE besteht aus zwei Komponenten:

  • Verwaltete Erfassung: Der verwaltete Collector bietet einen In-Cluster-OpenTelemetry Protocol-Endpunkt als Ziel für Arbeitslasten, um Traces, Messwerte und Logs im OTLP-Format zu senden, ohne dass ein Collector verwaltet werden muss.

  • Automatische Konfiguration: Eine benutzerdefinierte Ressource namens Instrumentation ermöglicht eine automatische Konfiguration für Ihre GKE-Arbeitslasten, um korrelierte OpenTelemetry-Traces, -Messwerte und -Logs zu generieren und aufzunehmen. Dieser Ansatz unterstützt das Agent Development Kit (ADK).

    Sie können die benutzerdefinierte Ressource Instrumentation für Arbeitslasten verwenden, die das OpenTelemetry SDK verwenden und mit standardmäßigen OpenTelemetry-Umgebungsvariablen konfiguriert sind. Diese benutzerdefinierte Instrumentation-Ressource, instrumentations.telemetry.googleapis.com, ist eine andere Ressource als die Instrumentation-Ressource für den OpenTelemetry-Operator.

Eine Anleitung zur Verwendung von Managed OpenTelemetry für GKE finden Sie unter Managed OpenTelemetry für GKE bereitstellen.

Mit verwaltetem OpenTelemetry für GKE können Sie OTLP-Telemetriedaten erfassen, ohne einen OpenTelemetry-Collector verwalten und betreiben zu müssen. Der Betrieb eines eigenen Collectors kann mit Aufwand verbunden sein, z. B. für Authentifizierung, Konfiguration, Upgrades und Monitoring. Wenn Sie jedoch Filterung und Steuerelemente auf Collector-Ebene benötigen, können Sie stattdessen den von Google entwickelten OpenTelemetry Collector verwenden.

OpenTelemetry bietet APIs, Bibliotheken und SDKs zum Generieren von verteilten Traces, Messwerten und Logs für die Anwendungsüberwachung. Weitere Informationen zu OpenTelemetry finden Sie in der Dokumentation zu OpenTelemetry und zum OpenTelemetry-Protokoll (OTLP). Weitere Informationen zum Generieren und Erfassen von Laufzeitverhaltensdaten Ihrer Anwendung finden Sie unter Instrumentierung und Beobachtbarkeit.

Funktionsweise von verwaltetem OpenTelemetry für GKE

Managed OpenTelemetry für GKE besteht aus zwei Komponenten: verwaltete Erfassung und automatische Konfiguration.

Verwaltete Sammlung

Bei der verwalteten Erfassung wird ein OTLP-Endpunkt im Cluster bereitgestellt, indem ein verwalteter OpenTelemetry Collector in Ihrem Cluster bereitgestellt wird. Dieser In-Cluster-OTLP-Endpunkt empfängt Traces, Messwerte und Logs im OTLP-Format. Damit Daten von einer Arbeitslast empfangen werden können, muss die Arbeitslast so konfiguriert sein, dass Daten an den Collector gesendet werden.

Der Endpunkt des verwalteten Collectors ist: http://opentelemetry-collector.gke-managed-otel.svc.cluster.local:4318.

Bei der verwalteten Erfassung werden die erhobenen Daten an Google Cloud Observability gesendet. Die Daten sind dann in den folgenden Diensten verfügbar:

Der verwaltete Collector kann für einen GKE-Cluster über die Console oder die gcloud CLI aktiviert werden. Eine Anleitung finden Sie unter Verwaltetes OpenTelemetry für GKE in einem Cluster aktivieren.

Automatische Konfiguration

Bei der automatischen Konfiguration werden Arbeitslasten, die in GKE ausgeführt werden, so konfiguriert, dass Signale an den Endpunkt des verwalteten Collectors gesendet werden.

Es gibt verschiedene Methoden, mit denen Sie eine Arbeitslast konfigurieren können. Bei der automatischen Konfiguration werden Umgebungsvariablen verwendet, die in den Container der Arbeitslast eingefügt werden, damit die Arbeitslast Signale an den verwalteten Collector sendet. Wenn Sie die Arbeitslast manuell konfigurieren, können Sie andere Methoden verwenden. Weitere Informationen finden Sie unter Manuelle Konfiguration.

Bei der automatischen Konfiguration definieren Sie die Konfiguration mit der benutzerdefinierten Ressource Instrumentation. Anschließend fügt GKE Umgebungsvariablen wie den OTLP-Exporter-Endpunkt in die Container der Arbeitslast ein. Wenn die Container der Arbeitslast diese Umgebungsvariablen haben, werden während der Ausführung der Arbeitslast OpenTelemetry-Daten an den verwalteten Collector gesendet.

Die automatische Konfiguration ist für Arbeitslasten verfügbar, die OpenTelemetry nativ unterstützen. Das bedeutet, dass sie das OpenTelemetry SDK verwenden und mit standardmäßigen OpenTelemetry-Umgebungsvariablen konfiguriert werden. Weitere Informationen finden Sie unter Unterstützte Arbeitslasten.

Eine Anleitung zum Konfigurieren Ihrer Anwendung mit der automatischen Konfiguration finden Sie unter Anwendung für die Verwendung des verwalteten OpenTelemetry-Collectors konfigurieren.

Benutzerdefinierte Instrumentation-Ressource

Sie verwenden die benutzerdefinierte Instrumentation-Ressource für Folgendes:

  • Geben Sie an, ob die Umgebungsvariablen in die Container ausgewählter Pods oder aller Pods in einem Namespace eingefügt werden sollen.
  • Sie können den Typ der erfassten Daten (Logs, Messwerte und Traces) festlegen.
  • Sie können festlegen, wie oft Messwertdaten an den verwalteten Collector gesendet werden.
  • Die Sampling-Rate von Trace-Daten steuern

Weitere Informationen zur Verwendung der benutzerdefinierten Instrumentation-Ressource finden Sie unter Konfiguration ändern.

Umgebungsvariablen automatisch einfügen

Wenn Sie OpenTelemetry-Umgebungsvariablen automatisch in Ihre GKE-Arbeitslasten einfügen möchten, müssen Sie ein Instrumentation-Objekt in Ihrem Cluster konfigurieren. Wenn Sie die Anwendung dann mit dem Instrumentation-Objekt im Cluster bereitstellen, werden die Variablen von GKE eingefügt.

Das Instrumentation-Objekt muss sich im Cluster befinden, wenn die Anwendung bereitgestellt und die Pods erstellt werden. Wenn Sie die Anwendung bereitgestellt haben, bevor Sie das Instrumentation-Objekt erstellt haben, müssen Sie die Pods der Anwendung neu starten, um die automatische Einfügung der Umgebungsvariablen auszulösen.

Umgebungsvariablen

Wenn eine Arbeitslast in dem Namespace bereitgestellt wird, in dem die automatische Konfiguration aktiviert ist, fügt GKE Umgebungsvariablen in die Container der Arbeitslasten ein. Diese Umgebungsvariablen sind OpenTelemetry-Variablen aus der OpenTelemetry SDK-Konfiguration.

Die folgende Liste enthält alle Umgebungsvariablen, die von Managed OpenTelemetry für GKE eingefügt werden können. Die spezifischen Umgebungsvariablen, die in einen Container eingefügt werden, hängen von der Konfiguration in der benutzerdefinierten Instrumentation-Ressource ab.

Die Umgebungsvariablen, die automatisch in Container eingefügt werden können, sind die folgenden:

  • OpenTelemetry-Exporter-Endpunkt.
    • OTEL_EXPORTER_OTLP_ENDPOINT: Eine Basis-Endpunkt-URL für jeden Signaltyp. Dieser Endpunkt verweist immer auf den verwalteten OpenTelemetry Collector-HTTP-Endpunkt im Cluster für Logs, Messwerte und Traces. Der Endpunkt lautet: http://opentelemetry-collector.gke-managed-otel.svc.cluster.local:4318.
  • Konfiguration des Trace Sampling-Verhältnisses.
    • OTEL_TRACES_SAMPLER: Legt den Sampler fest, der vom SDK zum Erstellen von Stichproben von Traces verwendet wird. Folgende Werte sind möglich:
      • parentbased_traceidratio, wenn die Trace-Erfassung in der benutzerdefinierten Ressource konfiguriert ist.
      • parentbased_always_on ist der Standardwert dieser Umgebungsvariable. Sie wird verwendet, wenn diese Umgebungsvariable in der benutzerdefinierten Ressource nicht konfiguriert oder null ist.
    • OTEL_TRACES_SAMPLER_ARG: Gibt das Verhältnis der Trace-Stichproben an (zwischen 0,0 und 1,0). Wenn sie in der benutzerdefinierten Ressource nicht konfiguriert ist, wird 1.0 verwendet.
  • Verzögerungsintervall zwischen dem Start von zwei aufeinanderfolgenden Messwertexports.
    • OTEL_METRIC_EXPORT_INTERVAL: Das Zeitintervall (in Millisekunden) zwischen dem Beginn zweier Exportversuche (min.: 5.000, max.: 300.000, Standard: 60.000).
  • Deaktivierung des OTLP-Telemetrieexports nach Signaltyp. Signalexporteure werden deaktiviert, wenn tracer_provider, meter_provider oder logger_provider in der Datei Instrumentation auf null gesetzt sind.
    • OTEL_TRACES_EXPORTER: Deaktiviert den Export von Traces, wenn none festgelegt ist. Standardwert: otlp
    • OTEL_METRICS_EXPORTER: Deaktiviert den Export von Messwerten, wenn none festgelegt ist. Standardwert: otlp
    • OTEL_LOGS_EXPORTER: Deaktiviert den Export von Logs, wenn none festgelegt ist. Standardwert: otlp
  • Identifizierung von hostNetwork-Pods zum Zuordnen der Metadaten durch den Kubernetes Attributes Processor des OpenTelemetry Collector.
    • K8S_POD_UID: Die Pod-UID eines hostNetwork-Pods zum Festlegen der Einstellung k8s.pod.uid in der Umgebungsvariable OTEL_RESOURCE_ATTRIBUTES.
    • OTEL_RESOURCE_ATTRIBUTES: Der Wert enthält k8s.pod.uid=$(K8S_POD_UID), damit der Kubernetes Attributes Processor Metadaten wie k8s.namespace.name, k8s.deployment.name und k8s.node.name HostNetwork-Pods zuordnen kann. Durch die Zuordnung von Metadaten und hostNetwork-Pods können die extrahierten Metadaten als Ressourcenattribute zu Spans, Messwerten und Logs hinzugefügt werden.

Manuelle Konfiguration

Es gibt verschiedene Methoden, mit denen Sie eine Arbeitslast so konfigurieren können, dass Signale an den Endpunkt des verwalteten Collectors gesendet werden. Wenn Sie Ihre Arbeitslast manuell konfigurieren, können Sie Umgebungsvariablen manuell hinzufügen und ändern oder eine andere Methode wie Befehlszeilenflags verwenden.

Wir empfehlen nicht, sowohl die manuelle als auch die automatische Konfiguration für dieselbe Arbeitslast zu verwenden, da die automatische Konfiguration manuelle Änderungen überschreiben kann. Diese Kombination kann es erschweren, Änderungen an der Konfiguration nachzuvollziehen.

Weitere Informationen zur automatischen Konfiguration finden Sie unter Automatische Konfiguration.

Unterstützte Arbeitslasten

Unterstützte Arbeitslasten sind Arbeitslasten, bei denen OpenTelemetry verwendet wird, um Daten zum Laufzeitverhalten der Anwendung zu erfassen. Arbeitslasten unterstützen OpenTelemetry nativ, wenn sie das OpenTelemetry SDK verwenden und mit standardmäßigen OpenTelemetry-Umgebungsvariablen konfiguriert werden. Das Agent Development Kit (ADK) unterstützt beispielsweise OpenTelemetry nativ.

Weitere Informationen dazu, wie die Laufzeitverhaltensdaten Ihrer Anwendung generiert und erhoben werden, finden Sie unter Instrumentierung und Beobachtbarkeit.

Wenn eine Arbeitslast einige Arten von OTLP-Daten unterstützt und andere nicht, werden die OTLP-Daten von Managed OpenTelemetry for GKE erfasst. Wenn für eine Arbeitslast beispielsweise das OpenTelemetry SDK zum Implementieren von Traces verwendet wird, aber nicht für Logs oder Messwerte, werden Log- und Messwertdaten nicht von Managed OpenTelemetry for GKE erfasst. Weitere Informationen dazu, wie Sie den Typ der zu erhebenden Daten steuern können, finden Sie unter Signaltypen für die Erhebung auswählen.

Die OpenTelemetry-Konfigurationseinfügung wird für privilegierte Arbeitslasten von GKE Autopilot-Partnern nicht unterstützt.

Abrechnung

Wenn Sie Telemetriedaten an Google Cloudsenden, wird Ihnen das Aufnahmevolumen in Rechnung gestellt. Messwerte werden gemäß den Preisen für Google Cloud Managed Service for Prometheus abgerechnet, Logs gemäß den Preisen für Cloud Logging und Traces gemäß den Preisen für Cloud Trace.

Informationen zu den Kosten für die Aufnahme von Traces, Logs und Messwerten für Google Cloud Managed Service for Prometheus finden Sie unter Google Cloud Observability-Preise.

Kontingente

Wenn Sie Managed OpenTelemetry für GKE verwenden, gelten die Kontingente für Google Cloud Observability-Dienste. Entsprechende Details finden Sie hier:

Nächste Schritte