随着 OpenTelemetry 在可观测领域影响力的不断提升，其项目以极快的速度不断演进。过去几年，阿里云在 OTel 社区中积极推动技术共享与代码贡献，深度融入社区多个关键领域，如 Semantic Conventions（可观测标准规范建设）、Java Instrumentation（Java 探针）、Go Instrumentation（Go 探针）、Profiling（性能分析）等。截至目前，我们累计向社区贡献并合并了1000+ PR Reviews 与400+ Pull Requests。在这一开源贡献进程中，我们成功培养出3 位 Maintainer、5 位 Approvers、1 位 Triager 以及 8 位 Member。在 OpenTelemetry 项目的贡献榜亚太地区排名第一。

在 2025 KubeCon China[1]会议中，阿里云可观测工程师饶子昊（铖朴）和来自社区的其他贡献者一起在社区的 Governance/Technical Committee 成员支持推荐下，为大家带来了《OpenTelemetry Project Updates》[2]的演讲分享，介绍过去一年社区在各个子项目中的一些最新更新，本文是相关分享对应的中文整理。

Semantic Conventions与数据采集组件

OpenTelemetry 作为当今业界可观测领域的事实标准，其旨在指导相关行业从业者如何创建和管理诸如 Traces、Metrics、Logs 和 Profiles 等各种维度可观测数据。

它专注于数据的生成、收集、管理和导出。其主要目标是，无论应用程序或系统使用何种编程语言、采用何种基础设施或运行在何种环境中，用户都能轻松地使用它对其进行观测。

厂商和工具无关性也是其核心特点，这意味着它可以与各种各样的可观测性后端配合使用，包括像 Jaeger 和 Prometheus 这样的开源工具，以及外部各种各样的商业化产品。

Semantic Convensions 作为 OpenTelemetry 的核心与灵魂。它相当于可观测数据收集工具实现的参考手册，通过定义不同对象分别需要采集哪些内容，记录成为什么字段，所对应的数据格式，采集强制性等内容，指导各种语言 SDK 或者 Intrumentation 如何去实现对相关数据的采集。 如图所示，在一个简单的客户端/服务器示例中，无论是在 Client 还是 Server，应该收集的属性包含服务器地址（server.address）和服务器端口（server.port）。 右侧是 OpenTelemetry 语义约定中 HTTP 服务器跨度（Http Server Span）的部分定义示例。

OTel Semantic Conventions 项目涉及9个SIGs，74个领域，900+ attributes，在社区维护者们过去几年的共同努力下，目前 Database Client、Code.*attributes和System metrics 领域的语言规范已经处于Stable状态，社区维护者们正在努力将 RPC、Messaging 等方面的语义规范建设成Stable态。另外一些较新的可观测领域，如 CI/CD、GenAI和Browser and mobile 等，在过去1年也有很多新内容。

Profiles 作为一种新的可观测数据类型，过去两年，在相关数据的标准规范演进，相关子项目迭代演进上发展速度很快。

作为一种在运行时动态检查应用程序代码的行为和性能的方法，对应用性能诊断非常有价值。

例如，如上右侧上半部分所示，通过采集的应用程序 Metrics 数据，可能会发现存在一些 CPU 或者内存使用波动曲线，如果要定位产生相关波动背后的原因。Profiles 可以通过采集相关线程的申请相关资源的方法栈信息，绘制对应资源的使用的火焰图等方式，确定相关时段特定资源波动产生的根因。

此外，如上右侧下半部分所示，使用 SDK 或者 Auto Instrumentation 方式对应用进行手动或者自动埋点，采集应用调用链的方式，考虑到性能和可操作性，一般只能在一些主流开源框架，比如 Spring Boot、MySQL等的核心功能方法执行前后插入一些可观测代码，以便在应用运行过程中采集到对应的调用链执行信息，进行链路追踪。但针对应用中埋点未覆盖的位置，可能会出现监控盲区，其具体的执行耗时可能会无法确定从而导致稳定定位陷入瓶颈。有了 Profiles 之后，可以对相关执行业务请求线程，通过周期性的采集方法栈信息，另辟蹊径地获取到一个请求执行全过程的完整耗时分布情况，从而作为互补，很好地解决 Traces 所存在的监控盲区问题。

从 2022年 KubeCon + CloudNativeCon Europe 2022 之后相关 SIG 小组的创立以及相关方案的讨论开始，相关领域的演进速度如上 Slide 所示在过去两年明显加快。过去一年项目团队，主要集中力量首先在 OTel Collector 中支持相关数据格式接收相关数据，对相关内容进行落地验证。在 Profilers 领域，接下来，项目团队正在努力为实现一个稳定的 Profiles 数据规范以及技术实现而努力。

除了Profiles，过去一年社区在各种语言的 SDK 或者 Instrumentation 方面也有很多的新进展。

首先，就Java而言，去年年底，OTeI Spring Boot Starter正式发布了稳定版本。作为 OTeI Java Instrumentation 和 SDK 的补充，它为 Spring 用户提供了一种更为熟悉的接入方式。用户只需添加一个依赖项并进行一些简单的配置，就能为 Spring 应用程序生成 OTeI 格式的监控数据。以下是一些常见的使用场景： 除了支持更快的启动开销和一些与 Spring 相关的原生配置之外，对 Spring Boot Native Image 应用程序的原生支持也是一大亮点。

右侧展示的是目前 OTeI Spring Boot Starter 所支持的组件以及相应的配置。

Java 领域另一个有趣的更新是对声明式配置的支持。声明式配置定义了相关工具，使用户能够依据基于文件的标准化配置数据模型表示形式来加载 OpenTelemetry（OTel）组件。

