9.2 可观测性与遥测

概述与动机

遥测是一个系统关于自身行为所发出的数据：从运行中的软件收集到的指标、日志、追踪和事件。监控回答的是你早已知道要问的、来自这些遥测数据的问题。磁盘满了吗？错误率超过阈值了吗？服务在线吗？可观测性的范畴更广。它是一种能力，让你能从外部就系统的内部状态提出新的问题，而无需发布新代码，从而理解你从未预料到的行为。随着系统演变成分布式、微服务和事件驱动架构，最伤人的故障往往是没有人预见到的那些，而可观测性正是让你能够调试它们的东西。监控告诉你出了问题。可观测性帮你弄清楚为什么。

对于大型团队而言，这个区别是决定性的。你可以靠读一台机器上的日志来理解一个单体应用。而一个现代平台横跨数百个服务、多个团队、多个区域和第三方依赖，一个用户请求可能会触及数十个组件。没有一个人能把整个系统装在脑子里。共享的、高质量的遥测数据成为连接组织，让任何一位工程师都能跨越边界追踪一个请求、在各个服务之间对齐症状、并对一个没有人完全拥有的系统进行推理。没有它，事件会拖延不决，责任会在团队之间来回推诿，根本原因始终隐而不现。

企业和政府系统因合规、可审计性和公共问责而提高了风险。监管机构可能要求提供谁在何时访问了什么的证据。安全团队需要遥测数据来检测入侵。面向公民的服务必须证明自己达到了公开承诺的性能标准。良好的可观测性能同时服务于所有这些需求：它既是一种工程工具，也是一种安全控制手段，还是一种问责机制，三者合一。在开放式插桩上实现标准化，可以避免被锁定在单一供应商的专有代理上，当系统必须持续数十年并挺过采购周期的更迭时，这一点极其重要。

另见： 第 9.1 章（站点可靠性工程与 SLO）、第 9.3 章（事件管理）以及第 3.3 章（分布式系统）。

关键原则

为未知的问题做插桩。 设计遥测数据，使你能够调查超出你预测范围的新型故障。
三大支柱，一个故事。 指标、日志和追踪是互补的视角；当它们被关联起来而不是各自孤立时，其价值会成倍放大。
一切都要结构化。 带有一致字段的结构化、可被机器解析的遥测数据，胜过只有人能读懂的自由文本。
用共享标识符做关联。 在各处传播的追踪 ID 和请求 ID，让你能把单一事件在各个服务之间串联起来。
对症状告警，而不是对原因告警。 用寻呼把人叫起来是为了用户可见的问题；让仪表盘和调查去揭示背后的原因。
每一次寻呼都必须是可采取行动的。 一个不需要人采取任何行动的告警就是噪音，会侵蚀信任并导致疲劳。
高基数是一项特性。 能够按用户、请求、区域和版本切片查看的能力，正是让生产环境调试成为可能的关键。
拥有你自己的插桩。 在开放的、供应商中立的遥测标准上实现统一，这样你才能掌控自己的数据，并能够切换后端。

建议

建立在三大支柱及其之上

指标是数字化的时间序列，存储成本低廉，非常适合用于仪表盘、趋势和告警阈值。日志是离散的、带时间戳的事件记录，细节丰富，对取证调查至关重要。追踪跟随单个请求在各服务之间的流转，展示出跨越分布式调用图的延迟和依赖关系。在这些之外，还可以考虑事件（有意义的状态变化，如部署）、性能剖析（代码在哪里消耗 CPU 和内存），以及针对真实客户端体验的真实用户监控。任何单一支柱本身都不够用。目标是在调查过程中能在它们之间灵活切换。

在 OpenTelemetry 和结构化日志上实现标准化

