可观测性体系：用指标、追踪和日志定位问题

修订于 2026-10-12。本文中的排障流程是示例，不代表本站亲历故障。

可观测性需要回答两个问题：系统是否满足用户目标，以及出现异常时如何定位原因。指标、追踪和日志各有用途，不能只收集大量数据而缺少共同的服务、时间和请求上下文。

三类信号怎样配合

信号	更擅长回答	常见局限
指标	错误率、延迟、流量与资源是否异常	聚合数据难以解释单次请求
追踪	一次请求经过哪些服务、时间花在哪里	采样后可能缺少某次请求
日志	具体事件、错误原因和业务上下文	搜索成本与敏感信息风险

OpenTelemetry 提供采集和导出这些信号的开放规范。它不是后端存储，也不会自动替团队定义告警。选择采集方案时，要确认语言 SDK、自动埋点覆盖率、采样策略、数据保留和费用。

从症状到定位

以“结账变慢”为例，先在指标中界定开始时间、受影响请求和延迟分位数；再查看对应追踪，判断瓶颈发生在入口、数据库还是外部依赖；最后用相关日志核对失败码或异常。若缺少共同的 trace ID、服务名和时间戳，跨信号排查会更难。

延迟指标应区分入口总耗时与组件耗时。只有单个组件快，不能推断完整业务流程快。异步队列还应观察积压、处理时间和失败重试。

建设顺序

1. 选出关键用户流程，定义成功率与延迟目标。
2. 统一服务名、环境、版本和请求相关标识；控制高基数标签。
3. 先覆盖入口与关键依赖，再补上追踪和结构化日志。
4. 对真实症状演练排障，检查数据是否足够、告警是否可行动。
5. 管理采样、保留期、访问权限和个人信息脱敏。

参考资料

• OpenTelemetry：信号概览
• OpenTelemetry：可观测性入门