可观测性不再只是站点可靠性团队的职责；开发者越来越需要在自己编写的代码中添加 traces、logs 和 metrics，以便在应用进入生产环境之前和之后诊断故障并理解应用行为。在 CNCF 博客于 2026 年 8 月 25 日发布的一篇博文中，OpenTelemetry 社区经理兼 CNCF 大使 Adriana Villela，以及 OpenTelemetry 文档认证贡献者兼 CNCF 大使 Diana Todea，介绍了一条使用 OpenTelemetry 来减轻这项任务负担的实用路径。
两位作者从开发者熟悉的反对意见出发：添加 Instrumentation 意味着需要维护更多代码、增加额外复杂性，并可能引入错误或技术债务。不过，她们将这些成本与直接的实际收益联系起来，其中最主要的包括缩短调试时间、加快功能完成和发布、发现缓慢路径、隐蔽的重试以及边界情况，同时还能更好地理解分布式系统。两位作者认为，当应用借助人工智能工具生成且质量参差不齐时，可观测性也有助于拆解这类应用。
先自动化，再补充缺失部分
第一条建议是：只要条件允许，就使用 Zero-code instrumentation。这种机制无需修改源代码即可向应用添加 Instrumentation，方法是在运行时或编译期间拦截常见框架和库的调用。根据该文章，Java、.NET、Python、JavaScript、PHP 和 Go 均提供此类支持。
两位作者并不认为自动化是完整解决方案；它未必知道应用逻辑本身哪些部分最重要。因此，应通过 Manual instrumentation 加以补充，以添加 traces、metrics、logs、上下文传播以及代码特有的属性。她们还建议采用 Observability-driven development，即在编写新代码时同步添加可观测性，而不是几天后再回头处理，因为届时设计细节在开发者脑中的印象已经不那么清晰。
哪些内容值得测量？
- 重要的工作单元：为传入请求（例如 HTTP 调用）、对数据库、缓存、API 和 Queues 的外发连接，以及业务敏感型操作添加 spans。文章提醒，不要为每个细小调用都创建 span，因为这可能产生噪声，掩盖重要信号。
- 有影响的事件：使用日志解释某件事发生的原因，重点关注错误、验证失败、重试和备用路径，以及认证失败、权限拒绝等安全事件。
- 响应时间：延迟指标有助于确定某个请求耗时为何超过通常水平，尤其是在添加商品到购物车再完成结账这类多步骤路径中。
- 内部框架和库：为团队自行开发的框架和库添加 Instrumentation 可能带来广泛覆盖，因为应用的大量部分都会经过这些框架和库。
将人工智能作为助手，而不是审查的替代品
两位作者认为，人工智能辅助编程工具可以缩短探索不同 OpenTelemetry 接口和 SDK 的时间，也能帮助处理旧代码。不过，要从中受益，需要进行精确引导。她们建议明确助手的角色、目标、代码位置和所使用的语言，以及所需的输出，并附上相关文档链接或代码示例。
她们还建议要求代理解释其决策，并在可能的情况下使用另一个代理作为裁判来质疑这些决策，然后反复尝试并改进结果，而不是接受工具提出的第一个修改方案。这些建议反映的是两位作者的观点和经验，并不能保证人工智能生成的代码一定正确或适合应用。
理解遥测数据的本地路径
没有读取生成数据的手段，Instrumentation 就无法完整发挥作用。文章解释说，OpenTelemetry Collector 充当供应商中立的代理，接收来自多个来源的 traces、logs 和 metrics，在需要时对其进行处理，然后将其发送到一个或多个目的地。它由用于接收数据的 Receivers、用于修改属性、隐藏属性或对数据进行采样的 Processors、用于发送数据的 Exporters、用于确定每类信号路径的 Pipelines，以及用于连接两条管道的 Connectors 组成。
针对开发环境，文章建议使用一个简单配置：通过 OTLP，利用 gRPC 或 HTTP 接收数据，并将其导出到 Debug 模块，同时使用 SpanMetrics Connector 将 span 时长转换为 metrics 数据，以帮助监测延迟问题。随后，文章介绍了三种可与 Collector 和 Docker Compose 一起运行的开源工具：用于显示 traces 的 OTel Desktop Viewer；通过终端界面显示 traces、logs、metrics 以及服务关系的 otel-tui；以及通过仪表板显示同样三类信号的 OTel Front。
必须考虑的限制
实践表明，这些工具并非没有障碍。由于两位作者此前已有使用 OpenTelemetry Collector 和 Docker 的经验，她们的配置过程更加容易；而初学者可能会面临更大困难。此外，这些工具依赖第三方维护的开源项目，未必始终跟上最新版本的 OpenTelemetry API 和 SDK，也未必能实现完整的功能对等。
文章还强调了生态系统中更广泛的挑战，包括各语言兴趣小组的活跃程度不同、某些语言（如 Rust 和 Elixir）缺乏自动化支持、SDK、eBPF 和编译时 Instrumentation 之间存在大量选择，以及 API 稳定性、依赖升级和某些属性 Cardinality 过高等问题。
编辑解读：这里的实际价值不在于增加一款新工具，而在于将可观测性从一项被推迟的任务转变为代码开发周期的一部分。这份指南确定了一个低摩擦的起点，然后明确了自动化无法了解的内容。不过，来源没有提供工具之间的量化性能比较，也没有证明某一条路径适用于所有语言或环境；因此，应将这些建议视为起步框架，并对配置进行测试，审查数据量、成本以及其对实际应用的适用性。