三大支柱 · Metrics、Logs、Traces
可观测性的三大支柱各自回答不同的问题、各有不同的代价曲线。这一章讲清指标、日志、追踪的本质分工——为什么是这三样、它们的成本模型有何根本不同，以及「三支柱」说法本身的争议。
三大支柱 · Metrics、Logs、Traces
上一章说系统要自证。但具体吐出什么数据？业界收敛出了三种形态，合称三大支柱：指标（Metrics）、日志（Logs）、追踪（Traces）。它们不是三种可选方案，而是三个互补的视角——各自擅长回答不同的问题，各自有完全不同的成本曲线。
三支柱各答什么
三大支柱的分工，可以用三个问题概括：
- 指标（Metrics） —— “系统现在什么状态？” 是聚合后的数字，随时间变化：QPS、错误率、P99 延迟、内存占用。特点是极度便宜（不管一秒来 1 个还是 100 万个请求，聚合后就是几个数），因此可以长期、高频、全量保存。代价是丢失了细节——你知道错误率 5%，但不知道具体是哪些请求失败了。
- 日志（Logs） —— “具体发生了什么？” 是离散的事件记录，带完整上下文：哪个用户、哪个订单号、什么错误堆栈。特点是细节完整，但极度昂贵（每个事件一条，量与流量成正比），且难以聚合（要从文本里捞出统计值很费劲）。
- 追踪（Traces） —— “这一个请求经历了什么？” 是一次请求跨服务的完整路径：在网关花了 5ms、订单服务 10ms、库存服务 1.8s（← 元凶）。特点是揭示因果与关联——这是分布式系统里指标和日志都给不了的视角。代价是量大，通常要采样。
一句话记忆：指标告诉你“出事了”，追踪告诉你“在哪一跳出的”，日志告诉你“那一跳到底怎么了”。三者串起来才是一次完整的排障。
成本模型才是关键区别
三支柱最本质的差异不在“记什么”，而在成本怎么随流量增长——这决定了你能拿它们干什么：
| 支柱 | 数据量随流量 | 能保存多久 | 能全量吗 |
|---|---|---|---|
| 指标 | 几乎不增长（聚合掉了） | 数月~数年 | ✅ 全量 |
| 追踪 | 线性增长 | 数天~数周 | ❌ 通常采样 |
| 日志 | 线性增长（且每条更大） | 数天~数月 | ⚠️ 常需取舍 |
指标“几乎不随流量增长”这一点，是它成为可观测性地基的根本原因。 想想：一个服务每秒处理 10 万请求，如果每个请求记一条日志，一天就是 86 亿条；但如果只记“请求总数”这一个计数器，一天下来它仍然只是一条时间序列——不管流量是 10 万还是 1000 万 QPS，存储成本几乎一样。
这个“聚合换细节”的交易，让指标可以做到长期、高频、全量、廉价，因此适合做告警和趋势（第 4 部分）。而日志和追踪因为线性增长，注定要在采样、保留期、成本上做痛苦取舍——这正是上一章说的“看得见 vs 付得起”那条轴。
你会发现整个 Prometheus 的设计，都是把“指标便宜”这个优势用到极致：压缩到平均 1~2 字节一个采样点、用倒排索引支持任意维度切——便宜到你可以毫无顾虑地全量长存。
一次真实排障里三者怎么配合
回到上一章那个 P99 变慢的例子，看三支柱如何接力：
指标发现问题 → 追踪定位到哪一跳 → 日志看清那一跳的细节。 这条“从宏观到微观逐级聚焦”的路径，是可观测性的标准工作流，也解释了为什么三者缺一不可：
- 只有指标：知道慢了，不知道哪慢。
- 只有日志：海量文本里大海捞针，且不知道该捞哪个时间段。
- 只有追踪：采样过的，可能恰好没采到出问题的那条；且没有全局趋势。
三者之间还需要能互相跳转——这就是第 6 部分要讲的关联机制（exemplar 让你从指标曲线一键跳到那一刻的某条 trace，trace 和日志靠 trace_id 关联）。支柱之间的“桥”和支柱本身一样重要，否则你在三个割裂的系统间手工对时间戳，效率极低。
“三支柱”说法的争议
必须提一句：“三大支柱”这个框架近年受到了不少批评，值得知道。
批评的核心是：“三支柱”容易让人以为“装齐这三样就有可观测性了”，但实际上割裂的三套系统 ≠ 可观测性**。**
- 割裂的问题 —— 指标在 Prometheus、日志在 ES、追踪在 Jaeger，三套系统、三个界面、三套查询语言，排障时人肉在中间倒腾。数据是有了，提问却依然困难。
- 本质是“宽事件” —— Charity Majors 等人的观点认为：三支柱只是同一份底层数据的三种投影。更本质的做法是记录高基数、宽维度的结构化事件（wide events），指标 / 追踪 / 日志都可以从它派生。
- 实践的回应 —— OpenTelemetry 正是往“统一”方向走的：用同一套 SDK、同一个协议（OTLP）、同一条管道（Collector）运送三支柱，并强调它们之间的关联。这也是第 5 部分要讲 Collector的原因——它的存在本身就是对“三支柱割裂”的一种回应。
所以别把“三支柱”当教条，把它当理解数据形态的入门框架：形态确实是三种，但目标是让它们成为一个整体。
小结与下一章
三大支柱的分工：指标（聚合数字，答“什么状态”，几乎不随流量增长故可全量长存）、日志（离散事件，答“具体发生了什么”，细节全但贵）、追踪（请求路径，答“哪一跳出的问题”，揭示因果但通常要采样）。本质区别是成本随流量的增长方式——这决定了各自的用法。排障标准流是指标发现 → 追踪定位 → 日志细看，三者间的关联桥（exemplar / trace_id）和支柱本身一样重要。“三支柱”框架有“割裂”之讥，OpenTelemetry 的统一路线正是对它的回应。
理论说完了。下一章用一条具体的指标走完全程，把这个专栏要讲的所有站点串成一张图。👉 一条指标的一生。
参考资料
- [1] Peter Bourgon 的经典文章 Metrics, tracing, and logging —— 三支柱框架的经典表述。
- [2] Charity Majors 等《Observability Engineering》（对三支柱的批评与“宽事件”主张）。
- [3] OpenTelemetry 官方文档：signals 概念（统一三支柱的实践）。