首页/云/可观测性速查/可观测性三支柱:Metrics、Logs、Traces
监控体系与方法40 条

可观测性三支柱:Metrics、Logs、Traces

指标、日志、链路追踪三类遥测数据的定位与分工:指标回答整体趋势,日志回答单次细节,链路回答请求跨服务的路径;三者靠统一标签与 trace_id 关联。

可观测性速查云更新于 2026-10-13

三支柱是什么

可观测性指仅凭系统对外输出的数据就能推断其内部状态的能力。Metrics 指标、Logs 日志、Traces 链路是当前最主流的三类遥测信号:指标回答整体趋势是否正常,日志回答这一次具体发生了什么,链路回答请求慢在哪个服务、哪一跳。三者不是替代关系,而是在排障路径上各管一段,并靠统一的服务标签与 trace_id 互相跳转。

基本信息

适用场景微服务、容器化与云原生系统的监控、告警与排障
关联字段指标 exemplar 上的 trace_id、日志中的 trace_id、各信号统一的 service.name
主流工具指标 Prometheus/VictoriaMetrics,日志 Loki/ELK,链路 Jaeger/Tempo
落地顺序先指标打底,再日志补细节,链路按服务复杂度逐步接入

典型使用场景

  • 容量与趋势:用指标看 QPS、错误率、资源水位的中长期走向,为扩容与成本决策提供依据
  • 告警与值班:指标是全量长期留存成本最低的形态,适合做实时告警与错误预算统计
  • 单次故障定位:从告警点拿到 trace_id,跳进链路找到耗时突增的那一跳
  • 跨服务调用分析:排查网关超时、下游抖动、数据库慢查询等跨边界问题
  • 审计与追溯:日志是事后复现与行为审计的主要数据来源
  • 发布回归验证:发布前后对比同一服务的 P95/P99 与错误率变化

三支柱对比

维度Metrics 指标Logs 日志Traces 链路
数据形态数值时间序列带时间戳的文本或结构化事件树状 span 调用记录
回答什么问题整体健康与趋势如何这次报错的具体细节请求慢在哪个服务、哪一跳
典型工具Prometheus、VictoriaMetricsELK、LokiJaeger、Tempo
成本量级低(聚合存储)偏高(原始文本,靠留存策略控制)中(与采样率相关)
常见留存数月到数年(降采样)数天到 90 天(分级留存)数天(按采样)

三类数据的关联手段

三类数据的关联手段
# 1) 指标侧:直方图暴露 exemplar,把 trace_id 挂在分桶上
#    服务端需开启 exemplar,Prometheus 需加 --enable-feature=exemplar-storage
# 2) 日志侧:每条日志输出 trace_id,推荐 JSON 结构化日志
#    {"ts":"2026-10-13T10:00:00Z","service":"order-svc","trace_id":"4bf92f35...","msg":"pay timeout"}
# 3) 链路侧:span 带 service.name 与实例标签,才能与指标标签对齐
# 4) 展示侧:Grafana 配置 Exemplar 与 Trace to logs,实现告警到链路的点击跳转

统一资源属性示例

统一资源属性示例
# OpenTelemetry Resource:三类信号共用同一套标识
resource:
  service.name: order-svc         # 必须与指标 job/label 口径一致
  service.version: 1.8.3          # 支持发布前后对比
  deployment.environment: prod    # 避免测试数据混入生产看板

从现象到根因的下钻路径

现象先看什么再去看
整体错误率上升指标:错误率与 QPS 曲线日志:按错误消息聚类定位异常类型
接口 P99 变慢指标:按 route 拆分的耗时分布链路:定位耗时集中在哪个下游
个别用户投诉日志:按用户或请求 ID 检索链路:还原该请求的完整调用树
突发抖动指标:实例维度分布是否均匀日志:是否有重试风暴与连接池拒绝
三类数据的留存与采样策略要同步设计:否则会出现有告警却查不到证据。指标宜全量长期,日志按级别分级留存,高流量服务上链路必须采样,并让错误请求优先被保留。
标签口径不一致是常见隐性故障:同一服务在指标里写 order-svc、在日志里写 order_service,两边永远关联不上,只能人工对表。

选型时的常见权衡

需求倾向指标倾向日志或链路
看中长期趋势且成本可控聚合存储、压缩比高原始数据成本随流量线性增长
按任意维度切片聚合标签维度直接聚合、结果稳定日志依赖索引设计,链路仅支持已有属性
还原单次请求全貌只能到计数与分位,无法还原个体span 树还原调用路径,日志补齐业务细节
长期留存做审计不保存原始事件日志按合规要求留存,链路通常短期保留
选信号的实用判断:需要长期低成本地看趋势与做告警,选指标;需要按未知维度做探索式检索,选日志;需要回答哪一个环节慢或失败,选链路。三类都缺时,排障会退化成靠经验猜。

易错点

  • 只做指标不做链路:跨服务慢请求只能逐个服务翻看板,长时间无法定位到具体下游
  • 日志不做结构化:缺少 trace_id 与固定字段,只能全文模糊检索,慢且不稳定
  • 标签与时间戳口径不一致:关联失败,需事先统一 service.name 并保证各主机 NTP 同步
  • 采样策略不当:错误请求未被采样,故障发生时恰恰没有链路可查

数据来源与参考

​‌‌​​‌​​​‌‌​‌‌‌‌​‌‌​​​‌‌​‌‌‌​​‌‌​​‌​‌‌‌​​‌‌‌​​​‌​‌‌​‌​​‌​‌‌‌​​​‌​‌‌​‌​​‌​‌‌​​​‌‌​‌‌‌​‌​​​‌‌​‌‌‌‌​​‌​‌‌‌​​‌‌​​​‌‌​‌‌​‌‌‌‌​‌‌​‌‌​‌