TL;DR · 本文论证：metrics / logs / traces 不是可观测性的三个维度，是同一种"事件"的三种输出格式。把它当作理论框架已经造成了过去七八年的工程混乱——三套独立存储、三套查询语言、三道事故现场的墙。 · 写给可观测后端选型者、SRE、平台工程师、AI 应用架构师。 · 不读会错过：为什么 OTLP / Exemplar / 列存后端的兴起本质上是"三支柱在悄悄解体"，以及为什么 AI 可观测不应再走老路。

如果你最近两年读过任何一篇关于可观测性的入门文章，大概率见过这张图——三个圆相交，分别标着 Metrics、Logs、Traces，相交处写着"完整可观测性"。它来自 Peter Bourgon 2017 年 2 月的一篇博客（“Metrics, tracing, and logging”, peter.bourgon.org），配着一句被引用过几千次的话：“Metrics, tracing, and logging.”

将近十年之后，这张图变成了一种事实——产品按它分类，工程师按它建岗，预算按它划块。但很少有人停下来问：这种切分为什么是三？为什么不是二、四、八？它有理论依据，还是只是历史的偶然？

我想论证一个不太讨好的观点：三支柱与其说是可观测性的理论分类，不如说是输出格式的清单。把它当成理论会产生三种持久的工程伤害——我们今天看到的可观测领域的混乱，相当一部分是在为这个误读买单。

1. 三支柱框架的来源

Bourgon 那篇博客严格说不是一份"理论"。他画那张韦恩图，是为了帮工程师在技术选型时区分三类工具的能力边界——它是描述性的，描述当时市场上存在的三类产品，而不是规定可观测性必须由这三类构成。Bourgon 自己在文中明确写过：“The point isn’t that these things are completely separate, it’s that they have different properties."——他本人甚至预言了边界会模糊。问题出在传播过程中，“different properties” 被简化成了 “different pillars”。

Cindy Sridharan 在同期的工作（最终成书 Distributed Systems Observability）里讨论得更细。她明确区分了 monitoring 和 observability，把 metrics / logs / traces 列为三类信号，但她本人对"是否应该作为独立支柱"是有保留的——她更接近"它们都是同一种基础事件流的不同视图"的立场。

把 “metrics / logs / traces” 重铸为 “three pillars” 的，主要是后续几年的厂商话语。“支柱"这个比喻有一种结构性、奠基性的意味——它暗示这三者各司其职、缺一不可、平等并列。这个暗示，是误读的种子。

MetricsLogsTraces"完整可观测性"

图 1·Bourgon 2017 年韦恩图的还原。三圆相交处被标为"完整可观测性”——但相交在哪里、相交的语义是什么，从未被严格定义。

2. 三支柱做对了什么

为公平起见，先讲清楚它做对的几件事。

它让这个领域对新人变得可读。十年前一个新工程师入门 monitoring 要先理解 SNMP、Nagios、syslog、StatsD、Graphite、collectd 一堆碎片化的东西。三支柱给了一个 first-pass mental model：我现在在和哪一类信号打交道？我用哪类工具？这是教学价值。

它确认了 traces 的合法地位。在三支柱出现之前，分布式追踪是少数大公司的内部奢侈品。把它和 metrics / logs 并列，让它在工程团队的预算讨论里能正式占一席。

它让产品边界变得清晰。Prometheus 守 metrics、ELK 守 logs、Jaeger 守 traces——这种"各占一柱"的结构在 2018–2021 年是高效的，它让每个开源项目能聚焦。

这些功劳真的存在。但它们都是当时的功劳，而不是永久的真理。

3. 三支柱做错的三件事

错事一：把"输出格式"误认为"理论维度”

Metrics、logs、traces 不是可观测性的三个维度，它们是同一种东西的三种输出格式。

  • 一个 metric 是"对一组事件按时间窗口做聚合"得到的数值。
  • 一条 trace 是"一组事件按因果关系串起来"得到的图。
  • 一条 log 是"一个事件单独输出"得到的文本。

它们的差别不在被观测对象，不在内部状态，不在系统行为——它们的差别只在取出来的姿势。把姿势当成维度，等于把"煮、蒸、煎"列为食材的三大类。

如果接受这一点，那三支柱就更像一个产品分类，而不是理论分类——它分的是工具，不是被观测对象的属性。这呼应 L1-1 的论点：可观测性是被观测对象的性质，工具只是看的姿势。

错事二：强制了三套独立系统

因为三支柱被当作理论，工程实践就按它建了三套独立的存储、查询、索引系统：

  • Metrics：TSDB（Prometheus、VictoriaMetrics、Mimir），PromQL
  • Logs：倒排索引或列存（Elasticsearch、Loki、ClickHouse、Apache Doris），LogQL / Lucene / SQL
  • Traces：trace-specific 存储（Jaeger、Tempo），TraceQL

这三套系统在大型组织里成本通常占可观测预算的 40%–70%。它们彼此存在大量功能重叠——都要 ingestion、都要 retention、都要 query、都要 RBAC——但因为属于不同"支柱"，被独立采购、独立运维、独立扩容。

