OpenTelemetry 可观测性入门
OpenTelemetry（OTel）用于生成、收集、处理和导出遥测数据，它本身不是存储和可视化后端。引入 OTel 的价值是统一埋点、上下文传播和数据出口，减少应用被某个监控厂商 SDK 锁定。
一、四类信号
| 信号 | 回答的问题 | 常见内容 |
|---|---|---|
| Trace | 一次请求经过了哪里 | Span、父子关系、耗时、错误 |
| Metric | 系统现在怎样 | 计数器、直方图、资源与业务指标 |
| Log | 当时发生了什么 | 结构化事件、异常栈、审计记录 |
| Baggage | 跨服务携带什么上下文 | 租户、区域等受控属性 |
不要把敏感个人信息、口令、令牌或完整请求正文放入 Span 属性和 Baggage。Baggage 会跨服务传播，必须限制字段和值的长度。
二、典型架构
应用或代理
-> OTLP
OpenTelemetry Collector
-> 处理、批量、过滤、采样
指标 / 日志 / Trace 后端
-> 查询、看板与告警
生产环境通常让应用发送给 Collector，由 Collector 统一做重试、批处理、属性清洗和多后端导出。Collector 不是无限缓冲区，出口故障时仍需明确队列上限和丢弃策略。
三、先统一资源属性
至少统一：service.name、服务版本、部署环境、集群、命名空间、区域和实例标识。属性命名应遵循语义约定，避免不同团队用 app、application、service 表示同一概念。
同时确保 HTTP、RPC、消息队列和数据库客户端可以传播 Trace Context。没有上下文传播，Trace 会在服务边界断开。
四、采样不是简单抽百分比
- 头部采样在请求开始时决定，开销低，但可能丢失后续错误请求。
- 尾部采样在收集到完整 Trace 后决定，更容易保留错误与高延迟请求，但需要更多 Collector 资源。
- 关键业务、错误、超时和低频请求可提高保留率；高频健康检查可降低采样。
先估算每秒请求数、平均 Span 数、属性大小、保留周期和出口带宽，再决定采样策略。
五、最小落地步骤
- 选择一个低风险服务，定义观测目标和成功标准。
- 先用自动埋点获得 HTTP、数据库和运行时基础信息。
- 补充少量业务关键 Span 和指标，不追求一次覆盖全部代码。
- 部署 Collector，设置内存限制、批处理、重试和健康检查。
- 将 Trace ID 写入结构化日志，建立日志与 Trace 跳转。
- 对比接入前后的 CPU、内存、时延和数据量。
- 再逐步扩大服务范围并治理属性基数。
六、常见问题
- 属性基数爆炸：把用户 ID、订单号、完整 URL 当作指标标签会显著增加存储和查询成本。
- 只接 Trace 不改日志：无法从一次故障快速关联到具体异常。
- Collector 单点：需按业务重要性设计冗余、队列和出口故障策略。
- 全量采样：小规模可用，生产高流量环境可能迅速造成成本和性能问题。
- 只有技术指标：应同时建立登录成功率、任务完成率等用户体验指标。
七、验收清单
- 一次测试请求能看到完整跨服务链路；
- Trace、Metric 与 Log 使用一致的服务和环境标识；
- 错误 Span 包含可诊断信息但不泄露敏感数据；
- Collector 的拒收、队列、导出失败和自身资源有监控；
- 采样后仍能保留重要故障和高延迟请求；
- 接入带来的性能与费用在预算内。