全景图：七组共 22 个概念

一张地铁线路图：先看到所有线路的全貌，再一站一站地坐过去。

先是三个基础——为什么在生产环境里你只能靠仪表飞行，monitoring 和 observability 有何不同，以及什么是 black box。然后是六组，每章一组：logs、metrics、traces、三大支柱如何合在一起用、alerting，以及如何用好它。

下面每个概念都是同一个结构：它的英文名称（记住它——这就是术语）、一幅生活中的画面、一张图，以及一张带字段的卡片：问题、思路、例子、代价或注意、何时使用、关联。

Flying by Instruments — 你没法给生产环境挂上 debugger

飞行员不能在飞行途中爬出去检查发动机——他完全靠仪表盘上的仪表飞行，相信表盘告诉他的一切。

在笔记本上，你可以暂停代码、查看变量、单步执行。在生产环境——真实的服务器、真实的用户、就在此刻——你没法停下它来看。你只能从系统运行时发出的信号里了解发生了什么。

这就是核心的转变：在生产环境里你靠仪表飞行，而 observability 就是在需要之前，先把正确的仪表装在仪表盘上。

Monitoring vs Observability — 已知的问题与新问题

汽车仪表盘显示的是你早就知道要盯的那几样——车速、油量、温度。但当出现一种陌生的新噪音时，你需要能去调查一个没人给它装表盘的东西。

Monitoring 是盯着你预料到的问题——针对已知故障模式的 dashboard 和告警。Observability（常写作 o11y）是更深一层的特性：只凭系统产生的数据，你能不能回答你没有预见到的问题？

真正的故障往往是前所未有的——"为什么巴西的用户从下午两点起结账很慢？"——而 observability 就看你的系统发出的数据够不够让你去追一个你从没计划过的问题。

Black Box — 只能靠猜的系统

一台吞了别人钱却什么都没吐出来的自动售货机，没有显示屏，也没有小票——你只能耸耸肩去猜，因为它什么都不告诉你。

一个很少发出信号的系统就是 black box：它出问题时，你只剩下猜和重启。代价出现在最糟的时刻——一场生产事故，每一分钟都很宝贵，而你完全不知道该往哪儿看。

Observability 是提前付出的，在系统平静的时候就给它做埋点（instrumenting），这样当它着火时，你才有光可以照亮。

Log — 系统的日记

船上的航海日志：带时间戳的条目记录发生了什么、何时发生——"10:42，驶入港口"——这样任何人事后都能还原整段航程。

Log 是一个事件带时间戳的记录："用户 42 登录了"、"支付失败：银行卡被拒"、"开始处理订单 91"。每一行都是一条小而详细的笔记，记下发生的某件事，在代码运行时写下。

Logs 是信息最丰富的信号，因为它们带着具体细节——到底是什么、到底何时、附带哪些细节。当你需要知道某一个案例里到底发生了什么，就去看 logs。

Structured Logging — 可以搜索的 logs

一盒手写笔记和一张电子表格的区别——两者都记着事实，但只有后者能让你立刻筛出与客户 42 有关的一切。

一行自由文本，在几百万条记录里很难搜。Structured logs 把每个事件记成数据——比如 user_id: 42、status: failed、duration_ms: 230 这样的字段——这样你就能查询："显示今天所有超过 500ms 的失败支付。"

这把 logs 从一面要不停滚动的文字墙，变成了一个可以审问的数据库。有了结构，logs 才能在生产规模下用得起来。

Log Levels — 把信号和噪声分开

一本日记：日常条目用铅笔写，紧急情况用红笔写——这样遇到危机时，你能直接翻到红色的那些，忽略其余。

每条 log 都有一个标记重要程度的级别：DEBUG 和 INFO 用于日常细节，WARN 表示有点不对劲，ERROR 表示真正的故障。级别让你在调查时调大音量，在正常运行时调小，并在一大堆记录里直接跳到错误。

用好了，级别能让重要的行始终找得到；被忽视了，每条 log 看起来都同样紧急，没有一条显眼。

Log Volume — log 太多和太少一样没用

一本把每一次呼吸都记下来的日记，和一本空白的日记一样没法读——你需要的信号被埋在没人筛得完的噪声里。

Logs 很容易被滥用，而 over-logging 有实实在在的代价：存储贵、搜索慢，还会把重要的行埋进噪声里。

关键在于记下你以后真正会想要的东西——决策、故障、关键事件——细节够用就行，别多到把信号淹没。记 log 要有目的，别凭条件反射。

Metric — 随时间变化的一个数字

医院里记录整夜心率的图表——不是每一次心跳，而是稳定采样得到的那个数字，所以一条上升的趋势会一下子跳出来。

