Verwaltetes OpenTelemetry für GKE

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

Wenn Sie Managed OpenTelemetry für die 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 stellt einen clusterinternen OpenTelemetry Protocol-Endpunkt als Ziel für Arbeitslasten bereit, 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 Prompt- und Antwortdaten.

    Sie können die benutzerdefinierte Ressource „Instrumentation“ für Arbeitslasten verwenden, die das OpenTelemetry SDK nutzen und mit Standard-OpenTelemetry-Umgebungsvariablen konfiguriert sind. Diese benutzerdefinierte Instrumentierungsressource, instrumentations.telemetry.googleapis.com, ist eine andere Ressource als die Instrumentierungsressource für den OpenTelemetry-Operator.

Eine Anleitung zur Verwendung von Managed OpenTelemetry for GKE finden Sie unter Managed OpenTelemetry for GKE bereitstellen.

Mit verwaltetem OpenTelemetry für GKE können Sie OTLP-Telemetriedaten erfassen, ohne einen OpenTelemetry-Collector verwalten und betreiben zu müssen. Das Ausführen eines eigenen Collectors kann zu Mehraufwand führen, einschließlich Authentifizierung, Konfiguration, Upgrades und Monitoring. Wenn Sie jedoch Filter und Steuerelemente auf Collector-Ebene benötigen, können Sie anstelle dieses verwalteten Dienstes den von Google erstellten OpenTelemetry Collector verwenden.

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

Funktionsweise von Managed OpenTelemetry for GKE

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

Verwaltete Erfassung

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

Der Endpunkt, an den Ihre Arbeitslast Daten sendet, hängt vom verwendeten Protokoll ab:

  • Die http://opentelemetry-collector.gke-managed-otel.svc.cluster.local:4318-URL für den HTTP-Endpunkt.
  • Die http://opentelemetry-collector.gke-managed-otel.svc.cluster.local:4317-URL für den gRPC-Endpunkt.

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

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

Es gibt verschiedene Methoden, um eine Arbeitslast zu konfigurieren. 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 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 Standard-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

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

  • 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 die Art der erfassten Daten (Logs, Messwerte und Traces) steuern.
  • Steuern Sie die Häufigkeit, mit der Messwertdaten an den verwalteten Collector gesendet werden.
  • Abtastrate von Trace-Daten steuern.
  • Steuern Sie das OTLP-Transportprotokoll (HTTP oder gRPC), das zum Exportieren von Telemetriedaten an den verwalteten Collector verwendet wird.

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 Instrumentierungsobjekt in Ihrem Cluster konfigurieren. Wenn Sie die Anwendung dann im Cluster mit dem Instrumentierungsobjekt 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 Injektion 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 Managed OpenTelemetry for GKE eingefügt werden können. Die spezifischen Umgebungsvariablen, die in einen Container eingefügt werden, hängen von der Konfiguration in der benutzerdefinierten Instrumentierungsressource ab.

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

  • Endpunkt und Protokoll des OpenTelemetry-Exporters.
    • OTEL_EXPORTER_OTLP_ENDPOINT: Eine Basis-Endpunkt-URL für jeden Signaltyp. Je nach dem in der benutzerdefinierten Ressource „Instrumentation“ konfigurierten Exporter ist der Wert dieser Umgebungsvariablen der im Cluster verwaltete OpenTelemetry-Collector-HTTP-Endpunkt (http://opentelemetry-collector.gke-managed-otel.svc.cluster.local:4318, Standard) oder der gRPC-Endpunkt (http://opentelemetry-collector.gke-managed-otel.svc.cluster.local:4317).
    • OTEL_EXPORTER_OTLP_PROTOCOL: Gibt das OTLP-Transportprotokoll an, das vom SDK-Exporter verwendet wird. Der Wert dieser Umgebungsvariablen ist einer der folgenden, je nachdem, welches OTLP-Transportprotokoll Sie verwenden:
      • grpc, wenn Sie das Transportprotokoll otlp_grpc verwenden.
      • http/protobuf, wenn Sie kein Transportprotokoll angeben oder das Transportprotokoll otlp_http verwenden.
  • Konfiguration des Trace-Stichprobenverhältnisses.
    • OTEL_TRACES_SAMPLER: Legt den Sampler fest, der vom SDK zum Erfassen von Traces verwendet wird. Mögliche Werte:
      • parentbased_traceidratio, wenn die Trace-Stichprobenerhebung in der benutzerdefinierten Ressource konfiguriert ist.
      • parentbased_always_on ist der Standardwert dieser Umgebungsvariablen. Sie wird verwendet, wenn diese Umgebungsvariable in der benutzerdefinierten Ressource nicht konfiguriert oder null ist.
    • OTEL_TRACES_SAMPLER_ARG: Gibt das Trace-Stichprobenverhältnis an (zwischen 0,0 und 1,0). Wenn sie nicht in der benutzerdefinierten Ressource konfiguriert ist, wird 1.0 verwendet.
  • Verzögerungsintervall zwischen dem Start von zwei aufeinanderfolgenden Messwertexporten.
    • OTEL_METRIC_EXPORT_INTERVAL: Das Zeitintervall (in Millisekunden) zwischen dem Start von zwei Exportversuchen (Min.: 5.000, Max.: 300.000, Standard: 30.000).
  • Deaktivierung des OTLP-Telemetrieexports nach Signaltyp. Signal-Exporter sind deaktiviert, wenn tracer_provider, meter_provider oder logger_provider in der benutzerdefinierten Instrumentation-Ressource 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 der Wert auf none festgelegt ist. Standardwert: otlp
  • Identifizierung von hostNetwork-Pods, um die Metadaten mit dem Kubernetes-Attributprozessor des OpenTelemetry Collectors zu verknüpfen.
    • 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-Attributprozessor Metadaten wie k8s.namespace.name, k8s.deployment.name und k8s.node.name mit hostNetwork-Pods verknüpfen kann. Durch die Verknüpfung 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 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 Befehlszeilen-Flags verwenden.

Wir raten davon ab, für dieselbe Arbeitslast sowohl die manuelle als auch die automatische Konfiguration zu verwenden, da die automatische Konfiguration manuelle Änderungen überschreiben kann. Diese Kombination kann es schwieriger machen, Änderungen an der Konfiguration nachzuverfolgen.

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 Standard-OpenTelemetry-Umgebungsvariablen konfiguriert sind. Das Agent Development Kit (ADK) unterstützt beispielsweise OpenTelemetry nativ.

Weitere Informationen dazu, wie die Laufzeitverhaltensdaten Ihrer Anwendung generiert und erfasst werden, finden Sie unter Beobachtbarkeit für Anwendungsentwickler.

Wenn eine Arbeitslast einige Arten von OTLP-Daten unterstützt und andere nicht, erfasst Managed OpenTelemetry for GKE die OTLP-Daten. Wenn eine Arbeitslast beispielsweise das OpenTelemetry SDK zum Implementieren von Traces verwendet, aber nicht für Logs oder Messwerte, werden Log- und Messwertdaten nicht von Managed OpenTelemetry for GKE erfasst. Weitere Informationen dazu, wie Sie die Art der zu erfassenden Daten steuern, 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, 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 Google Cloud Managed Service for Prometheus-Messwerten finden Sie unter Google Cloud Observability-Preise.

Kontingente

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

Nächste Schritte