不修改代码为 Go 项目添加监控
想想有多少次，你仅仅因为要在每个方法中传递 context 太过繁琐，就推迟了在项目中实现完整追踪？更糟糕的是，当你需要追踪第三方库内部的请求路径，而该库的源代码你又无法控制时。在这种情况下，你通常要么得重写一半的业务逻辑来适配 OpenTelemetry API，要么只能接受监控中的"盲区"。
OpenTelemetry 团队似乎找到了消除这种繁琐工作的方法。opentelemetry-go-compile-instrumentation 仓库提供了一个工具，可以在应用构建过程中直接注入遥测数据。
这是什么"魔法"
这个项目是一个实用工具 otelc。它作为标准 Go 编译器的一层封装运行。与其手动导入 OpenTelemetry 库并放置 span，这个工具会在编译时为你完成这些工作。它会找到代码和依赖项中的正确位置，然后在那里插入必要的调用。
这不仅仅是"自动化"——而是一种范式转变。你写的是专注于业务任务的干净代码，而可观测性成为位于其上的基础设施层。
在实践中这有什么用
主要亮点是完全不需要修改源代码。如果明天你决定更换监控供应商或完全放弃追踪，你不需要清理整个项目中数百个导入。
工具的一些有趣能力：
- 与第三方库配合使用。你可以从通过 go.mod 连接的他人代码深处获取追踪数据。
- 零运行时开销。由于代码在构建时注入，程序在执行时不需要为动态分析或反射消耗资源。
- 灵活的集成。该工具可以轻松接入 CI/CD 流水线。本质上，你只需要更改构建命令。
内部工作原理
该工具修改了构建过程。你不再使用熟悉的 go build，而是使用 otelc go build。在底层，该工具会分析代码及其依赖项的抽象语法树（AST）。基于预先描述的规则（插桩规则），它会注入必要的代码片段。
仓库中包含详细的架构指南。如果你对调用替换的具体工作方式以及如何为新库描述规则感兴趣，可以查看 docs/ 文件夹。其中记录了一切：从 API 设计到语义约定。
从哪里开始
首先，你需要构建这个工具本身。这是 Go 项目的标准流程：
git clone https://github.com/open-telemetry/opentelemetry-go-compile-instrumentation.git
cd opentelemetry-go-compile-instrumentation
make build
之后，你将拥有二进制文件 otelc。要测试它的实际效果，你可以运行仓库中的演示应用程序。整个过程简化为一个命令：
cd demo/app/basic
../../otelc go build
./basic
如果一切顺利，你的应用程序将开始生成遥测数据，尽管你不会在其源代码中找到任何关于 OpenTelemetry 的提及。
谁会从中受益
这个项目看起来是维护遗留系统或大型单体应用的绝佳工具，在这些场景中手动实现追踪可能需要数月时间。对于希望保持代码"纯净"、不受基础设施依赖影响的团队来说，这也是一个救星。
但是值得注意的是，这个项目需要理解插桩规则的工作方式。如果你需要标准规则未涵盖的特定功能，就需要深入研究 YAML 配置，甚至可能需要编写自己的钩子。
如果你已经厌倦了围绕 context 和 span 的样板代码，这个工具绝对值得一试。这是迈向现代开发者体验的一步：像可观测性这样的复杂功能可以"开箱即用"，不会妨碍你编写代码。
相关项目