什么是 OpenTelemetry
OpenTelemetry（简称 OTel）是 CNCF 下的可观测数据采集标准，提供统一的 API 与 SDK 来生成指标、日志与追踪，并用 OTLP 协议把数据发送到任意兼容后端。它的核心价值是采集与后端解耦：埋点一次，后端可替换，避免每个供应商都重做一轮埋点。配套的语义约定给出了属性命名规范，让不同服务的字段可以横向对比。
基本信息
| 组成 | API、SDK、Collector、语义约定（Semantic Conventions） |
|---|---|
| 协议 | OTLP（gRPC 或 HTTP），Collector 负责接收、处理与导出 |
| 三类信号 | Trace 追踪、Metric 指标、Log 日志 |
| 落地顺序 | 先统一资源属性与命名约定，再接仪表盘与告警 |
典型使用场景
- 多语言技术栈：各语言用同一套 SDK 与协议，命名与字段口径统一
- 后端替换：用 Collector 统一出口，切换观测后端时业务代码不改
- 数据加工：在 Collector 做采样、属性增补与多路导出
- 成本控制：按服务与错误状态做尾部采样，降低无用数据量
- 跨系统追踪：把追踪上下文注入消息与任务，串起异步链路
- 指标标准化：按语义约定命名，避免同名不同义或同义不同名
Collector 配置片段
Collector 配置片段
receivers:
otlp:
protocols:
grpc: {}
http: {}
processors:
batch: {} # 批量发送，降低导出压力
memory_limiter: # 内存保护，避免采集器被压垮
check_interval: 1s
limit_percentage: 75
exporters:
otlphttp:
endpoint: http://backend:4318
service:
pipelines:
traces:
receivers: [otlp]
processors: [memory_limiter, batch]
exporters: [otlphttp]三类信号与用途
| 信号 | 回答什么问题 | 常见用法 |
|---|---|---|
| Trace | 这次请求慢在哪一步 | 定位单次调用的瓶颈与错误 |
| Metric | 整体趋势是否异常 | 容量规划、告警与趋势分析 |
| Log | 具体发生了什么 | 错误细节与审计留痕 |
埋点语义约定先行的收益更高：字段命名不一致时，查询、面板与告警都要为每个服务单独适配，采集标准化省下的工作量远大于它本身。
采集器自身要有内存与队列保护：没有限流与丢弃策略时，后端故障会把采集器拖垮，反过来影响业务进程。
采样策略要按业务分级：核心交易链路提高采样率保留完整证据，高频读接口降低采样率控制成本，错误与慢请求则强制保留，保证排查时样本可用。
从埋点到上线需要三步：先在试点服务接入 SDK 并统一资源属性，再接入采集器做加工与多路导出，最后才连仪表盘与告警，顺序颠倒会造成面板反复重建。