采用 OpenTelemetry 作为生成和收集指标、日志与追踪的供应商中立标准。它把插桩与分析后端分离开来，这样你就能在不需要为数百个服务重新插桩的情况下更换供应商。这个特性对于长期存续的企业和政府系统至关重要。把日志作为结构化记录（例如 JSON）发出，并对时间戳、严重程度、服务和标识符使用一致的字段名。把一个追踪或关联 ID 从边缘一路传播到每一次下游调用，并将其包含在每一条日志和每一个指标示例中，这样三大支柱就能自动关联起来。

为可操作性和低噪音而设计告警

你的告警理念决定了值班制度是否可持续。主要针对用户能感受到的症状告警，这些症状以 SLO（服务水平目标）消耗率的形式表达。当你消耗错误预算（相对于该目标所允许的差额）的速度快到即将突破它时，就触发寻呼，使用多窗口消耗率告警，在快速检测和误报之间取得平衡。把寻呼留给需要人立即采取行动的问题，其余的一切都路由到工单或仪表盘。毫不留情地修剪那些触发时不需要任何行动的告警，因为告警疲劳是导致真实事件被漏掉、值班人员倦怠的一个主要原因。每一个告警都应该链接到一份操作手册。

用仪表盘和 SLO 监控来建模健康状况

围绕一个清晰的健康模型来构建仪表盘，而不是把你拥有的所有指标堆成一面墙。一个好的入门框架是”四大黄金信号”：延迟、流量、错误和饱和度。创建能一眼看出 SLO 状态和剩余错误预算的服务级仪表盘，再加上能对整体系统和用户旅程健康状况建模的更高层级仪表盘。要刻意地对它们进行精心筛选，因为一个展示所有内容的仪表盘等于什么都没传达。让它们靠近告警和操作手册，这样响应者才能迅速从信号走向上下文、再走向行动。

用高基数实现生产环境调试

最棘手的生产问题往往只命中一个狭窄的切面：一个客户、一个区域、一个 API 版本、一种设备类型。要调查它们，你需要高基数遥测数据，即按拥有大量不同取值的字段（如用户 ID 或请求 ID）进行分组和过滤的能力。每条记录带有丰富属性、维度众多的宽事件，让你能够事后提出任意的问题。保留足够的基数和采样保真度，以便能够隔离出异常值，并优先采用与示例关联的追踪，这样一个指标上的尖峰就能直接带你找到具有代表性的慢请求。

管理成本、留存和采样

遥测数据量会随系统一同增长，并可能演变成一项重大开支。按数据类别设定留存策略：高分辨率数据只短期保留，聚合数据保留更久。对追踪数据采用智能采样，偏向于保留错误和慢请求，这样你就能保留感兴趣的长尾数据，而不必为每一次常规的成功都付费。定期评审你的遥测支出，因为失控的可观测性成本可能会与它所观测的基础设施本身不相上下。

权衡：优点与缺点

决策	优点	缺点
高基数事件	调试能力强，可以问任何问题	存储和查询成本更高
激进采样	成本更低，噪音更少	可能错过罕见事件
基于症状的告警	寻呼更少、更可操作	需要良好的 SLO 才能奏效
OpenTelemetry 标准	供应商中立，可移植	迁移工作量大，工具仍在成熟中
长期日志留存	更好的取证和审计能力	存储成本，隐私风险敞口

可观测性方面的决策，归根结底是保真度与成本之间的张力。以完整分辨率捕获一切能给你完美的后见之明，但在大规模场景下代价高得令人望而却步。激进地削减虽然能省钱，却可能丢掉那唯一能解释一次停机事件的记录。采样和留存分级是成熟团队走这条钢丝的方式，在保留错误和异常值的同时稀释常规数据。告警方面的权衡在于灵敏度与噪音之间：告警太多会导致疲劳和漏报真实事件，太少则会让问题持续恶化。基于症状、由 SLO 驱动的告警能化解这个矛盾的大部分，但前提是你已经建立了有意义的 SLO。

与团队讨论的问题