它包含三个部分：数据模型、检测配置 API 和配置 API。借助声明式配置，用户可以直接根据上述右图所示的配置格式，通过定义各种配置内容对 OTel Java Agent或者 SDK 进行行为进行设置。

在 Golang 语言的数据收集工具方面，在过去一年，Golang 编译时插桩无疑是社区在相关领域发展中一个令人振奋的时刻。社区收到了来自阿里巴巴和 Datadog 的两份相关实现捐赠提案。今年年初，由阿里巴巴、Datadog 和 Quesma 共同发起成立了一个与供应商无关的 Go 编译时插桩特别兴趣小组（SIG），目前该小组正在汇聚各方力量，以实现 Go 应用程序的零代码、与供应商无关的编译时插桩。

Golang 编译时插桩其基本思想是通过在 Go 语言编译阶段插入可观测增强逻辑，让 Go 语言在完成编译后，就生成了一个包含可观察增强逻辑的 Go 应用。

在 GenAI 方面，过去一年除了对 OpenAI、VertexAI 等相关框架的增强支持外，Agent 和 MCP 相关 Semantic Conventions 分别处于开发和 Review 状态中。目前相关领域也有了亚太时间友好的周会，欢迎大家参与到相关领域内容建设中来。

OTel Collector

除了 Semantic Conventions 语义规范和数据采集模块，OTel 中另外一个核心部分就是其提供的数据转发与处理组件 OTel Collector。

OTel Collector 具备厂商无关特点，其用于接收、处理和导出遥测数据。它消除了运行、操作和维护多个代理/收集器的需要。它具有更好的可扩展性，并支持开源可观测性数据格式（例如 Jaeger、Prometheus、Fluent Bit 等）发送到一个或多个开源或商业后端。

在 Kubernetes 里，容器和 Pod 中的应用，由于随时可能创建、销毁或迁移。传统监控需要手动配置规则（比如 “当发现 80 端口的 NGINX Pod 时，启用 NGINX 监控”），但如果有新的应用类型（如 Apache 服务器）需要监控，就必须修改 Collector 配置、走代码变更和部署流程，甚至重启服务，非常麻烦。

针对上述问题，OpenTelemetry Collector 最新支持通过 Kubernetes 的 Pod 注解来自动配置监控规则。其通过 Kubernetes API 实时监测集群中 Pod 的变化，获取 Pod 的元数据（包括注解）和端点信息（如端口、IP）。根据 Pod 的注解，自动生成对应的监控接收器（如 NGINX 接收器），并填入从 K8s 获取的端点信息和自定义配置，整个过程无需手动修改 Collector 的主配置文件。该特性大大提升了动态环境下的可观测性管理效率，尤其适合需要频繁部署新应用的团队。

OTel Weaver

正如上文介绍的 Semantic Conventions 作为整个 OTel 的核心，因此，在社区有一个专门的项目叫 OTel Weaver 来实现轻松地开发、验证、记录和部署语义约定，接下来，着重介绍其相关使用实践, 以便帮助了解社区如何使用和管理 Semantic Conventions。

它通过一个语义约定注册表作为输入，这个注册表可以是官方的，也可以是自定义的模式注册表。它由策略引擎、模板引擎、社区插件和解析处理4部分组成。

首先，该工具可以实现快速基于 markdown 格式模版生成格式清晰、内容完整的对外用户使用文档，帮助外部用户使用和学习 OTel Semantic Conventions。

另外，它可以帮助生成开箱即用的各语言 SDK，在各个语言的 Instrumentation 或 SDK 中可以通过相关依赖，帮助更便捷地采集相关数据。

在内容检查校验方面，其不仅支持常规的静态语义内容校验，其还提供了运行时检查能力。通过 live-check 命令，Weaver 会启动一个 OTLP 监听器，用户可以配置应用程序或 OTEL 收集器将数据发送给 Weaver。它会将接收到的消息与所设模式注册表进行比对，检查实时数据是否与定义的模式相匹配。

当退出进程时，它会提供一份覆盖率报告，指出诸如未定义的非法内容、类型错误等问题。它还会给出一个注册表覆盖率百分比，显示已定义的模式中有多少得到了实现。这可以集成到你的 CI/CD 管道中，以实现持续验证。

另外，通过 Weaver，可以直接基于所定义的语言内容，基于上述命令生成开箱即用的 Mock 测试数据。

除此之外，Weaver 还提供了针对 Semantic Conventions 的更变 diff 功能，一条命令就可以生成 diff 日志，不仅可以帮助维护者了解相关变更的准确性，还可用于在不同存储和解析系统中提供数据不同版本的转换和解析效果。

最后，欢迎大家了解和尝试使用 OTel Weaver，用其帮助你更好的维护可观测 Semantic Conventions !

演讲相关资料

1. KubeCon China 2025: https://kccncchn2025.sched.com/
2. OpenTelemetry Project Updates 2025: https://sched.co/1x5hN
3. GenAI: https://opentelemetry.io/blog/2024/otel-generative-ai/
4. RPC Semantic Conventionsstabilization project:https://opentelemetry.io/blog/2025/stabilizing-rpc-conventions/
5. OTel Weaver: https://github.com/open-telemetry/weaver/
6. OTel Profiling updates: https://opentelemetry.io/blog/2024/state-profiling/
7. OTel Java Spring Boot Starter:https://opentelemetry.io/blog/2024/spring-starter-stable/
8. Go compile-time Instrumentation: https://opentelemetry.io/blog/2025/go-compile-time-instrumentation/
9. Kubernetes annotation-based discovery: https://opentelemetry.io/blog/2025/otel-collector-k8s-discovery/
10. OTTL playground: https://github.com/elastic/ottl-playground