方案文档里写「接 OpenTelemetry」，评审的人却把看板、告警、长期存储也算进同一行交付。准备给服务补 tracing 或 metrics 时，这句话很常出现。有人听完以为装上它就等于有了监控平台：能存、能查、能画板。翻官方定义会发现，它管的那一层和 Jaeger、Prometheus 或商业后端并不重叠。
官方怎么给它下定义
What is OpenTelemetry? 写得很干脆：OpenTelemetry 是一套可观测性框架与工具包，用来方便地生成、导出、采集 traces、metrics、logs。它开源，并且对厂商、工具保持中立，可以接到多种后端——文档举例包括开源的 Jaeger、Prometheus，以及各类商业产品。同一段里有一句需要划线：OpenTelemetry 本身不是观测后端。
页面还把可观测性说成：通过系统对外输出（遥测数据）理解内部状态。要让系统可观测，代码或运行时得先被 instrument，再把数据送到某个后端去存和看。存储（backend）和展示（frontend / 可视化）被有意留给别的工具。
它实际由哪些块组成
官方列出的主要组件大致是：
- 各组件共用的规范（specification）
- 描述遥测数据形状的标准协议（常见落地是 OTLP）
- 语义约定：给常见字段一套稳定命名
- API：规定怎么产生遥测
- 各语言 SDK：实现规范、API 与导出
- 常见库 / 框架的埋点生态，以及少改业务代码的自动埋点
- OpenTelemetry Collector：接收、处理、再导出遥测的代理
- 周边还有 Kubernetes Operator、Helm Charts、FaaS 相关资产等
历史一节补充：它是 CNCF 项目，由 OpenTracing 与 OpenCensus 合并而来，两边当年都想解决「埋点与上报缺少统一标准」的问题，合并后希望只学一套 API 与约定。文档也强调两点原则：你有自己产生的数据、避免被单一厂商锁死。团队只需学一套 API 与约定。
厂商文档里常把「支持 OpenTelemetry」写成卖点，指的多半是能收 OTLP 或兼容语义约定，并不等于 OTel 替你完成了长期存储和告警规则。选型时把「埋点标准」和「观测产品」分成两行写，后面换存储或加一套开源查询都不至于整层推翻。
落地时容易反的顺序
容易踩的坑是：还没选定语言 SDK 和 Collector 的导出目标，就先在业务里写死某一家的专有 SDK，或者把「上了 OTel」理解成「监控平台已经就绪」。更顺的顺序通常是：
- 先确认要采哪几类信号（trace / metric / log），以及应用语言有没有成熟 SDK
- 中间尽量走 Collector（或等价网关），把采样、过滤、路由留在管道层
- 后端（存储与查询、告警、看板）按团队现有运维能力和预算另选。换后端时最好只改导出配置，而不是重写埋点
扩展性一节也提醒：多数人不必自己改协议，但可以加自定义 receiver、装自定义埋点库、做发行版、给尚未支持 OTLP 的后端写 exporter 等。那是进阶需求，入门阶段把「生成 / 导出 / 采集」和「存储 / 可视化」拆开就够用。
和「先买一套可观测平台再慢慢埋点」相比，OTel 更像先把埋点与导出口径统一，再决定数据落到哪。评审时如果有人把 OTel 和某块看板划等号，把官方那句「不是 backend」拿出来对一下，能少走一轮返工。自动埋点能覆盖的框架因语言而异，缺口仍要靠手动 API。Collector 则适合把采样率、敏感字段过滤、多后端扇出放在管道里改，而不是每个服务各写一份导出逻辑。
你们现在卡在「语言 SDK 怎么埋」，还是卡在「Collector 后面接到哪套存储」？有没有已经把某一家专有 SDK 写进业务、又想迁到 OTLP 的案例想交流？