你把遗留服务迁移到 OpenTelemetry 的计划是什么？你如何避免在过渡期间同时为两套插桩体系买单？ 供应商中立的插桩，正是让你能在不为数百个服务重新插桩的情况下更换后端的特性，而这一点对那些比任何单一供应商合同都活得更久的、长期存续的企业和政府系统最为重要。迁移正是良好意愿容易搁浅的地方：只完成一半插桩的资产，恰恰会在请求从一个新服务跨越到一个旧服务时留下缺口，打断端到端的追踪。把一份清单带到讨论中：哪些服务发出专有代理数据、哪些发出 OpenTelemetry 数据，以及追踪上下文在哪个边界处被丢失。确定一个遵循真实请求路径、而不是遵循组织架构图的迁移顺序，并为同时运行两套采集器的窗口期做好预算。这个答案决定了你到底是真正拥有自己的遥测数据，还是仍被锁定在某个供应商的代理上。
你上一次审查每个告警的可操作性是什么时候？上个月有多少次寻呼没有需要任何人的行动？ 告警疲劳是导致真实事件被漏掉、值班人员倦怠的一个主要原因，所以一次不需要行动的寻呼不是无害的噪音，它在实际侵蚀你所依赖的响应能力。把证据带来：调出上个月的寻呼记录，把每一条标记为”已采取行动”或”被忽略”，数一数有多少条对应到一份操作手册。对于横跨众多服务的大型团队而言，来自某个团队的嘈杂告警会让每个人对共享的值班机制变得麻木。设定一条标准：每一次寻呼都要链接到一份操作手册，并与一个 SLO 消耗率挂钩，然后毫不留情地删除其余的。这次审查的结果应该直接削减你的寻呼量，并告诉你哪些服务的告警背后并没有有意义的 SLO 支撑。
你的追踪采样策略是什么？你有多大把握它能保留住错误和慢请求这条长尾？ 遥测数据量随系统一同增长，失控的可观测性成本可能与它所观测的基础设施本身相当，所以你终究会采样，问题在于你是否智能地采样。剥离基数或盲目采样，恰恰会移除掉用来调试那些只命中一个客户、一个区域或一个 API 版本的狭窄问题所需要的记录。带上你当前的留存分级和采样规则：你是否偏向于保留错误和慢请求，是否使用与示例关联的追踪，让一个指标尖峰能直接带你找到一个具有代表性的慢请求？对于受审计和隐私约束的系统，要把留存策略与数据最小化规则协调一致，避免为了调试而囤积个人数据。这个答案决定了你把遥测预算花在哪里，也决定了你下一次严重停机事件是可以解释的，还是一个谜。
你的哪些 SLO 是真实的用户旅程承诺，哪些是除了负责团队之外没人相信的代理指标？ 基于症状的告警只有在症状映射到用户真正能感受到的东西时才有效，所以一个绑定 CPU 阈值或一个凭空捏造的可用性目标的告警，会为可能并不重要的问题寻呼人们，同时对真正重要的问题保持沉默。对于一个大型组织，SLO 也是一份契约，让独立的团队能够共享一个值班轮值表，而不必在每次事件中重新争论严重程度。带上当前的 SLO 目录、每个目标本应保护的用户旅程，以及上一季度的违规情况，看看客户是否真的投诉过。在企业和政府环境中，把最显眼的 SLO 与该服务所背负的、已公开承诺的性能指标挂钩起来，这样同一个用来寻呼工程师的消耗率信号，也就是你向监管机构或监督机构展示的证据。这场讨论应该淘汰掉那些代理指标，留给你一份简短的目标清单，其中每一项都是一个非工程师也能认出来是对用户承诺的东西。
谁负责遥测数据的治理？你能证明个人数据在进入你的可观测性后端之前已经被脱敏了吗？ 高基数事件和长期日志留存，正是让调试成为可能的那些特性，也恰恰是让一个可观测性存储变成你用户个人数据的失控副本的那些特性。这里的对立拉力是真实存在的：工程师想要更丰富的属性和更长的留存期，而隐私和法务部门想要数据最小化和更短的生命周期。带上一份数据流地图，展示哪些字段携带个人或敏感数据、脱敏或令牌化发生在流水线的哪个环节，以及你按数据类别划分的留存分级是什么。对于受监管和公共系统，指明问责的负责人，把留存策略与你所依据的合法依据和数据最小化规则对应起来，并做好准备向审计员证明，对遥测数据本身的访问也是被记录和受控的。这个答案决定了你的可观测性平台究竟是一项资产，还是一次等待被发现的既成违规。
当一次事件跨越了几个团队的服务时，你的遥测数据能否让一位响应者端到端地追踪这个请求？还是说线索会在每一个所有权边界处中断？ 关联的、传播了 ID 的遥测数据，其全部承诺就在于让一位工程师能够对一个没有人完全拥有的系统进行推理，而这个承诺恰恰会在追踪上下文被丢弃、或两个团队使用不兼容的标识符和工具的边界处崩溃。要权衡各团队在选择可观测性工具上的自主性拉力，与一个碎片化资产的共享成本之间的关系，在停机事件中，每一次交接都可能变成一条死路。带上一份近期跨团队事件的时间线，标出响应者在哪里丢失了线索，再加上一份清单，列出哪些服务传播了一个共同的关联 ID、哪些没有。对于一个由众多供应商和长期存续系统拼凑而成的大型企业或政府平台，要决定你在多大程度上要中央统一强制规定（）一套共享的追踪上下文标准和一套通用的 ID 方案（）与你留给各团队自行决定的部分之间的界线，因为那些你在数十年间反复重新采购的组件，仍然必须在同一个请求上实现互操作。这个答案会告诉你，你下一次跨团队事件将是一场协同的调查，还是一轮互相推诿。

