Metrics、Logs、Traces 有什么区别？

简化版

Metrics 是低成本聚合数值，适合趋势与告警；Logs 是离散事件记录，适合上下文与审计；Traces 描述一次请求跨服务的因果和耗时，适合链路定位。三者通过统一服务、时间、版本和 traceId 关联，而不是互相替代。

详细版

先用 SLO/Metrics 判断影响范围和时间，再从 exemplar 或版本维度进入 Trace 找到慢在哪一跳，最后用结构化日志查看该步骤的业务与错误细节。日志和 Trace 采样不会影响权威业务对账；Metrics 避免高基数，明细 ID 留在受控日志/Trace。

统一资源属性、UTC 时间、service.version 与 trace context；错误日志自动带 traceId/spanId。根据各信号价值设置不同保留和访问策略，并监控采集管道自身的丢弃、延迟与成本。

完整版教学

一、三种数据模型

Metrics 按时间序列聚合，Logs 是带时间的事件，Traces 是 span 构成的因果图。数据模型不同，擅长的问题也不同；把每个请求 ID 做指标标签会错误使用 Metrics。

记忆钩子：Metrics 告诉你“哪里不对”，Traces 告诉你“路径哪里慢”，Logs 告诉你“当时发生了什么”。

二、能力对比

信号	优点	局限	典型用途
Metrics	便宜、可聚合	缺少单次上下文	告警、容量
Logs	细节丰富	量大、关联弱	错误、审计
Traces	因果与耗时	采样、成本	分布式链路

业务事实最终仍在数据库或账本，遥测不是权威状态。

三、一次排障怎样串联

SLO alert -> metric spike at 10:05
-> exemplar/trace search -> DB span 1.8s
-> traceId logs -> lock timeout + SQL context

这种由广到窄的路径比先搜索海量日志更高效，也避免从单个错误样本夸大整体影响。

四、统一上下文

所有信号使用相同 service.name、environment、region 和 service.version；日志包含 traceId/spanId，发布系统写 release marker。字段语义不统一时，工具再多也无法可靠关联。

时钟同步并记录事件时间与接收时间；跨主机时间线仅靠壁钟可能因偏差出现“子 span 早于父 span”。

五、成本与基数

Metrics 只放 route/status 等有限标签；orderId 进入日志或 Trace。健康 Trace 采样、错误和长尾优先保留；日志按价值分级与冷热存储。

三者各自设置租户预算，不能因为一次事故全量 DEBUG 和全量 Trace 同时压垮观测平台。

六、缺失和不一致

Trace 查不到可能是采样，日志缺失可能是采集器故障，指标下降可能是遥测断流。观测系统本身要暴露接收率、队列、丢弃和延迟，并用心跳区分“零事件”和“无数据”。

关键业务用对账和 Outbox 证明事实，不能用遥测缺失直接判定消息未发生。

查询入口应保留原始口径说明，例如指标聚合窗口、Trace 采样规则和日志时区，避免跨信号比较时把不同语义拼在一起。

遥测关联权限取三者最严格边界，不能因 traceId 跳转就绕过敏感日志的访问控制。

七、常见误区与追问

• 误区：有日志就不需要 Trace。 日志难以自动还原跨服务因果。
• 误区：Trace 可以直接计算准确 QPS。 采样后数量有偏差。
• 误区：指标标签越细越容易定位。 高基数会拖垮存储。
• 误区：三种信号保留期应相同。 价值与成本不同，应分层。
• 追问：如何从指标跳到 Trace？ 用 exemplar、时间窗和一致资源属性。
• 追问：Trace 丢失怎么办？ 回退日志与位点证据，并检查采样/管道指标。
• 追问：哪个信号用于审计？ 独立、完整、不可篡改的审计日志，而非普通采样遥测。

八、加强记忆

三类信号按“指标定范围、追踪找路径、日志看细节”协作，以统一资源属性、版本、时间和 traceId 串联。各自按模型控制基数、采样和保留，并监控采集管道；最终业务正确性仍由权威数据与对账证明。