知识花园

最近更新

可观测性：从已知失败到任意提问

26分钟阅读

可观测性：从已知失败到任意提问

经典范式三篇走完了。监控给了我们布尔判断，指标给了我们量化趋势，日志第一次把个体留在了桌上。但它们共享同一个前提——你得预先知道系统会怎么坏，才能在那里埋下哨兵、设好阈值、记好日志。

这一篇，我们正式跨过那条线。可观测性（observability）不是把监控做得更好，它是换了一个根本问题：从”系统坏了没”，到”系统现在到底在发生什么——包括我从没想到要问的那些”。这是 01 那个元命题在云原生这一跳的具象——存储变便宜、系统变分布，天平于是从”靠人预判”彻底倒向”留下一切、事后任意提问”。这是云原生范式的第一篇，也是整套系列认识论上的分水岭。

一、换挡：从”坏了没”到”在发生什么”

接上日志的渡口

上一篇结尾，我们站在一个渡口：当你给同一次请求的所有日志打上同一个 trace_id、把散落在五个服务里的孤立日志串成一条因果链时，你已经在亲手搭建追踪的雏形了——而那一步，你就走出了经典范式。

现在我们正式上岸。上岸后的世界，规则和经典范式不一样：你不再假设自己能预先列出故障清单，你转而假设——故障会以你想不到的方式出现，所以系统必须保留足够的原始信息，让你在事后把任何问题问出来。 这个假设的转变，就是这一整篇要展开的东西。

可观测性不是更多的监控，是换了问题

最常见的误解，是把可观测性当成”监控 2.0”——更多的指标、更漂亮的仪表盘、更高级的告警。不是的。它们问的是不同的问题：

  • 监控问：我预设的这些指标，有没有越过我预设的阈值？（答案是是 / 否）
  • 可观测性问：此刻系统内部到底在发生什么？为什么这一类用户、这一类请求表现异常？——而这个”这一类”，我事先并不知道。

监控是一组封闭的问题（你能问的，都是你预先埋好的）。可观测性追求一种开放的能力（你能问出你埋点时根本没想到的问题）。这就是为什么”更多的监控”永远到不了可观测性——你加再多预设的图表，也仍然只能回答预设的问题。

一个借来的词

“可观测性”不是运维行业生造的词，它是从控制论借来的。1960 年，Rudolf Kálmán 给出了它的数学定义：一个系统是可观测的，当且仅当你能仅凭它的外部输出，在有限时间内推断出它的任意内部状态。 注意”任意内部状态”——不是某个预设的状态，是任意的。

Charity Majors（Honeycomb 创始人）把这个定义搬进了软件：可观测性，衡量的是你能否回答关于系统的、你事先没有预料到的问题，而无需预先埋点、无需重新发布代码。 全篇最重要的词，就是”事先没有预料到”——它精确地、字面地，对立于 监控的"预知"。监控建立在预判之上，可观测性建立在”放弃预判”之上。

二、核心：已知的已知与未知的未知

为什么分布式系统逼着我们放弃预判？答案藏在一个著名的认识论框架里。

Rumsfeld 四象限

把”故障”按两个轴切开——你知不知道它存在、你知不知道怎么应对：

  • 已知的已知：你知道会发生，也知道怎么观察。“磁盘会满，我监控它。”
  • 已知的未知：你知道可能发生，但不确定细节。“延迟可能会高，但不知道会高在哪。”
  • 未知的未知：你根本没想到的故障模式。出事之前，你甚至不知道该担心它。
  • （第四象限”未知的已知”——你忽视的已知风险，是组织问题，按下不表。）

监控与指标的领地

监控和 指标是预判的产物，所以它们的领地，恰好是前两个象限：

  • 已知的已知：完美覆盖——你预设的检查项、你埋的指标。
  • 已知的未知：部分覆盖——你用 RED/USE 这样的普适方法，给”可能出问题但不确定细节”的地方布上信号。

在这两个象限里，经典范式是高效且正确的。问题出在第三个象限。

可观测性的领地：未知的未知

分布式系统最难、最致命的那类故障，几乎全部落在”未知的未知”里——因为它们是涌现的。没有任何单个组件失败：服务 A 正常，服务 B 正常，数据库正常。但 A 在某次流量尖峰下对 B 的重试，叠加 B 恰好在做 GC，叠加这批请求恰好都来自启用了某个新特性的 2.3.1 版本客户端——这三件正常的事，组合出了一个异常。