Metric 是随时间追踪的一项度量：每秒请求数、错误率、响应时间、已用内存。和 log 不同，它说的不是某一个事件——它是聚合，被持续采样，所以你看到的是趋势和尖峰。

Metrics 采集和存储都很便宜，因为它们只是数字，这意味着你可以对所有东西、一直保留它们，并看着系统的形态变化。

Counter vs Gauge — counter 一路上升，gauge 上下摆动

里程表只会一路往上，数着一共开过多少英里；速度表则随你此刻的快慢起起落落。

两种基本形状涵盖了大多数 metrics。Counter 只增不减——已处理的请求总数、错误总数——你要看的是它的变化速率。Gauge 上下移动，显示当前值——正在使用的内存、活跃连接数、队列长度。

知道自己看的是哪一种，就知道该怎么读它：counter 看的是斜率；gauge 看的是当前的高度。

Dashboard — 让趋势看得见

控制室里一整面墙的仪表：操作员一眼就能看出一切都是绿色且平稳，或者哪个表盘正朝红色爬升。

Metrics 通常在 dashboard 上查看——把关键数字随时间变化的图并排摆在一起。好的 dashboard 能让你几秒钟内看清系统的健康状况，并发现某条线是在哪一刻拐向了不对的方向。

Metrics 的价值就体现在这里：不在任何单个数值，而在那条可见的趋势——它在用户还没抱怨完之前就告诉你"下午两点起有什么开始出问题了"。

Four Golden Signals — 服务的生命体征

医生快速检查生命体征——脉搏、体温、血压、呼吸——一小组指标，不必什么都测，就能发现大部分问题。

起步不需要一千个 metrics。Four golden signals 涵盖了系统大部分的健康状况：latency（请求要多久）、traffic（有多少需求）、errors（有多少请求失败）和 saturation（你的资源有多满）。

盯住这四个，你就能及早发现绝大多数问题。它们是服务的生命体征——是最先该装到仪表盘上的几个表盘。

Trace — 一个请求穿过各服务的路径

包裹的追踪记录：在这里揽收，在那里分拣，空运过去，最后送达——一个包裹经过每一双手的完整旅程。

在现代系统里，一个请求会跳过很多服务——gateway 调用订单服务，订单服务调用支付，支付再调用数据库。Trace 记录一个请求的整段旅程，把它缝合起来，让你看到它跳过的每一站。

它回答的问题，logs 和 metrics 都回答不了：不是"发生了什么"或"有多少"，而是"这一个具体的请求在整个系统里走的是什么路径？"

Span — 时间花在了哪里

一份分成几段的旅行行程，每段都有自己的时长——一眼就能看出吃掉一整天的是那三小时的中转，而不是航班本身。

Trace 由 spans 组成——每一步一个，各自记录那一段花了多久。摊开成瀑布图（waterfall），spans 会准确显示一个慢请求把时间花在了哪里：数据库的 span 用了 900ms，其他所有加起来才 50。

没有它，"请求很慢"就是一个横跨许多服务的谜；有了它，你能直接指出罪魁祸首。Spans 把含糊的"慢"变成了精确的位置。

Distributed Tracing — 你如何调试分布式系统

在接力赛里把一根掉落的接力棒一路倒查回去，找出究竟是哪一次交接出了错——光看最终结果是看不出来的。

当一个请求失败或慢得像爬，而工作分散在各个服务之间时，trace 往往是找出问题所在的唯一办法。这就是 distributed tracing。

Metrics 告诉你系统慢；logs 告诉你每个服务说了什么；trace 把一个请求的路径串起来，指出究竟是哪个服务、哪一步出了问题。对任何分布式的东西来说，tracing 就是那个把"里面某个地方出错了"变成"就是这里"的工具。

Three Pillars — 各自回答不同的问题

用三样工具调查一个问题：一张图表显示什么时候发生了变化，一张地图显示在哪里，一份详细报告显示究竟是什么——单独都没用，合起来才有决定性。

Observability 的三大支柱把工作分了工。Metrics 回答"有没有哪里不对，趋势如何？"——便宜、始终开着的全景。Traces 回答"在所有服务之中，问题出在哪里？"——把范围缩小到某一步。Logs 回答"那里究竟发生了什么？"——现场的全部细节。

任何一个单独都不够；每一个都接着其他几个停下的地方往下走。

Notice → Locate → Explain — 自然的流程

医生在体温单上看到发烧，接着检查找出是哪个器官，再做那项能指出病名的具体检验——先是宽泛的信号，再收窄，最后精确。

