Verwaltetes OpenTelemetry für GKE

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

Wenn Sie verwaltetes OpenTelemetry für Google Kubernetes Engine (GKE) verwenden möchten, 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 OpenTelemetry Protocol-Endpunkt im Cluster 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) und multimodale Prompts und Antworten.

    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 Ressource Instrumentation, instrumentations.telemetry.googleapis.com, ist eine andere Ressource als die Ressource Instrumentation für den OpenTelemetry-Operator.

Eine Anleitung zur Verwendung von verwaltetem OpenTelemetry für GKE finden Sie unter Verwaltetes 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 eine Filterung und Steuerung auf Collector-Ebene benötigen, können Sie stattdessen den von Google entwickelten OpenTelemetry-Collector verwenden, anstatt diesen verwalteten Dienst zu nutzen.

OpenTelemetry bietet APIs, Bibliotheken und SDKs zum Generieren verteilter Traces, Messwerte und Logs für das Anwendungsmonitoring. Weitere Informationen zu OpenTelemetry finden Sie in der Dokumentation zu OpenTelemetry und zum OpenTelemetry-Protokoll (OTLP). Weitere Informationen zum Generieren und Erfassen von Daten zum Laufzeitverhalten Ihrer Anwendung finden Sie unter Instrumentierung und Beobachtbarkeit.

Funktionsweise von verwaltetem OpenTelemetry für GKE

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

Verwaltete Erfassung

Die verwaltete Erfassung bietet einen OTLP-Endpunkt im Cluster, indem ein verwalteter OpenTelemetry-Collector in Ihrem Cluster bereitgestellt wird. Dieser OTLP-Endpunkt im Cluster 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 sie Daten an den Collector sendet.

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

Die verwaltete Erfassung sendet die erfassten Daten an Google Cloud Observability. 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

Mit der automatischen Konfiguration kann GKE Arbeitslasten, die in GKE ausgeführt werden, so konfigurieren, dass sie Signale an den Endpunkt des verwalteten Collectors senden.

Es gibt verschiedene Methoden, mit denen eine Arbeitslast konfiguriert werden kann. 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.

Wenn Sie die automatische Konfiguration verwenden, 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 enthalten, werden OpenTelemetry-Daten während der Ausführung der Arbeitslast 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 sind. 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.

Die benutzerdefinierte Ressource Instrumentation

Mit der benutzerdefinierten Ressource Instrumentation können Sie Folgendes tun:

  • Festlegen, ob die Umgebungsvariablen in die Container ausgewählter Pods oder aller Pods in einem Namespace eingefügt werden sollen.
  • Den Typ der erfassten Daten steuern (Logs, Messwerte und Traces).
  • Die Häufigkeit steuern, mit der Messwertdaten an den verwalteten Collector gesendet werden.
  • Die Sampling-Rate von Tracedaten steuern.

Weitere Informationen zur Verwendung der benutzerdefinierten Ressource Instrumentation 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 im Cluster vorhanden sein, 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 das automatische Einfügen der Umgebungsvariablen auszulösen.

Umgebungsvariablen