更尴尬的是，事故发生时工程师需要同时查三套系统并人工关联：metric 告警 → 跳 trace 找慢 span → 跳 log 找异常堆栈。每一次跳转都伴随上下文丢失、时间戳错位、ID 对不上——三支柱给出的"清晰边界"在事故现场变成了三道墙。

flowchart LR
    subgraph TSDB["Metrics 系统
Prometheus / Mimir"]
        ALERT["p99 飙高告警"]
    end
    subgraph TRACE["Traces 系统
Jaeger / Tempo"]
        SPAN["定位慢 span"]
    end
    subgraph LOG["Logs 系统
ELK / Loki"]
        ERR["查异常堆栈"]
    end
    ALERT -.->|"人工复制 trace_id
切换控制台"| SPAN
    SPAN -.->|"对齐时间窗口
切换控制台"| ERR
    style ALERT fill:#ffe3e3
    style SPAN fill:#fff4d6
    style ERR fill:#e0eaff

图 2·三支柱在事故现场变成三道墙。每一次跨系统跳转都伴随上下文丢失、时间戳错位、ID 对不上。

错事三：让"事件"这个更基础的概念被边缘化

如果你接受 metric / log / trace 都是"事件"的不同输出形式，那么可观测性的基础原语就是事件（event）——更准确地说，是 wide event：一条富上下文的结构化记录，携带时间戳、因果链 ID、所有相关属性。

Charity Majors 和 Honeycomb 的核心论点之一就是这个：你只需要存储足够宽的事件流，metrics、logs、traces 都可以派生出来。

  • Metric = SELECT count(*) FROM events WHERE ... GROUP BY time_bucket
  • Trace = SELECT * FROM events WHERE trace_id = X ORDER BY start_time
  • Log = SELECT * FROM events WHERE level = 'error'

但三支柱框架把"事件"这个原语隐藏起来了。它让一代工程师以为 metric 是基础物、log 是基础物、trace 是基础物——而不是看到它们背后那个共同的、更基础的东西。

4. 如果不是三支柱，那是什么？

不是抹掉三种格式，而是把它们还原为同一原语的三种视图。

维度三支柱视角事件统一视角
基础原语metric / log / trace 各自独立宽事件（wide event）
存储三套系统一套（理想情况）
查询三套语言一套（含聚合、过滤、因果）
关联用 trace_id 跨系统手工 join同一张表，原生关联
加新视图建新系统、新一支柱加新查询而已

这个视角不是新的——它是 OLAP 思路在可观测领域的搬运。它的代价是查询引擎要够强（基数高时聚合代价大），存储要够便宜（列存 + 对象存储）。这两件事在 2024 年之后已经普遍成熟。

flowchart LR
    subgraph EVT["宽事件流  (单一存储)"]
        E["event {
timestamp, trace_id, span_id,
service.name, user_id,
http.status, duration_ms,
error.type, ... }"]
    end
    E -->|"GROUP BY time, name
SELECT count, p99"| M["Metric 视图"]
    E -->|"WHERE trace_id = X
ORDER BY start_time"| T["Trace 视图"]
    E -->|"WHERE level = 'error'
SELECT message"| L["Log 视图"]

图 3·宽事件是原语，三支柱是查询视图——存一份、查多种。

5. 工程证据：三支柱正在自我解体

如果三支柱只是"输出格式清单"，我们应该能看到工程实践正在绕过它——而不是巩固它。证据如下。

OTLP 在协议层统一了三者。 OpenTelemetry Protocol 把 metrics、logs、traces 装进同一套 Protobuf schema 体系（共享 Resource / Attribute 等通用结构）、走同一种 transport、用同一组 Collector 处理。十年前是三种独立协议（Prometheus exposition、syslog、Jaeger Thrift），今天是一个 OTLP。

Semantic Conventions 在语义层统一了属性。 service.name、http.request.method、error.type 这些属性在三类信号中含义相同、命名相同。这暗示它们本来就在同一概念空间里。

Exemplar 在数据点层把 metric 和 trace 直接连起来。 一个 p99 数据点里直接挂着代表性 trace ID——三支柱被打了一个洞。

列存后端让一个系统服务三类信号。 ClickHouse、Apache Doris、SigNoz、Honeycomb、Axiom 这些系统都建立在"一切都是宽事件表"的假设之上——Doris 在高并发交互式查询和复杂 Join 场景下尤其能体现"一套系统服务三类信号"的工程价值。它们的崛起本身就是对三支柱模型的工程级否定。

新一代厂商的产品分类不再按支柱划分。 Honeycomb 卖的是 “events”，Axiom 卖的是 “unified telemetry”，Grafana 在向 “single pane of glass” 靠拢——“支柱"这个词在新的市场材料里出现频率正在下降。

flowchart TD
    P["三支柱框架
(metrics / logs / traces)"]
    P -.->|"协议层统一"| OTLP["OTLP
同一 Protobuf schema"]
    P -.->|"语义层统一"| SC["Semantic Conventions
属性命名共用"]
    P -.->|"数据点层穿透"| EX["Exemplar
metric 直挂 trace_id"]
    P -.->|"存储层合并"| CS["列存后端
ClickHouse / Apache Doris / Honeycomb"]
    P -.->|"产品话语转向"| V["'events' / 'unified telemetry'
替代 'pillars'"]
    style P fill:#f5f5f5,stroke-dasharray:5 5

图 4·三支柱在五个层面同时被绕过——这不是某家厂商的策略，是整个生态的范式漂移。

6. 但三支柱不会马上消失

诚实一点：这种框架不会因为它错就消失。它会持续存在很多年，原因不在理论，在结构。

路径依赖。 Prometheus + ELK + Jaeger 是几十万家公司的现役栈。它们工作得"够好”，迁移成本巨大。

组织分工。 大型组织里 metrics 团队、logs 团队、APM 团队是分开的，预算、KPI、岗位都按这个分。重写理论不会撼动 org chart。

厂商利益。 把可观测拆成三块好分别定价、好做 upsell。统一架构反而难定价。

学习惯性。 入门材料、培训课程、面试题已经按三支柱写了近十年。换叙述要时间。

所以这一篇的目标不是呼吁立刻拆掉三支柱栈。它的目标是让你在做新系统设计时——尤其是 AI 可观测这种没有历史包袱的领域——不要默认地从"我要建 metrics + logs + traces"开始，而是从"我要捕获哪些事件、保留哪些维度"开始。

7. 回声一：状态可推断性的回归

回到 L1-1 留下的回声：可观测性的核心判别标准是系统状态能否被推断。

在三支柱框架下，状态推断需要跨三套系统做关联——而关联失败正是大多数事故 debug 卡住的根因。在统一事件视角下，状态推断变成单系统的查询——更简单、更可探索、更接近 Kalman 原始定义所说的"从有限输出反演内部状态"。

我不是在说事件统一视角已经赢了——它显然还在演化中。我觉得更准确的说法是：当我们追问"系统状态能否被推断"时，三支柱给出的答案越来越牵强，事件统一视角给出的答案越来越自然。这是一场仍在进行的范式转移。

8. 自我证伪

如果以下任一条件成立，本文的核心论证就会动摇： ① 如果查询引擎在宽事件规模上扛不动——即"存一份、查多种"的代价在生产规模上不可接受。部分有效： 这在 2018 年是真问题，在 2024+ 列存技术（ClickHouse、Apache Doris、Arrow）成熟后已经基本被解掉。但对超大规模（>10 PB/天）公司仍是开放问题。 ② 如果三支柱框架其实有理论依据而非历史偶然——比如"采集姿势"对应不同观察者模式。反驳： 我没找到任何严肃的理论文献支持这种分类；它在所有可信的文献里都被描述为"行业现状"而非"理论框架"。 ③ 如果某类信号（如 continuous profiling）确实在数据模型上无法归约到事件——那么至少存在"第 N 支柱"的合理性。部分成立： profile 数据的体积和结构确实特殊，是否能完全归约到事件流仍有争议；本文承认这一开放问题。

9. Key Takeaways

  • 三支柱更像产品分类而非理论分类——metric / log / trace 是同一种宽事件的三种查询投影。
  • 三套独立系统让事故现场变成三道墙——跨系统手工 join 是大多数 debug 卡顿的根因。
  • “事件"是更合理的基础原语——Honeycomb / ClickHouse / Apache Doris on events 这一脉的崛起是工程级证据。
  • 三支柱在协议层（OTLP）、语义层（Semantic Conventions）、数据点层（Exemplar）、存储层（列存）、产品话语层同时被绕过——这是范式漂移，不是某家厂商的策略。
  • AI 可观测没有历史包袱，没必要继承三支柱——从"我要捕获哪些事件"开始，而不是从"我要建 metrics + logs + traces"开始。

10. 通向下篇

把"事件"立为基础原语之后，下一个问题立刻浮现：

你不可能记录全部事件。

每条 HTTP 请求、每个数据库查询、每次函数调用——如果都按宽事件存下来，存储成本以 O(流量 × 维度) 增长。这不是工程优化能解决的问题，是物理约束。

这就把"采样"从工程技巧上升为认识论问题：在你不可能存下全部状态的前提下，存什么、怎么存、丢什么，决定了你能回答什么问题、不能回答什么问题。

下一篇 L1-3 处理这个问题。

参考

  • Bourgon, P. (2017). Metrics, tracing, and logging. peter.bourgon.org (Feb 2017).
  • Sridharan, C. (2018). Distributed Systems Observability. O’Reilly Report——明确指出三类信号"highly complementary” 但不主张作为独立"pillars"。
  • OpenTelemetry Specification. Protocol (OTLP). opentelemetry.io——证据 A：协议层统一。
  • OpenTelemetry Specification. Semantic Conventions. opentelemetry.io——证据 B：语义层统一。
  • Honeycomb Engineering Blog. Why We Use Events as the Foundation. honeycomb.io——核心 thesis: 宽事件即原语。