行业视角

创业公司。 只有寥寥几个服务、也没有多余的人手，从第一天起就用 OpenTelemetry 做插桩，并发布带有一个端到端请求 ID 的结构化 JSON 日志。这项小小的投入能把”应用很慢”变成一条你能读懂的追踪，也让你以后能从免费套餐迁移到付费后端而无需重新插桩。在你拥有真正能衡量其体验的用户之前，先跳过精细的仪表盘和 SLO 体系。

小型企业。 你没有可观测性专家，预算也紧张，所以要依靠一个把插桩、存储和仪表盘都打包在一起的托管后端，而不是自己搭建一整套技术栈。在这里，“买还是造”的决定几乎总是倾向于购买；把你稀缺的注意力花在那两三个能告诉你服务是否宕机的黄金信号告警上，比自己运行一整条遥测流水线更划算。设定一个硬性的留存上限，这样遥测成本就不会悄悄超过它所监控的基础设施本身。

企业。 这里的工作是跨众多团队的治理：一套共享的 OpenTelemetry 标准、一套通用的关联 ID 方案，以及经过精心策划的 SLO 仪表盘，让单个响应者能够跨越数十个服务追踪一个请求。把遥测数据当作一个成本中心来管理，配有留存分级和采样策略，统一以 SLO 消耗率为基础的告警，以维持共享值班制度的可持续性，并集中修剪嘈杂的告警，这样一个团队的疲劳就不会让所有人都变得麻木。把插桩层当作能超越任何单一后端合同而存续的、供应商中立的基础设施来对待。

政府。 采购规则、透明度和公共问责塑造着设计。在开放式插桩上实现标准化，这样一个预期要运行数十年的系统，就能在被不同供应商重新采购时存活下来，而不会被专有代理绑架，并要求把这种可移植性写进合同。使用结构化审计日志，展示谁在何时访问了哪条记录，在个人数据抵达遥测存储之前对其进行脱敏或令牌化处理，并把留存策略与数据最小化法律协调一致。为面向公民的服务发布 SLO 仪表盘，这样你的工程师所关注的同一批信号，也就是你所背负承诺的可见证据。

