把可观测性做成平台能力：OpenChoreo 用 OpenTelemetry 打通分布式追踪与 K8s 事件持久化

代码从编辑器走到生产环境，要经历构建、测试、部署，然后在真正跑起来之后还得看懂它在干什么。内部开发者平台（IDP）承诺给开发者一条”黄金路径”，让大家专注业务逻辑而不是接线。可观测性是这条路上绕不开的一环——但工具太多、组件太多、仪表盘太多，可观测性本身已经变成了一个”平台问题”。CNCF Sandbox 项目 OpenChoreo 给出的答案是：把 OpenTelemetry Collector 做成平台底座，撑起两个平台级能力——分布式追踪，以及持久化、带富化元数据的 Kubernetes 事件。

OpenChoreo 是什么：按”平面”拆开的 Kubernetes IDP

OpenChoreo 是一个模块化的开源 IDP，构建、部署、观测、保护应用开箱即用，生态模块可以让平台团队换成自己顺手的工具。它的架构按平面（plane）切分，每个平面都跑在 Kubernetes 上：控制平面管平台状态，一个或多个数据平面跑工作负载，可选的工作流平面跑构建和测试，可观测性平面负责采集和提供观测数据。最上面是体验平面，通过基于 Backstage 的门户、CLI、IDE 集成和 MCP server，同时给人和 AI agent 留了入口。

图：OpenChoreo 的平面架构（图源：CNCF 原文 Figure 1）

Observer：六边形架构，后端随便换

平台团队做可观测性最容易踩的坑，是把平台和某个具体后端绑死。OpenChoreo 的核心组件 Observer 采用六边形（端口与适配器）架构：一侧暴露日志、指标、追踪 API 供门户、CLI 和 agent 查询；另一侧通过公开规范的适配器 API 对接存储后端。每个后端作为一个生态模块单独出货——把追踪数据从 OpenSearch 换到 AWS X-Ray，只需要装另一个 Helm chart，不用动平台。

图：Observer 的六边形架构（图源：CNCF 原文 Figure 2）

追踪流水线：接收、富化、采样、导出

微服务架构里，一个请求扇出到几十个服务，没有分布式追踪根本没法排障。OpenChoreo 的做法是：开发者用标准 OpenTelemetry SDK 给应用埋点、走 OTLP 上报，剩下的交给 Collector 流水线——

• 接收：otlp receiver 摄入 span，Collector 就近部署在每个数据平面，span 在离开所属集群前就地处理；
• 富化：k8sattributes processor 把每个 span 匹配到产生它的 Pod，附上 Kubernetes 元数据。因为 OpenChoreo 给每个部署的工作负载都打了标签，span 能直接映射回平台概念：属于哪个项目、组件、环境；
• 采样：tail_sampling processor 在看到整条 trace 的所有 span 之后再决定留哪些，而不是拿第一个 span 赌全局；
• 导出：富化后的追踪转发给可观测性平面的中央 Collector，或用 googlecloud / awsxray / azuremonitor exporter 直发云后端，otlphttp 覆盖 OTLP 原生后端，认证扩展负责各家凭据。

目前追踪模块支持 OpenSearch、OpenObserve、AWS X-Ray、Azure Application Insights 和 Google Cloud Trace。追踪数据直接出现在门户的 Traces 页签，可按组件、环境、时间范围过滤；可观测性 MCP server 把同一份数据以工具形式开放出来，AI agent 也能拿着分布式追踪去调试应用。

图：门户里的 trace，失败的 10 秒 RecommendationService span 一目了然（图源：CNCF 原文 Figure 3）

K8s 事件：默认只活一小时，事故复盘时往往已经没了

不是所有事故都体现在日志和追踪里。黑五大促扩容失败，往往是因为工作负载撞上了资源上限——证据全在 Kubernetes 事件里。工程师的本能是 kubectl get events，但 API server 默认只把事件保留约一小时，等开始查事故，能解释事故的现场往往已经消失了。

事件还有个特殊难点：它来自 Pod、Deployment、ReplicaSet、Job 等各种对象，没法像 span 那样靠 Pod 关联挂到工作负载头上。OpenChoreo 为此专门做了一个 Collector 发行版，把这条链路补齐：

• 采集：contrib 仓库的 k8s_events receiver 监听全集群事件，Collector 按单副本运行，保证每个事件只记一次；
• 富化：自定义处理器 k8seventenrich 查出事件指向的对象，把它的标签、注解、owner 引用复制成事件资源属性（k8s.object.label.<key>、k8s.object.annotation.<key>、k8s.object.owner.{kind,name,uid}），所有查询都走集群级内存 informer 缓存，事件路径上不新增 API server 调用；
• 导出：经 batch processor 写入持久化日志后端，内置 OpenSearch、OTLP（gRPC/HTTP）、AWS CloudWatch Logs 和 debug exporter。

图：事件流水线与 k8seventenrich 自定义处理器（图源：CNCF 原文 Figure 4）

由于富化用的标签就是 OpenChoreo 自己的标识，门户能在每个组件的 Events 页签里直接展示”这个组件”的事件，带着完整的项目/组件/环境上下文——事件从此是一层持久的观测数据，而不是一小时就蒸发的临时品。

图：门户里按组件聚合的 K8s 事件（图源：CNCF 原文 Figure 5）

安装就是一个 Helm 命令：

helm upgrade --install observability-events-otel-collector \
  oci://ghcr.io/openchoreo/helm-charts/observability-events-otel-collector \
  --namespace openchoreo-observability-plane --create-namespace \
  --version 0.2.0

为什么是 OpenTelemetry

原文给了四条理由：厂商中立（OTLP 是开放标准，Collector 中立、厂商普遍支持）；组件齐全（receiver/processor/exporter 目录覆盖了大部分需求，流水线基本是配置不是代码）；多语言 SDK（开发者用什么语言埋点平台不用管）；核心可扩展（没有现成组件时，在 core 发行版上写一个小的、可测试的 Go 处理器就行——k8seventenrich 正是这么来的，团队计划把它反哺给 OpenTelemetry 社区）。

上手路径：官方提供 GCP microservices demo 样例，把 Google 的微服务演示整套跑在 OpenChoreo 上，就能跟着一个请求跨服务找瓶颈，再回看部署动作背后集群真实做过什么。

小夏点评

• “事件只活一小时”是 K8s 生态的老大难，这个方案值钱在工程分寸感：事件富化全部走 informer 内存缓存，不在事件路径上给 API server 加一次调用——排障能力是补上了，控制平面没被拖下水。
• 六边形架构 + 模块换后端，把”选哪家可观测性厂商”从平台级押注降级成一次 Helm upgrade，国内团队做技术选型时最怕的锁定问题，这套设计给了一个可抄的模板。
• 对国内 IT 运维/开发者的启示：可观测性正在从”装个 agent”变成”平台产品”——先把标签体系这种地基打好，让追踪和事件自动带业务上下文，再谈仪表盘；连 AI agent 调试都预留了 MCP 入口，地基打对了，后面每一层能力都是白捡的。

参考链接

• 原文：https://www.cncf.io/blog/2026/10/27/opentelemetry-powered-distributed-tracing-and-kubernetes-events-in-openchoreo/
• OpenChoreo 官网：https://openchoreo.dev/
• 事件 Collector 发行版（生态模块）：https://github.com/openchoreo/community-modules/tree/main/observability-events-otel-collector
• GCP microservices demo 样例：https://github.com/openchoreo/openchoreo/tree/main/samples/gcp-microservices-demo
• OTel in Practice 分享视频：https://www.youtube.com/live/yyJmBj8k7mk