日志、指标、链路的区别与联系：可观测性三大支柱详解
日志（Logs）、指标（Metrics）、链路追踪（Traces）被称为可观测性三大支柱，但三者的区别与适用场景常被混淆。本文用通俗的方式讲清每种信号的定义、优势与局限，以及如何借助观测云把三者关联成一个完整的排障闭环。
日志是带时间戳的离散事件记录，指标是随时间聚合的数值序列，链路追踪是一次请求在分布式系统中完整流转的路径记录——三者从不同维度描述系统行为，互为补充而非互相替代。理解它们的差异，是设计可观测性体系的第一步。
核心要点速览
- 日志回答「发生了什么」，细节最全但难以聚合统计；
- 指标回答「整体趋势如何」，成本最低、最适合告警，但没有个案细节；
- 链路回答「请求经过了哪里、慢在哪一环」，是微服务排障的关键；
- 三者通过 trace_id 等关联字段打通后，才能实现「告警 → 定位 → 根因」的完整闭环。
什么是日志？
日志是系统在特定时刻产生的离散事件记录，比如一次请求、一个异常、一次状态变更。每条日志通常包含时间戳、级别、消息正文和上下文字段（结构化日志以 JSON 等格式输出键值对）。
优势：细节最丰富，可以还原任意单个事件的完整上下文；写入简单，任何语言开箱即有。
局限：量最大、存储成本最高；非结构化日志难以聚合统计；只看日志很难回答「整体水位如何」这类问题。
典型场景：记录异常堆栈、审计操作、事后追溯单笔请求的处理细节。
什么是指标？
指标是把系统状态按固定间隔聚合成的数值——CPU 使用率、每秒请求数、错误率、P99 延迟。一条指标由名称、标签（维度）、时间戳和数值构成。
优势：体积极小、查询极快，天然适合趋势图和阈值告警；降采样后长期留存成本可控。
局限：是聚合后的抽象，丢失了个案细节；标签基数（cardinality）失控会撑爆时序存储。
典型场景：SLI/SLO 定义、容量规划、异常告警（如「错误率 5 分钟内超过 2%」）。
什么是链路追踪？
链路追踪记录一次请求穿越多个服务的完整路径：每个环节产生一个 Span（记录操作名、耗时、状态），所有 Span 通过同一个 trace_id 串成一棵调用树。
优势：微服务架构下唯一能回答「慢在哪一环、错在哪一跳」的手段；直观呈现服务间依赖。
局限：需要埋点（或 eBPF 等零侵入方案）；全量采集成本高，通常需要采样。
典型场景：跨服务慢请求定位、服务依赖分析、错误传播路径还原。
三者应该如何选择？
不是三选一，而是分层组合：
- 指标做哨兵：低成本持续监控全局水位，负责触发告警；
- 链路做定位：告警后沿着异常请求的 trace 找到出问题的服务与环节；
- 日志做根因：在出问题的服务上查阅对应 trace_id 的详细日志，确认根因。
这个「指标 → 链路 → 日志」的下钻路径，是业界公认的排障最佳实践。
观测云落地：三支柱一体打通
观测云原生支持三大信号的统一采集与关联分析：
- 指标：DataKit 内置数百种采集器（主机、数据库、中间件、云服务），指标自动进入指标模块，支持 DQL 查询与仪表板可视化；
- 日志：DataKit 日志采集 + Pipeline 解析，日志查看器支持聚类分析与多维过滤；
- 链路：DataKit 支持 OTLP（4317/4318）、Jaeger、Zipkin、SkyWalking 等多种链路数据接收，APM 模块提供服务拓扑、火焰图与链路详情。
关键在于关联：应用日志注入 trace_id 后，在观测云中可从链路详情直接跳到同一次请求的日志，也可以从日志反查链路；指标异常时通过关联标签直达相关服务与主机。监控器对指标或日志配置告警后，事件自带关联数据入口，把三大支柱串成一条排障动线。
常见问题（FAQ）
Q：小团队资源有限，应该先上哪个？ 先指标（覆盖面广、成本最低），再日志（排障刚需），服务数量上来后补链路。观测云一个 DataKit 即可同时采集三者，边际成本很低。
Q：有了链路追踪还需要日志吗？ 需要。Span 只携带有限属性，详细堆栈、业务字段仍要靠日志；两者通过 trace_id 关联才能各取所长。
Q：指标和日志里的 time series 有什么区别？ 指标是预先聚合的数值序列，日志是原始事件。日志平台也能「从日志提取指标」，但实时性和成本不如原生指标管道。
Q：Profiling 算第四根支柱吗？ 业内越来越多地这么看。Profiling 提供代码级的持续性能剖析，观测云同样支持，可作为三支柱的补充。
系列阅读
- 下一篇：《日志 vs 错误追踪》
- 相关：《什么是可观测性》 · 《什么是 APM》 · 《返回索引》