示例

创业公司。 一家四人规模的创业公司发布了一个移动端后端，却不断收到”应用很慢”这类它无法复现的模糊投诉。团队为其寥寥几个服务加上了 OpenTelemetry，并切换到带有请求 ID、从应用端一路传递经过每一跳的结构化 JSON 日志。下一次收到”慢”的报告时，几分钟内就解决了：一条追踪显示，在某个特定查询下，订单表缺少一个数据库索引。因为他们早早选择了开放式插桩，后来从免费套餐迁移到付费后端时，完全不需要重新插桩。

企业。 一个大型电子商务平台为每一个服务都装上了 OpenTelemetry，把一个追踪 ID 从客户的浏览器一路传播，经过结账、支付、库存和物流环节。当转化率下降时，一位值班工程师从一个 SLO 消耗率告警入手，打开结账仪表盘的黄金信号，发现某个区域的延迟升高，然后跟着一条示例追踪找到了单个服务中一次缓慢的数据库调用。高基数属性显示，问题局限于一个商品类别，这在几分钟内、而不是几小时内，就指引了一次精准的修复。

政府。 一家国家医疗服务机构在严格的审计和隐私规则下运营一个患者档案平台。结构化日志记录了谁在何时访问了哪条记录，同时为安全监控和合规报告提供数据，而可识别个人身份的字段在遥测数据中被脱敏或令牌化。公开的 SLO 仪表盘展示了面向公民的预约挂号服务的可用性和延迟情况。通过在开放式插桩上实现标准化，该机构避免了在一个预期要运行数十年、并在其生命周期中被不同供应商反复重新采购的系统上被专有锁定。

商业理由：动机、投资回报率与总拥有成本

可观测性的主要回报，是检测和解决事件所需时间的大幅缩短。对于一个停机代价高昂的服务而言，把平均解决时间从数小时缩短到数分钟，仅靠一次重大事件就能让工具投入回本数倍。可观测性还能节省本来要花在猜测、复现缺陷和争论谁该负责上的工程时间，并缩短反馈循环，让团队能有信心地发布。安全与合规方面的价值同样真实：同一套遥测数据既支持入侵检测，也能作为审计证据。

总拥有成本包括插桩工作量、遥测存储和查询成本，以及从噪音中筛选出有用信号所需要的纪律。这些成本是可见且经常性的，这会诱使领导层投入不足。而不采用它的成本更大，却更难看见：长时间的停机、未被诊断出的性能问题、发现得太晚或根本没被发现的安全事件，以及在他们无能为力的告警上被耗尽精力的工程师。用具体的事件数据来说明理由。展示近期停机事件的解决时长和业务影响，并推算更好的遥测数据能带来的改善幅度。把可观测性定性为一种同时能加快交付速度的保险，而不是一个纯粹的成本中心，这种说法更能赢得争论。

反模式与陷阱

对一切都告警。 为每一个异常都寻呼，会训练响应者去忽略告警，使真实事件溜过去。
基于原因的寻呼。 对内部原因而非用户症状告警，会用噪音淹没值班，并错过新型故障。
非结构化日志。 无法被查询或关联的自由文本日志，迫使人在事件中进行缓慢的人工搜索。
三大支柱各自为政。 指标、日志和追踪分散在互不连通的工具中、没有共享 ID，使人无法端到端地追踪一个事件。
仪表盘泛滥。 数百个未经筛选的仪表盘，意味着没有人知道该看哪一个才能判断系统是否健康。
基数坍缩。 为省成本而剥离高基数字段，恰恰移除了调试狭窄问题所需要的数据。
供应商锁定。 到处都是专有代理，使更换后端的代价高得令人望而却步，并劫持了你的数据。