Wenn eine Arbeitslast im 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 verwaltetem 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 Ressource Instrumentation ab.

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

  • OpenTelemetry-Exporter-Endpunkt.
    • OTEL_EXPORTER_OTLP_ENDPOINT: Eine Basis-Endpunkt-URL für jeden Signaltyp. Dieser Endpunkt verweist immer auf den HTTP-Endpunkt des verwalteten OpenTelemetry-Collectors im Cluster für Logs, Messwerte und Traces. Der Endpunkt ist 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 Erfassen von Traces verwendet wird, auf einen der folgenden Werte fest:
      • parentbased_traceidratio , wenn das Trace-Sampling in der benutzerdefinierten Ressource konfiguriert ist.
      • parentbased_always_on ist der Standardwert dieser Umgebungsvariable. Er wird verwendet, wenn diese Umgebungsvariable in der benutzerdefinierten Ressource nicht konfiguriert oder null ist.
    • OTEL_TRACES_SAMPLER_ARG: Gibt das Trace-Sampling-Verhältnis an (zwischen 0,0 und 1,0). Wenn in der benutzerdefinierten Ressource nichts konfiguriert ist, wird 1,0 verwendet.
  • Verzögerungsintervall zwischen dem Start von zwei aufeinanderfolgenden Messwert-Exports.
    • OTEL_METRIC_EXPORT_INTERVAL: Das Zeitintervall (in Millisekunden) zwischen dem Start von zwei Exportversuchen (min.: 5000, max.: 300000, Standard: 30000).
  • Deaktivierung des OTLP-Telemetrie-Exports 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 auf none gesetzt. Standardwert: otlp.
    • OTEL_METRICS_EXPORTER: Deaktiviert den Export von Messwerten, wenn auf none gesetzt. Standardwert: otlp.
    • OTEL_LOGS_EXPORTER: Deaktiviert den Export von Logs, wenn auf none gesetzt. Standardwert: otlp.
  • Identifizierung von hostNetwork-Pods zum Zuordnen der Metadaten durch den Kubernetes Attributes Processor des OpenTelemetry-Collectors.
    • K8S_POD_UID: Die Pod-UID eines hostNetwork-Pods zum Ausfüllen 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.
  • Prompts und Antworten.
    • OTEL_INSTRUMENTATION_GENAI_UPLOAD_FORMAT='jsonl': Weist OpenTelemetry an, Cloud Storage-Objekte als JSON Lines zu formatieren. Diese Umgebungsvariable hat einen festen Wert: jsonl.
    • OTEL_INSTRUMENTATION_GENAI_COMPLETION_HOOK='upload': Weist OpenTelemetry an, Prompt- und Antwortdaten hochzuladen, anstatt diese Inhalte in Trace-Spans einzubetten. Verweise auf die hochgeladenen Objekte sind in einem Logeintrag enthalten. Diese Umgebungsvariable hat einen festen Wert: upload.
    • OTEL_SEMCONV_STABILITY_OPT_IN='gen_ai_latest_experimental': Weist OpenTelemetry an, die neuesten semantischen Konventionen für generative KI zu verwenden. Diese Umgebungsvariable hat einen festen Wert: gen_ai_latest_experimental.
    • OTEL_INSTRUMENTATION_GENAI_UPLOAD_BASE_PATH: Geben Sie den Pfad für Objekte an. Beispiel: gs://STORAGE_BUCKET_NAME/PATH

Manuelle Konfiguration

Es gibt verschiedene Methoden, mit denen Sie eine Arbeitslast so konfigurieren können, dass sie Signale an den Endpunkt des verwalteten Collectors sendet. Wenn Sie Ihre Arbeitslast manuell konfigurieren, können Sie Umgebungsvariablen manuell hinzufügen und ändern oder eine andere Methode wie Befehlszeilen-Flags 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, die OpenTelemetry verwenden, 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 sind. Das Agent Development Kit (ADK) unterstützt beispielsweise OpenTelemetry nativ.

Weitere Informationen zum Generieren und Erfassen von Daten zum Laufzeitverhalten Ihrer Anwendung finden Sie unter Instrumentierung und Beobachtbarkeit.

Wenn eine Arbeitslast einige Arten von OTLP-Daten unterstützt, andere jedoch nicht, erfasst verwaltetes OpenTelemetry für GKE die OTLP-Daten. Wenn eine Arbeitslast beispielsweise das OpenTelemetry SDK verwendet, um Traces zu implementieren, aber nicht für Logs oder Messwerte, werden keine Logs und Messwertdaten von verwaltetem OpenTelemetry für GKE erfasst. Weitere Informationen zum Steuern des zu erfassenden Datentyps finden Sie unter Zu erfassende Signaltypen auswählen.

Das Einfügen der OpenTelemetry-Konfiguration wird für privilegierte Arbeitslasten von GKE Autopilot-Partnern nicht unterstützt.

Abrechnung

Wenn Sie Telemetriedaten an Google Cloudsenden, werden Ihnen die Kosten nach Aufnahme volumen in Rechnung gestellt. Messwerte werden gemäß den Preisen für Google Cloud Managed Service for Prometheus, Logs gemäß den Preisen für Cloud Logging und Traces gemäß den Preisen für Cloud Trace in Rechnung gestellt.

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

Kontingente

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

Nächste Schritte