CNCF OpenTelemetry 治理成熟后如何划分 Collector 配置与业务埋点责任

OpenTelemetry 进入 CNCF Graduated 阶段后，团队更容易把它当成“平台统一接入”的基础设施，但治理成熟不等于所有配置都归平台团队。实际落地时，最稳妥的切法是：应用团队负责业务语义和埋点质量，平台团队负责 Collector 的传输与处理管道，观测平台或 SRE 负责查询、告警和容量规则。

官方地址：https://opentelemetry.io/

先把 OpenTelemetry 的三层责任边界画清

先按信号流向划三层，比按“谁部署了进程”划分更不容易扯皮。第一层是应用代码：它知道一次下单、库存锁定或消息消费代表什么，应该补充业务 span、关键指标和必要日志。第二层是 Collector：它接收 OTLP 等输入，执行批处理、过滤、属性补充、路由和导出。第三层是后端消费：它维护查询视图、告警阈值、保留策略和看板。

这个边界也解释了为什么不能把所有问题都写进 Collector。平台可以删除高风险属性、统一 resource attributes、限制队列和出口；却无法可靠判断“订单支付成功”与“支付请求发出”的业务含义。

用组件和信号类型分配配置归属

Collector 配置可以拆成“平台默认层”和“服务接入层”。平台默认层包括 receivers 的监听方式、processors 的资源限制与脱敏、exporters 的出口、队列和重试；服务接入层只声明需要进入哪条 pipeline、服务名和环境等资源信息。两层都进入配置仓库，变更通过评审合并，避免在部署平台上手工改出漂移。

Collector 只处理管道，业务团队维护可解释的信号

一个最小的 Collector pipeline 可以这样表达。下面的 YAML 是配置形状示例，重点在责任归属，不绑定某个发行版的完整组件清单：

receivers:
  otlp:
    protocols:
      grpc: {}

processors:
  batch:
    send_batch_size: 512 # 平台团队根据吞吐和内存压测调整
  resource:
    attributes:
      - key: deployment.environment
        value: prod
        action: upsert # 统一环境字段，避免服务各写一套

exporters:
  otlp:
    endpoint: observability.example:4317 # 凭据应来自部署系统，不写入仓库

service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: [resource, batch]
      exporters: [otlp]

应用侧不要为了适配这段配置而把业务名改成平台喜欢的字段。应用团队应使用稳定的 span 名称和属性，例如把“锁库存”作为明确的业务操作，并记录成功、拒绝、超时等结果；平台团队再对高基数属性、敏感字段和出口容量做统一治理。OpenTelemetry 的 zero-code 方式适合快速覆盖库调用和运行环境，但业务代码的关键语义仍需要 code-based instrumentation 补齐。

用变更检查清单把双方连起来

每次新增服务或修改 Collector 时，按下面四项走一遍，通常比建立一份巨大总规范更有效：

1. 确认输入：服务能通过约定协议送到正确 receiver，service.name、版本和环境字段可识别。
2. 确认处理：processors 的过滤、脱敏、批处理和内存边界不会删除业务必需字段，也不会放大高基数标签。
3. 确认语义：应用团队说明每个关键 span 或指标代表的业务动作、成功条件和异常含义，instrumentation scope 可追溯到模块或库。
4. 确认恢复：先对单服务或单 pipeline 灰度，观察拒收、队列积压和导出失败，再扩大范围；配置与埋点都能独立回滚。

责任边界的核心不是限制谁能改文件，而是让改动具备可解释的 owner。平台团队可以提供模板和默认 processors，应用团队可以提交业务字段；涉及语义变更时，双方评审同一个变更单，避免 Collector 把“能收到”误当成“有用”。

常见问题

Collector 能不能直接生成业务指标？

它可以处理、聚合或转换已有信号，但不应凭字段猜测业务事件。业务指标的定义和来源应由应用团队确认。

零代码采集后还需要手工埋点吗？

需要。零代码通常先覆盖请求、数据库和消息队列等边缘调用，订单状态、风控决策等应用内部语义仍要用代码埋点表达。

Resource attributes 由谁最终拍板？

平台团队维护字段规范和注入方式，应用团队提供 service.name、版本等真实值；两方共同保证查询可用且不互相覆盖。