这种故障，你预先想不到，因为它不在任何单个组件里，而在组件的特定组合里，而组合是组合爆炸的。你不可能给每一种可能的组合预先埋点。监控对它系统性失明，不是因为监控不够好，是因为它的前提（可预判）在这个象限根本不成立。 而可观测性的全部存在意义，就是攻克这第三个象限——让你能在事后，把一个你从没想到的问题问出来。

“任意提问”的真正含义

所以”任意提问”不是一句营销话术，它有精确的工程含义：问题在故障发生之后才被定义，而系统当时保留的数据，足以回答这个尚未被定义的问题。

举例：故障发生了，你逐步逼近——“是不是某个版本？”→“2.3.1 版本里，是不是某个平台？”→“2.3.1 + iOS 里，是不是某个地区？“。这条提问链上的每一个维度（版本、平台、地区），你在埋点时都没有专门为这次故障准备过。可观测性要求的，就是这些维度当时都在数据里，等着你在事后把它们任意组合起来发问。这件事，技术上需要一个前提——而这个前提，是下一章的主角。

三、技术内核：高基数与高维度

可观测性听起来很哲学，但它能不能落地，取决于一个非常具体的技术条件。把它讲透，可观测性就从口号变成了工程。

要问任意问题，就要留任意维度——高维度

如果你想在事后按”版本 + 平台 + 地区 + 端点 + 用户层级”的任意组合发问，那么在数据采集的那一刻，这些维度就必须都在。少留一个维度，事后就少一个能问的问题。

高维度（high dimensionality），就是指每个事件携带很多个字段——不是三五个，而是几十甚至上百个：请求的每一个属性、用户的每一个特征、运行环境的每一个标记，能记的全记上。维度越多，你事后能提的问题空间就越大。

拥抱基数爆炸

但 指标那篇我们刚学过一条铁律：高基数字段（user_id、request_id）绝不能进指标，否则序列数笛卡尔积爆炸、Prometheus OOM。而可观测性最有价值的提问，偏偏要靠这些高基数维度——“是哪个用户？”、“是哪条请求？”

这就是可观测性和指标的根本分水岭：指标因为预聚合，必须把高基数挡在门外；可观测性因为不聚合、保留每个事件，反而要把高基数请进门。

高基数（high cardinality）：一个字段可能的取值数量。
  user_id：百万级   → 指标的死穴，可观测性的金矿
  trace_id：无限    → 指标绝不能碰，可观测性的主键
  status_code：~10  → 两者都能用

03 里指标的死穴，在这里成了地基。 可观测性不回避基数爆炸——它正面拥抱，然后用便宜的存储和（必要时的）采样去扛。这个”拥抱高基数”的决心，就是天平从资源端倒向提问端的那一下。

数据模型：wide events

那么，承载”高维度 + 高基数”的数据，长什么样？答案是 wide event（宽事件）：一次请求，在它的生命周期里，只产生一条极宽的结构化事件，把这次请求相关的一切都塞进同一条记录：

{
  "timestamp": "2026-06-06T14:32:07Z",
  "trace_id": "abc-123",
  "duration_ms": 1840,
  "http.method": "POST",
  "http.route": "/api/checkout",
  "http.status_code": 500,
  "user.id": "8f3a",
  "user.tier": "premium",
  "app.version": "2.3.1",
  "device.platform": "iOS",
  "geo.region": "ap-southeast",
  "db.query_count": 14,
  "db.slowest_ms": 1200,
  "cache.hit": false,
  "downstream.payment.status": "declined",
  "feature_flags": ["new_checkout", "fast_path"]
}

一条这样的事件，胜过散落在三处的指标 + 日志 + 追踪。因为它的所有字段都在同一行里，你可以在事后对任意字段的任意组合做切分、聚合、过滤——这正是前面那条提问链需要的。

wide events vs 时间序列

把它和 Prometheus 的时间序列并排，两种数据模型的世界观一目了然：