成熟度模型

第 1 级，启动。 可观测性是临时性、被动响应式的。基本的正常运行检查和非结构化日志存放在各台机器上，调试意味着登录服务器去做文本搜索，也没有共享的遥测数据。告警嘈杂、基于原因，且常常被忽视，所以真实事件是通过用户投诉、而不是信号浮现出来的。

第 2 级，发展。 基本实践开始出现，但因团队而异。一些服务把指标和日志推送到一个中心位置，存在一些仪表盘和阈值告警，但日志只是半结构化的，追踪要么缺失、要么不完整。跨服务的关联是手动的，一位工程师能否端到端地追踪一个请求，取决于恰好涉及哪些团队。

第 3 级，标准化。 插桩在整个组织范围内有文档记录并被强制执行。跨服务的 OpenTelemetry、传播的追踪或关联 ID、字段名一致的结构化日志、分布式追踪、精心策划的黄金信号仪表盘，以及基于 SLO 的症状告警，是每个团队都遵循的标准。每一次寻呼都链接到一份操作手册并与一个 SLO 挂钩，值班制度是可持续的，而不是倦怠的根源。

第 4 级，管理。 可观测性资产本身依据基线被度量和管控。你追踪各服务的插桩覆盖率和追踪上下文传播率、被采取行动与被忽略的寻呼所占的比例、平均检测和解决时间、SLO 达成率和错误预算消耗情况，以及每个服务相对于预算的遥测成本。差距和告警噪音依据数据被逐步降低到明确的目标水平，采样保真度被验证以确保错误和慢请求的长尾记录得以保留，关于覆盖率和留存策略的通过／不通过决定依据证据而非主观判断来做出。

第 5 级，编排。 可观测性在整个组织范围内被持续改进和整合。高基数、事件丰富的遥测数据支持对任意切面进行即席调查，告警由 SLO 消耗率驱动，噪音降到最低，采样和留存策略随成本和风险的变化而调整。遥测数据作为例行工作的一部分，支撑着容量规划、安全检测和产品决策，该平台会随着系统、威胁态势和监管义务的变化，不断重新调校自身的信号、预算和覆盖范围。

讨论话题

对于你最关键的服务而言，遥测数据的保真度与成本之间正确的平衡点在哪里？
你如何决定什么该触发寻呼、什么该生成工单、什么只需要记录在仪表盘上？
对于不共享代码库或发布周期的团队，你传播关联 ID 的策略是什么？
你如何在满足隐私和数据最小化要求的同时，保留高基数的调试能力？
可观测性工具应该由中央统一强制规定，还是由各团队自行选择？两种做法各自的后果是什么？
你会如何向审计员证明你的遥测数据是完整且防篡改的？

关键要点

监控用来检测已知的问题；可观测性让你能够调查未知的问题，而无需发布新代码。
指标、日志和追踪在通过共享标识符相互关联、而非各自孤立时最有价值。
在 OpenTelemetry 和结构化日志上实现标准化，以在漫长的系统生命周期中保持供应商中立和可移植。
通过 SLO 消耗率对用户可见的症状进行告警，让每一次寻呼都可操作，并不遗余力地修剪噪音。
围绕一个清晰的健康模型（如黄金信号）来精心策划仪表盘，而不是展示每一个指标。
高基数、事件丰富的遥测数据，正是让调试狭窄的生产问题成为可能的关键。

参考文献与延伸阅读

Charity Majors, Liz Fong-Jones, George Miranda, Observability Engineering: Achieving Production Excellence
Cindy Sridharan, Distributed Systems Observability
Betsy Beyer et al., Site Reliability Engineering（关于监控和告警的章节）
Brendan Gregg, Systems Performance: Enterprise and the Cloud
OpenTelemetry project, specification and documentation (Cloud Native Computing Foundation)
Google, The Four Golden Signals（《站点可靠性工程》监控章节）