OpenChoreo nutzt OpenTelemetry zur Persistenz von Kubernetes-Ereignissen und Traces

OpenChoreo, ein CNCF-Sandbox-Projekt, hat den OpenTelemetry Collector in seine Internal Developer Platform integriert, um häufige Herausforderungen bei der Observability zu lösen. Dieses Update, das Ende Oktober 2026 veröffentlicht wurde, ermöglicht es Plattform-Teams, verteilte Traces zu erfassen und Kubernetes-Ereignisse dauerhaft zu speichern, die andernfalls vom API-Server verschwinden würden.

Was passiert ist

Internal Developer Platforms zielen darauf ab, einen optimierten Weg vom Code bis zur Produktion bereitzustellen, doch die Observability bleibt oft eine fragmentierte Belastung. Entwickler stehen vor einer Flut an Tools, komplexen Verdrahtungsanforderungen und isolierten Dashboards. OpenChoreo adressiert dies durch die direkte Einbettung der Observability in seine Architektur und nutzt den OpenTelemetry Collector als Kern-Engine für zwei kritische Funktionen: verteiltes Tracing und persistente Kubernetes-Ereignisse.

Die Plattform ist in verschiedene Ebenen (Planes) strukturiert, die auf Kubernetes laufen. Eine Control Plane verwaltet den Zustand, während Data Planes Workloads handhaben. Eine optionale Workflow Plane steuert Builds und Tests, und eine dedizierte Observability Plane sammelt Telemetriedaten. Diese Trennung ermöglicht es der Observability-Schicht, unabhängig zu operieren und Logs, Metriken, Traces und Ereignisse zu sammeln, ohne die Anwendungsleistung zu beeinträchtigen. Das System nutzt eine hexagonale Architektur, die Standard-APIs für die Aufnahme (Ingestion) und Adapter-Schnittstellen für Storage-Backends bereitstellt. So können Teams Anbieter wie OpenSearch oder AWS X-Ray über Helm Charts austauschen, statt Code ändern zu müssen.

Wie es funktioniert

Für das verteilte Tracing nutzt OpenChoreo die standardmäßigen OpenTelemetry SDKs. Anwendungen exportieren Spans über OTLP an einen lokalen Collector in jedem Data Plane. Die Pipeline empfängt diese Spans zunächst und reichert sie dann mit dem k8sattributes Processor an. Dieser Schritt ordnet Spans ihren Ursprungs-Pods zu und fügt Kubernetes-Metadaten hinzu, wobei technische Details auf OpenChoreo-Konzepte wie Projekt und Umgebung abgebildet werden. Ein tail_sampling Processor wertet anschließend ganze Traces aus, bevor er entscheidet, welche behalten werden, was kontextbewusste Sampling-Entscheidungen sicherstellt. Schließlich werden die angereicherten Traces an einen zentralen Collector oder direkt an Cloud-Backends exportiert.

Kubernetes-Ereignisse stellen eine andere Herausforderung dar, da sie kurzlebig sind und nicht auf dieselbe Weise an spezifische Pods gebunden sind wie Traces. Der API-Server behält sie typischerweise nur für eine Stunde. OpenChoreo setzt eine zweckgebundene Collector-Distribution ein, um dieses Problem zu lösen. Ein Single-Replica-Collector nutzt den k8s_events Receiver, um clusterweite Ereignisse zu überwachen. Ein benutzerdefinierter Processor, k8seventenrich, sucht Objekt-Labels und Annotationen aus In-Memory-Informer-Caches heraus und fügt sie als Resource Attributes hinzu, ohne den API-Server wiederholt zu belasten. Diese angereicherten Ereignisse werden dann gebündelt und an dauerhafte Log-Backends gesendet, wodurch sie lange nach Ablauf der Standard-Aufbewahrungsfrist für die Post-Incident-Analyse verfügbar bleiben.

Wichtige Details

• OpenChoreo ist eine modulare, Open-Source-Internal-Developer-Platform, die sich derzeit in der CNCF Sandbox befindet.
• Die Observability Plane nutzt eine hexagonale Architektur mit Adapter-APIs zum Austausch von Storage-Backends.
• Verteiltes Tracing verwendet tail_sampling, um Aufbewahrungsentscheidungen basierend auf dem vollständigen Trace-Kontext zu treffen.
• Ein benutzerdefinierter k8seventenrich Processor fügt Kubernetes-Labels und Owner References Ereignissen unter Verwendung von In-Memory-Caches hinzu.
• Unterstützte Tracing-Backends umfassen OpenSearch, OpenObserve, AWS X-Ray, Azure Application Insights und Google Cloud Trace.
• Die Events-Collector-Distribution unterstützt Exporter für OpenSearch, OTLP, AWS CloudWatch Logs und Debug-Ausgaben.

Warum es wichtig ist

Für Plattform-Ingenieure besteht der Hauptvorteil in der Reduzierung des operativen Reibungsverlusts. Durch die Standardisierung auf OpenTelemetry vermeidet OpenChoreo Vendor-Lock-in und reduziert den Bedarf an benutzerdefiniertem Instrumentierungscode. Die Möglichkeit, Backends über Konfiguration auszutauschen, bedeutet, dass Teams sich an veränderte Kosten- oder Compliance-Anforderungen anpassen können, ohne die Plattform refactorn zu müssen. Darüber hinaus ermöglicht die Integration von KI-Agenten über MCP-Server automatisierten Debugging-Tools den Zugriff auf dieselben reichhaltigen Trace-Daten, die menschliche Entwickler sehen, was die Incident-Bearbeitung beschleunigen kann.

Die Persistenz von Kubernetes-Ereignissen ist besonders wertvoll für die Diagnose von Infrastrukturproblemen. Probleme wie Throttling aufgrund von Ressourcenlimits oder Scheduling-Fehler hinterlassen oft keine Spuren in Anwendungslogs. Durch das Erfassen und Anreichern dieser Ereignisse gewinnen Plattform-Teams Sichtbarkeit in den Lebenszyklus von Deployments und Jobs. Dies verwandelt ephemeres Cluster-Rauschen in eine zuverlässige Audit-Trail-Historie und hilft Teams zu verstehen, warum ein Deployment fehlgeschlagen ist oder warum ein Dienst während Spitzenlast unerwartet skaliert hat.

Was Sie tun können

• Stellen Sie die GCP-Microservices-Demo auf OpenChoreo bereit, um verteiltes Tracing über mehrere Services hinweg zu testen.
• Installieren Sie das Modul observability-events-otel-collector über das bereitgestellte Helm Chart, um mit der Erfassung persistenter Ereignisse zu beginnen.
• Konfigurieren Sie den tail_sampling Processor so, dass nur Traces mit Fehlern oder hoher Latenz gespeichert werden, um Speicherkosten zu optimieren.
• Nutzen Sie den k8sattributes Processor, um rohe Kubernetes-Metadaten auf Ihre internen Projekt- und Umgebungslabels abzubilden.
• Erkunden Sie die Tabs „Traces“ und „Events“ im OpenChoreo-Portal, um die Anwendungsleistung mit clusterseitigen Aktivitäten zu korrelieren.
• Prüfen Sie den Code des benutzerdefinierten k8seventenrich Processors, wenn Sie die Event-Anreicherungslogik für Ihre spezifischen Cluster-Objekte erweitern müssen.