时间序列（Prometheus）宽事件（Wide Events）
存什么预聚合的数字每个事件的全部原始字段
基数必须低（否则爆炸）拥抱高基数
能问什么预设维度的”多少”任意维度任意组合的”哪一个/为什么”
成本极低、可预期高（数十到数百倍）
提问时机埋点时就决定事后才定义

这不是”谁取代谁”，是两种数据模型服务于两个象限：时间序列守”已知”，宽事件攻”未知”。Honeycomb 这类工具押注宽事件，Prometheus 押注时间序列——它们的分野，本质上是数据模型的分野。

四、实践：从三大支柱到统一宽事件

理论要落到工程实践。可观测性领域有一场仍在进行的辩论，恰好把”怎么落地”这件事的两条路线摆在了台面上：三大支柱 vs 统一宽事件。

经典做法：三大支柱

业界流传最广的可观测性入门说法，是”三大支柱（three pillars）“——Metrics、Logs、Traces。你部署三套系统：Prometheus 收指标、Loki/ES 收日志、Jaeger 收追踪。这个框架好记、好卖，是大多数团队今天的现状。

三支柱的代价：在筒仓间反复横跳

但三大支柱有一个结构性的病：它们是三个割裂的筒仓，数据彼此不通。 真实的排障现场是这样的：

  1. 你在 Grafana（指标）看到结账接口 P99 飙升；
  2. 你切到 Jaeger（追踪），手动找一条慢的 trace，发现卡在支付服务；
  3. 你再切到 Kibana（日志），用刚才那个 trace 的时间戳和 service，手工搜对应的日志，想看错误详情。

三个系统、三次上下文切换、靠时间戳和 id 手工关联——而且每一步你都只能看到这个筒仓预先决定让你看到的维度。割裂本身就是成本。 当你最焦虑、最需要快速定位时，你在三个工具间反复横跳、手工拼线索。

云原生做法：一条 canonical wide event

另一条路线（Honeycomb、以及”observability 2.0”的倡导者们主张的）是：别要三个筒仓，要一种足够丰富的原始数据——宽事件——让指标、日志、追踪都成为它的派生视图。

每个服务为每次请求发一条 canonical wide event（前面那样的宽事件）。需要趋势？从宽事件实时聚合出指标。需要某次请求的上下文？那条宽事件本身就是日志。需要因果链？宽事件带着 trace_id 和 span 信息，拼起来就是 trace。一份数据，三种视图，永远在同一个维度空间里，不再需要跨系统手工关联。 这是把前面那个”反复横跳”从根上消掉。

（要诚实：宽事件路线很美，但它对存储和工具的要求高，三大支柱仍是当下多数团队的务实选择。两者更像光谱的两端，而非对错。）

Honeycomb 与探索式分析

数据模型变了，工作方式也跟着变。经典范式是”仪表盘驱动”——你预先做好图表，盯着它，等某根线变红。但宽事件支持一种全新的姿势——“探索式分析（exploratory analysis）”：

出事了，你不去翻预设的仪表盘，你打开一个高维数据集，开始交互式地提问——按 app.version 分组看看？P99 高的都集中在 2.3.1？那在 2.3.1 里按 device.platform 再分？iOS 特别高？再按 geo.region 切……每一步都是即时的、自由的下钻。

Honeycomb 有个标志性功能叫 BubbleUp：你框选出”慢的那些请求”，它自动对比这批请求和正常请求，告诉你它们在哪些维度上显著不同——“这批慢请求，91% 来自 app.version=2.3.1 且 device.platform=iOS”。它把”大海捞针”自动化成了”机器告诉你针在哪个维度的组合里”。 这是仪表盘永远做不到的——因为仪表盘只能展示你预先想到的切面。

★ 故障剧场：看不见的那类用户

把这一切落到一个具体的故障上。

你发布了 2.3.1 版本。整体指标几乎没动：总错误率从 0.2% 升到 0.35%，P99 抖了一下就回去了——所有仪表盘都是绿的或接近绿的，因为受影响的用户被淹没在海量正常请求里。但客服开始零星收到”结账转圈圈”的投诉。

用 指标，你查不出来：0.35% 的错误率不会触发任何告警，而且就算你盯着它，它也不会告诉你”是谁”。你想加个 user_id 维度去定位？指标会 OOM（03 的故障剧场）。

