云原生可观测性实践：用 OpenTelemetry 统一日志、指标与链路追踪

一、为什么可观测性不能只靠日志

很多团队排查线上问题时，第一反应仍然是登录服务器 grep 日志。日志当然重要，但它只记录离散事件：当一次请求跨过网关、认证、订单、库存和支付等多个服务时，单看某个服务的日志很难还原完整调用链。可观测性的核心，是把日志、指标和链路追踪三类信号放到同一个上下文里观察，让问题从发现、定位到复盘形成闭环。

二、统一上下文：TraceID 是粘合剂

落地 OpenTelemetry 的第一步，是在入口层生成全局唯一的 TraceID，并通过 HTTP Header 或消息属性向下游透传。所有日志框架在输出时自动附带 TraceID 与 SpanID，指标标签中也带上服务名和接口名。这样当告警提示某个接口 P99 升高时，可以直接用 TraceID 检索到对应日志与完整调用链，省去在多个系统之间来回切换的时间。

三、采集与采样：别让数据洪流拖垮系统

全量采集链路数据成本很高。实践中可以采用头部采样加尾部采样的组合：常规请求按 10% 采样，错误请求和慢请求全部保留。采集端使用 OpenTelemetry Collector 统一接收 OTLP 数据，再分流到日志、指标与追踪后端，既降低了业务进程的耦合，也方便后续更换存储。

四、从指标到告警：用 SLO 说话

告警不应该围着单机 CPU 打转，而应围绕用户体验定义 SLO。例如接口成功率和 P95 延迟，配合错误预算消耗速率设置多级告警。指标维度控制在合理范围，避免高基数标签导致存储膨胀。告警触发时附带仪表盘和追踪查询链接，让值班同学能在最短时间内完成初步判断。

五、落地清单

• 统一 TraceID 透传规范，覆盖 HTTP、RPC 与消息队列；
• 日志格式结构化，强制包含 TraceID、服务名与耗时字段；
• 使用 OpenTelemetry Collector 做采集与分流，业务代码只负责埋点；
• 按错误与慢请求优先配置采样策略；
• 以 SLO 和错误预算驱动告警，而不是单机资源指标。

可观测性建设不是一次性工程，而是随着业务演进的持续投入。先把链路打通、把上下文统一，再逐步完善采样与告警，往往比一开始追求大而全的平台更容易见效。