要真正把OpenTelemetry用起来，第一步不是看它怎么发数据，而是看清API、SDK和Collector这三层是怎么分工的。这套严格分离的设计，是整个项目的核心骨架。它保护的不是某一项功能，而是你的应用代码本身——无论遥测的实现方式怎么变，无论后端要切到哪个平台，你的业务逻辑都可以纹丝不动。

API是你直接在代码里引入的依赖。它定义了一套编程模型、数据类型和接口，覆盖Traces、Metrics和Logs的采集。关键是，API内部没有任何操作逻辑，只是一组抽象接口。默认情况下，它返回的全是空实现。也就是说，你在应用里打完点，如果不配置SDK，程序照常运行，不会抛异常，也几乎不会产生任何性能开销。这一步把所有跟业务无关的遥测实现彻底剥离了，开发者只管埋点，完全不用操心数据往哪儿发、怎么发。

打开网易新闻 查看精彩图片

SDK是API的具体实现，它负责状态管理、内存缓冲、采样、处理和导出。通常是在应用启动时通过依赖注入或初始化脚本来加载，再配合Exporter把数据发出去，可以直接推到后端，但更建议的路线是先送给一个中间的Collector。因为批量化、上下文传播、网络通信这些重活全部落在SDK这一层，它的参数配置会直接影响应用的资源消耗。如果在高吞吐场景下把缓冲大小或采样比例配错了，内存耗尽、CPU飙升就是分分钟的事。

Collector是一套独立于应用运行的高性能代理服务，等同一个集中化的遥测管线。它能接收、处理和导出多种格式的数据，包括OTLP、Jaeger、Zipkin和Prometheus。把Collector部署下去，处理开销就从应用进程里卸掉了。每个微服务实例不需要再为不同的后端维护多路连接和序列化任务，只需要通过gRPC或HTTP/2把原始OTLP数据甩给本地或中心化的Collector，剩下的批量、过滤、敏感信息脱敏、多目标路由全部由Collector搞定。

这套架构在应用执行空间和遥测路由基础设施之间划出了一道清晰的边界。内网传输统一走OTLP协议，带来的直接好处是：后端可观测平台想换就换、想拆分就拆分、想复制就复制，全凭改一改Collector的配置就能完成，一行应用代码都不用动。