用宽事件，你三次下钻就到底了：按 http.status_code 过滤出 500 → 按 app.version 分组，发现 500 几乎全在 2.3.1 → 在 2.3.1 里按 device.platform + geo.region 分组，发现是”iOS + ap-southeast”的组合——这批用户的某个 CDN 节点返回了过期的支付配置。这个故障只伤害了一小撮特定组合的用户，它在聚合数字里是隐形的，但在高维宽事件里，一问即现。 这就是”未知的未知”被攻克的样子。

五、代价：可观测性不是免费的午餐

到这里，可观测性看起来像银弹。但 那把尺子提醒我们：没有免费的可见性。这一章，我们诚实地算账。

存储的账单与采样的必然

宽事件保留每一次请求的几十上百个字段，存储成本是预聚合指标的数十到数百倍。一个高 QPS 的系统，全量保留宽事件的账单会迅速变得不可承受。

于是几乎所有可观测性系统都要采样（sampling）——不保留每一条，只保留一部分（比如 1%-10%，或者更聪明地：保留全部出错的、全部慢的，加上一小撮正常的作为基线）。采样是用”完整性”换”成本”的取舍，它本身是一门学问——头部采样还是尾部采样？怎么保证采到的样本对排障有代表性？这些问题，是 下一篇追踪的核心议题，这里先埋下。

工作方式的门槛

探索式分析很强大，但它要求工程师会提问，而不只是会看图。仪表盘是把答案预先准备好喂给你；探索式分析是给你一片数据的旷野，让你自己用假设去切割它。这是一种更高的能力门槛——它要求你对系统有 mental model，知道该往哪个维度下钻。工具给了你任意提问的能力，但提问本身仍是人的技艺。 团队若没准备好这种文化转变，再好的工具也会退化成又一个没人看的仪表盘。

规模的分水岭

01 反复强调的错配，在这里要再说一次：可观测性是为复杂度买单的，不是为时髦买单的。 一个百人团队、几个服务的产品，故障大多落在”已知”象限，指标 + 日志完全够用——上全套宽事件 + 采样 + 探索式分析，是把运维负担和账单凭空翻几倍。可观测性的价值，和你”未知的未知”象限的故障占比成正比。这个象限小，它就是过度投资。

它没有取代指标

最后澄清一个常见的误读：可观测性不是来取代指标的。指标依然是最便宜、最适合做趋势和告警的信号——你不会想用宽事件去画一条”过去一年的 QPS 曲线”，那太贵且没必要。

正确的关系是分工：指标守住”已知”象限的趋势与告警（便宜、高效），可观测性补上”未知”象限的事后追问（昂贵、强大）。健康的系统两者都有。可观测性扩展了你能力的边界，而不是把旧能力推倒重来。

六、小结：坐标与去向

可观测性在五维标尺上的坐标

用 那把尺子给可观测性定位，并和经典三篇连成完整的一条迁移线：

维度经典范式（02-04）可观测性（05）
① 故障预判权人预判机器事后回答——放弃预判，攻”未知的未知”
② 存储汇率预聚合 / 中间地带高基数全量——拥抱基数爆炸，存下个体
③ 信号分工三类信号各自割裂走向统一宽事件——一份数据派生三视图
④ 注意力阀门基于原因为 SLO 让路——本篇尚未展开
⑤ 仪器化负担手写、机会主义更系统、也更重——要刻意为高维度埋点

天平在这一篇，第一次整体倒向了提问端。这就是经典范式与云原生范式的分界线——前四篇天平在资源端来回挪动，从这一篇起，它落到了”留下一切、事后任意提问”的另一边。

去向

可观测性立起了”任意提问”的世界观，但它留下了几个具体的工程问题，正好交给后面几篇：

那个贯穿全系列的问题，云原生范式的第一次回答：可观测性把天平推向了哪边？留下一切、机器事后回答——它用昂贵的高基数存储，赎回了指标永远给不了的东西：问出你从没想到要问的问题。下一篇，我们深入这条”因果链”本身，看追踪如何把宽事件串成一次请求的完整旅程。

返回 可观测性与运维工程 MOC ｜ 上一篇 04-日志-结构化事件的叙事力量 ｜ 下一篇 06-分布式追踪-因果链的精确重建

关系图谱