实际中你是按顺序走过它们的。一个 metric 或告警告诉你出事了（错误率跳高）。一个 trace 告诉你在哪里（支付服务那一步在失败）。那个位置上的一条 log 告诉你究竟是什么（支付服务商返回了超时）。

从宽泛到收窄再到精确：metric 发现，trace 定位，log 解释。懂得这个流程，就懂了调试生产环境的大半。

Correlation ID — 把一切串起来的那根线

在每一份文件、照片和报告上都写上同一个案件编号——这样调查员就能把一起事件的所有东西拉到一起，而不必逐堆分别去找。

支柱之间一旦连起来，就强大得多。给一个请求的 metrics、trace 和每一行 log 都附上同一个 request ID（或 trace ID），你就能从"这个请求失败了"直接跳到它的 trace 和它确切的 logs。这就是 correlation（关联）。

没有 correlation，你面对的是三堆互相独立的干草垛；有了它，一拉就把一起事故的完整故事带到你面前。支柱之间的连接，让它们成为一个体系，而不是三件工具。

Symptom-based Alerting — 针对用户能感受到的东西告警

烟雾报警器应该在真的起火时响，而不是每次有人烤面包就响——否则人们会把电池抠掉，反而错过真正的那一次。

告警（alert）是某个东西越过一条线时自动发出的通知。关键在于针对用户真正能感受到的症状告警——结账在失败、网站很慢——而不是针对每一次内部的小抽动。

服务器内存用到 80%，只要用户一切正常，就不是问题；订单失败数激增就是问题，即使每台服务器看起来都健康。针对面向用户的结果告警，你叫醒人的时候就都是真正重要的事。

SLI / SLO / SLA — 定义什么叫够好

一家快递公司承诺"99% 的包裹两天内送达"——一条清晰、可衡量的标准，说明什么算可接受的服务，事先就说好了。

三个缩写把"多好才算够好"正式化了。SLI（service level indicator，服务水平指标）是度量（在 300ms 内完成的请求所占的百分比）。SLO（service level objective，服务水平目标）是你为它定的目标（应该达到 99.9%）。SLA（service level agreement，服务水平协议）是对客户的合同承诺，做不到要承担后果。

定下一个明确的 SLO，就把可靠性从一种模糊的感觉，变成了一个能用来要求系统的数字——也变成了一条何时该行动的清晰界线。

Alert Fatigue — 无声的杀手

一辆为琐事不停哔哔响的车，会让司机学会无视所有哔声——于是真正重要的那次警告，也跟着其余的一起被屏蔽了。

告警太多本身就是一种失败：当人们为不重要的事被呼叫，他们就会开始完全无视告警，而真正的那一条就在噪声里被漏掉——这就是 alert fatigue（告警疲劳）。

每一条告警都应该是可执行的，并且值得人此刻就投入注意力；如果不是，它该放在 dashboard 上，而不是 pager 里。少而精的告警胜过一大片，因为一个没人信任的告警，比没有告警还糟。

Instrument as You Build — 别等火烧起来之后

盖房子的时候就把烟雾探测器接好——而不是站在浓烟里，后悔自己没装。

加 observability 最糟的时机，就是在故障期间，那时你才发现系统什么都没告诉你。所以你要边做边把埋点（instrumentation）做进去：为新功能发出一个 metric，记下它的关键决策，确保一个请求能被一路 trace 过去。

趁代码还新鲜时加一点点埋点，能省下以后好几个小时的盲猜。把"我在生产环境里怎么看到它？"当作构建它的一部分，而不是事后才想起来的东西。

Start Small and Grow — 从 golden signals 开始

新开店的店主起初只盯着那几个重要的数字——销售额、客流量、投诉——只有当出现具体问题时才加上更细的追踪。

你第一天不需要全面覆盖。从 four golden signals 和几处关键决策点上的少量 logs 开始，然后在真实事故暴露出盲区（blind spot）的地方，再补上细节。

每一次故障，都是一堂"你真希望当时记录了什么"的课——所以让你的 observability 顺着系统真正让你吃惊的地方生长，而不是一开始就把所有东西都埋上点。

这些概念如何连在一起

飞机的仪表盘：十几个表盘，但全都关于同一次飞行——飞行员是把它们放在一起读的。

本课里的一切，都是同一块仪表盘的一部分。一个运行中的系统发出三种信号：metrics 发现，traces 定位，logs 解释。Correlation ID 把这三者绑到同一个请求上。Metrics 和 golden signals 喂给 SLI 和 SLO，而它们驱动 symptom-based alerts——少而精，所以没有 alert fatigue。而仪表盘本身会随着你边做边埋点，以及在真实事故之后补上细节而不断生长。