OpenChoreo utilise OpenTelemetry pour persister les événements et traces Kubernetes

OpenChoreo, un projet CNCF Sandbox, a intégré le Collecteur OpenTelemetry dans sa Plateforme de Développement Interne (Internal Developer Platform) pour résoudre les défis courants liés à l'observabilité. Publiée fin octobre 2026, cette mise à jour permet aux équipes de plateforme de capturer des traces distribuées et de persister les événements Kubernetes qui disparaissent autrement du serveur API.

Ce qui s'est passé

Les plateformes de développement interne visent à offrir un chemin simplifié du code à la production, mais l'observabilité reste souvent une charge fragmentée. Les développeurs font face à une prolifération d'outils, à des exigences de câblage complexes et à des tableaux de bord décousus. OpenChoreo répond à ce problème en intégrant directement l'observabilité dans son architecture, en utilisant le Collecteur OpenTelemetry comme moteur central pour deux fonctionnalités critiques : le traçage distribué et la persistance des événements Kubernetes.

La plateforme est structurée en plans distincts exécutés sur Kubernetes. Un plan de contrôle gère l'état, tandis que les plans de données traitent les charges de travail. Un plan de workflow optionnel gère les builds et les tests, et un plan d'observabilité dédié collecte les données de télémétrie. Cette séparation permet à la couche d'observabilité de fonctionner indépendamment, collectant logs, métriques, traces et événements sans interférer avec les performances de l'application. Le système utilise une architecture hexagonale, exposant des API standard pour l'ingestion et des interfaces d'adaptateur pour les backends de stockage, permettant aux équipes de changer de fournisseurs tels qu'OpenSearch ou AWS X-Ray via des charts Helm plutôt que par des modifications de code.

Comment cela fonctionne

Pour le traçage distribué, OpenChoreo exploite les SDK OpenTelemetry standards. Les applications exportent des spans via OTLP vers un Collecteur local dans chaque plan de données. Le pipeline reçoit d'abord ces spans, puis les enrichit à l'aide du processeur k8sattributes. Cette étape associe les spans à leurs pods d'origine et attache les métadonnées Kubernetes, reliant les détails techniques aux concepts OpenChoreo tels que projet et environnement. Un processeur tail_sampling évalue ensuite l'intégralité des traces avant de décider lesquelles conserver, garantissant des décisions d'échantillonnage conscientes du contexte. Enfin, les traces enrichies sont exportées vers un collecteur central ou directement vers des backends cloud.

Les événements Kubernetes posent un défi différent car ils sont de courte durée et ne sont pas liés à des pods spécifiques de la même manière que les traces. Le serveur API les conserve généralement pendant seulement une heure. OpenChoreo déploie une distribution de Collecteur conçue spécifiquement pour résoudre ce problème. Un collecteur à réplique unique utilise le receiver k8s_events pour surveiller les événements à l'échelle du cluster. Un processeur personnalisé, k8seventenrich, recherche les labels et annotations des objets dans les caches informer en mémoire, les ajoutant comme attributs de ressource sans solliciter répétitivement le serveur API. Ces événements enrichis sont ensuite regroupés et envoyés vers des backends de logs durables, les rendant disponibles pour l'analyse post-incident bien après l'expiration de la période de rétention par défaut.

Détails clés

• OpenChoreo est une plateforme de développement interne modulaire et open source actuellement dans le CNCF Sandbox.
• Le plan d'observabilité utilise une architecture hexagonale avec des API d'adaptateur pour changer de backend de stockage.
• Le traçage distribué utilise tail_sampling pour prendre des décisions de rétention basées sur le contexte complet de la trace.
• Un processeur k8seventenrich personnalisé ajoute les labels Kubernetes et les références propriétaires aux événements en utilisant des caches en mémoire.
• Les backends de traçage pris en charge incluent OpenSearch, OpenObserve, AWS X-Ray, Azure Application Insights et Google Cloud Trace.
• La distribution du collecteur d'événements prend en charge les exporters pour OpenSearch, OTLP, AWS CloudWatch Logs et les sorties de débogage.

Pourquoi c'est important

Pour les ingénieurs de plateforme, le principal avantage est la réduction des frictions opérationnelles. En se standardisant sur OpenTelemetry, OpenChoreo évite le verrouillage fournisseur et réduit le besoin de code d'instrumentation personnalisé. La capacité de changer de backend via configuration signifie que les équipes peuvent s'adapter aux évolutions des coûts ou des exigences de conformité sans refactoriser la plateforme. De plus, l'intégration d'agents IA via des serveurs MCP permet aux outils de débogage automatisés d'accéder aux mêmes données de traces riches que celles visibles par les développeurs humains, accélérant potentiellement la résolution des incidents.

La persistance des événements Kubernetes est particulièrement précieuse pour diagnostiquer les problèmes au niveau de l'infrastructure. Des problèmes tels que le throttling des limites de ressources ou les échecs de planification ne laissent souvent aucune trace dans les logs applicatifs. En capturant et enrichissant ces événements, les équipes de plateforme gagnent en visibilité sur le cycle de vie des déploiements et des jobs. Cela transforme le bruit éphémère du cluster en une piste d'audit fiable, aidant les équipes à comprendre pourquoi un déploiement a échoué ou pourquoi un service a augmenté de façon inattendue lors d'un pic de trafic.

Ce que vous pouvez faire

• Déployez la démo de microservices GCP sur OpenChoreo pour tester le traçage distribué entre plusieurs services.
• Installez le module observability-events-otel-collector en utilisant le chart Helm fourni pour commencer à capturer des événements persistants.
• Configurez le processeur tail_sampling pour ne conserver que les traces comportant des erreurs ou une latence élevée, optimisant ainsi les coûts de stockage.
• Utilisez le processeur k8sattributes pour mapper les métadonnées Kubernetes brutes à vos labels internes de projet et d'environnement.
• Explorez les onglets Traces et Events du portail OpenChoreo pour corréler les performances applicatives avec les activités au niveau du cluster.
• Examinez le code du processeur k8seventenrich personnalisé si vous devez étendre la logique d'enrichissement des événements pour vos objets de cluster spécifiques.