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 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 Prompt- und Antwortdaten.

    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. 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 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

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

Verwaltete Sammlung

Bei der verwalteten Sammlung 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 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

Durch die automatische Konfiguration können Arbeitslasten, die in GKE ausgeführt werden, Signale an den Endpunkt des verwalteten Collectors senden.

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 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

Mit der benutzerdefinierten Instrumentation-Ressource haben Sie folgende Möglichkeiten:

  • 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 erhobenen Daten (Logs, Messwerte und Traces) festlegen.
  • Sie können festlegen, wie oft Messwertdaten an den verwalteten Collector gesendet werden.
  • Abtastrate für Trace-Daten 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 im Cluster mit dem Instrumentation-Objekt 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 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 Instrumentation-Ressource ab.

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

  • OpenTelemetry-Exporteur-Endpunkt.
    • OTEL_EXPORTER_OTLP_ENDPOINT: Eine Basis-Endpunkt-URL für jeden Signaltyp. Dieser Endpunkt verweist immer auf den im Cluster verwalteten OpenTelemetry-Collector-HTTP-Endpunkt für Logs, Messwerte und Traces. Der Endpunkt lautet: http://opentelemetry-collector.gke-managed-otel.svc.cluster.local:4318.
  • 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-Erfassung 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 (zwischen 0,0 und 1,0) an. Wenn sie in der benutzerdefinierten Ressource nicht konfiguriert ist, wird 1.0 verwendet.
  • Verzögerungsintervall zwischen dem Beginn von zwei aufeinanderfolgenden Messwertexports.
    • 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. 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 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 Verknüpfung von Metadaten und hostNetwork-Pods können die extrahierten Metadaten Spans, Messwerten und Logs als Ressourcenattribute hinzugefügt werden.
  • Prompts und Antworten.
    • OTEL_INSTRUMENTATION_GENAI_UPLOAD_FORMAT='jsonl': Weisen Sie OpenTelemetry an, Cloud Storage-Objekte als JSON-Zeilen zu formatieren. Diese Umgebungsvariable hat einen festen Wert: jsonl.
    • OTEL_INSTRUMENTATION_GENAI_COMPLETION_HOOK='upload': Weisen Sie OpenTelemetry an, Aufforderungs- 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': Weisen Sie 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 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 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 erhoben werden, finden Sie unter Instrumentierung und Beobachtbarkeit.

Wenn eine Arbeitslast einige Arten von OTLP-Daten unterstützt, andere jedoch nicht, werden die OTLP-Daten von Managed OpenTelemetry für 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 für 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-Konfigurationsinjektion 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 für GKE verwenden, gelten die Kontingente für Google Cloud Observability-Dienste. Entsprechende Details finden Sie hier:

Nächste Schritte