# 三大支柱 · Metrics、Logs、Traces

> 可观测性的三大支柱各自回答不同的问题、各有不同的代价曲线。这一章讲清指标、日志、追踪的本质分工——为什么是这三样、它们的成本模型有何根本不同，以及「三支柱」说法本身的争议。

- 作者：David（道雾轩）
- 专栏：指标采集与观测（https://daiw.org/manual/observability.md）
- 最后更新：2026-07-15
- 原文：https://daiw.org/manual/observability/three-pillars
- 转载与引用：请注明出处并附原文链接（https://daiw.org/about/copyright）

# 三大支柱 · Metrics、Logs、Traces

[上一章](https://daiw.org/manual/observability/why-observability)说系统要**自证**。但具体吐出什么数据？业界收敛出了三种形态，合称**三大支柱**：**指标（Metrics）、日志（Logs）、追踪（Traces）**。它们不是三种可选方案，而是**三个互补的视角**——各自擅长回答不同的问题，各自有完全不同的成本曲线。

## 三支柱各答什么

<Callout type="info">
  **三大支柱的分工，可以用三个问题概括：**

  - **指标（Metrics）** —— “**系统现在什么状态？**” 是**聚合后的数字**，随时间变化：QPS、错误率、P99 延迟、内存占用。特点是**极度便宜**（不管一秒来 1 个还是 100 万个请求，聚合后就是几个数），因此可以**长期、高频、全量**保存。代价是**丢失了细节**——你知道错误率 5%，但不知道**具体是哪些请求**失败了。
  - **日志（Logs）** —— “**具体发生了什么？**” 是**离散的事件记录**，带完整上下文：哪个用户、哪个订单号、什么错误堆栈。特点是**细节完整**，但**极度昂贵**（每个事件一条，量与流量成正比），且**难以聚合**（要从文本里捞出统计值很费劲）。
  - **追踪（Traces）** —— “**这一个请求经历了什么？**” 是**一次请求跨服务的完整路径**：在网关花了 5ms、订单服务 10ms、库存服务 1.8s（← 元凶）。特点是**揭示因果与关联**——这是[分布式系统里指标和日志都给不了的视角](https://daiw.org/manual/observability/why-observability)。代价是量大，通常要**采样**。

  一句话记忆：**指标告诉你“出事了”，追踪告诉你“在哪一跳出的”，日志告诉你“那一跳到底怎么了”**。三者串起来才是一次完整的排障。
</Callout>

## 成本模型才是关键区别

三支柱最本质的差异不在“记什么”，而在**成本怎么随流量增长**——这决定了你能拿它们干什么：

| 支柱 | 数据量随流量 | 能保存多久 | 能全量吗 |
| --- | --- | --- | --- |
| **指标** | **几乎不增长**（聚合掉了） | 数月~数年 | ✅ 全量 |
| **追踪** | **线性增长** | 数天~数周 | ❌ 通常采样 |
| **日志** | **线性增长**（且每条更大） | 数天~数月 | ⚠️ 常需取舍 |

<Callout type="info">
  **指标“几乎不随流量增长”这一点，是它成为可观测性**地基**的根本原因。** 想想：一个服务每秒处理 10 万请求，如果每个请求记一条日志，一天就是 86 亿条；但如果只记“请求总数”这一个**计数器**，一天下来它仍然只是**一条时间序列**——不管流量是 10 万还是 1000 万 QPS，存储成本几乎一样。

  这个“**聚合换细节**”的交易，让指标可以做到[长期、高频、全量、廉价](https://daiw.org/manual/observability/three-pillars)，因此适合做**告警和趋势**（[第 4 部分](https://daiw.org/manual/observability/three-pillars)）。而日志和追踪因为线性增长，注定要在**采样、保留期、成本**上做痛苦取舍——这正是[上一章说的“看得见 vs 付得起”](https://daiw.org/manual/observability/why-observability)那条轴。

  **你会发现整个 Prometheus 的设计，都是把“指标便宜”这个优势用到极致**：[压缩到平均 1~2 字节一个采样点](https://daiw.org/manual/observability/data-journey)、[用倒排索引支持任意维度切](https://daiw.org/manual/observability/data-journey)——便宜到你可以毫无顾虑地全量长存。
</Callout>

## 一次真实排障里三者怎么配合

回到[上一章那个 P99 变慢的例子](https://daiw.org/manual/observability/why-observability)，看三支柱如何接力：

```mermaid
flowchart LR
    M["① 指标<br/>P99 从 200ms → 2s<br/>(告警触发)"] --> T["② 追踪<br/>看一条慢请求的火焰图<br/>→ 库存服务这一跳占 1.8s"]
    T --> L["③ 日志<br/>翻库存服务那一刻的日志<br/>→ 大量 '磁盘超时' 错误"]
    L --> R["根因定位"]
    style M fill:#3b82f6,color:#fff
    style T fill:#a855f7,color:#fff
    style L fill:#f59e0b,color:#fff
    style R fill:#22c55e,color:#fff
```

**指标发现问题 → 追踪定位到哪一跳 → 日志看清那一跳的细节。** 这条“从宏观到微观逐级聚焦”的路径，是可观测性的标准工作流，也解释了为什么三者缺一不可：
- 只有指标：知道慢了，不知道哪慢。
- 只有日志：海量文本里大海捞针，且不知道该捞哪个时间段。
- 只有追踪：采样过的，可能恰好没采到出问题的那条；且没有全局趋势。

三者之间还需要**能互相跳转**——这就是[第 6 部分要讲的关联机制](https://daiw.org/manual/observability/three-pillars)（exemplar 让你从指标曲线一键跳到那一刻的某条 trace，trace 和日志靠 trace_id 关联）。**支柱之间的“桥”和支柱本身一样重要**，否则你在三个割裂的系统间手工对时间戳，效率极低。

## “三支柱”说法的争议

必须提一句：**“三大支柱”这个框架近年受到了不少批评**，值得知道。

<Callout type="warn">
  **批评的核心是：“三支柱”容易让人以为“装齐这三样就有可观测性了”，但实际上**割裂的三套系统 ≠ 可观测性**。**

  - **割裂的问题** —— 指标在 Prometheus、日志在 ES、追踪在 Jaeger，三套系统、三个界面、三套查询语言，排障时人肉在中间倒腾。**数据是有了，提问却依然困难**。
  - **本质是“宽事件”** —— [Charity Majors 等人的观点](https://daiw.org/manual/observability/why-observability)认为：三支柱只是**同一份底层数据的三种投影**。更本质的做法是记录**高基数、宽维度的结构化事件**（wide events），指标 / 追踪 / 日志都可以从它派生。
  - **实践的回应** —— OpenTelemetry 正是往“**统一**”方向走的：[用同一套 SDK、同一个协议（OTLP）、同一条管道（Collector）运送三支柱](https://daiw.org/manual/observability/the-three-projects)，并强调它们之间的关联。这也是[第 5 部分要讲 Collector](https://daiw.org/manual/observability/the-three-projects)的原因——**它的存在本身就是对“三支柱割裂”的一种回应**。

  所以别把“三支柱”当教条，把它当**理解数据形态的入门框架**：形态确实是三种，但**目标是让它们成为一个整体**。
</Callout>

## 小结与下一章

三大支柱的分工：**指标**（聚合数字，答“[什么状态](https://daiw.org/manual/observability/three-pillars)”，[几乎不随流量增长故可全量长存](https://daiw.org/manual/observability/three-pillars)）、**日志**（离散事件，答“[具体发生了什么](https://daiw.org/manual/observability/three-pillars)”，细节全但贵）、**追踪**（请求路径，答“[哪一跳出的问题](https://daiw.org/manual/observability/three-pillars)”，揭示因果但通常要采样）。**本质区别是成本随流量的增长方式**——这决定了各自的用法。排障标准流是[指标发现 → 追踪定位 → 日志细看](https://daiw.org/manual/observability/three-pillars)，三者间的**关联桥**（[exemplar / trace_id](https://daiw.org/manual/observability/the-three-projects)）和支柱本身一样重要。“三支柱”框架[有“割裂”之讥](https://daiw.org/manual/observability/why-observability)，[OpenTelemetry 的统一路线](https://daiw.org/manual/observability/the-three-projects)正是对它的回应。

理论说完了。下一章用一条**具体的指标**走完全程，把这个专栏要讲的所有站点串成一张图。👉 [一条指标的一生](https://daiw.org/manual/observability/data-journey)。

## 参考资料

- [1] Peter Bourgon 的经典文章 Metrics, tracing, and logging —— 三支柱框架的经典表述。
- [2] Charity Majors 等《Observability Engineering》（对三支柱的批评与“宽事件”主张）。
- [3] OpenTelemetry 官方文档：signals 概念（统一三支柱的实践）。