可观测性服务于未知问题

可观测性关心能否根据系统产生的外部证据，推断内部正在发生什么。它不只是多收集日志，也不等同于已有监控面板。监控擅长回答预先定义的问题，可观测性还要支持事故发生后提出的新问题，并把证据关联到具体请求、版本和依赖。

指标、日志和追踪承担不同职责

指标把一段时间内的行为聚合为数值，适合观察请求率、错误率、延迟和资源饱和。日志记录离散事件及上下文，适合还原状态变化和失败原因。分布式追踪沿一次请求经过多个服务的路径记录跨度，帮助定位等待发生在哪里。

三类信号并非必须彼此替代。指标发现异常后，可以借助追踪缩小依赖范围，再通过结构化日志查看具体条件。若它们使用不同时间、服务名或请求标识，数据再多也难以形成完整证据链。

上下文决定一条信号是否有用

一条“请求失败”日志若没有接口、错误类别、版本和关联标识，很难用于诊断。反过来，把完整正文、令牌和个人信息全部写入日志会制造安全与成本风险。应选择能够解释行为且符合数据保护要求的字段。

高基数字段不适合直接成为所有指标标签，否则时序数量会快速增长。它们可以保留在日志或追踪中，通过样本与关联查询使用。信号设计需要同时考虑诊断价值、存储成本和访问权限。

监控从已知风险建立告警

服务水平指标和目标把用户可感知行为转成可测量信号，例如成功率和延迟分位数。告警应对应需要采取行动的状态，而不是每个瞬时波动。只监控 CPU 使用率可能漏掉依赖故障，只监控业务错误也可能来不及解释容量耗尽。

预设告警覆盖的是已知故障模式。新的代码路径、数据组合或依赖交互仍可能产生未见问题，这时需要从请求、变更和依赖维度自由切分证据。可观测性为这种探索提供基础。

关联和时间使因果调查成为可能

请求标识、内容 ID、租户、部署版本和任务编号能连接多个事件。所有组件还需要一致且可信的时间基准，否则跨服务顺序难以判断。异步消息应传递关联信息，同时区分原始业务动作和后续重试。

相关性不自动证明因果。部署后错误上升可能由流量结构、下游故障或数据变化引起。诊断应结合变更记录、对照实例和依赖状态，避免仅凭时间接近就确定原因。

可观测能力需要被验证

系统上线前可以演练超时、数据库连接耗尽、队列积压和部分请求失败，检查能否从信号发现并定位。若值班人员只能看到“服务异常”而不能判断受影响范围和下一步，说明信息设计仍不充分。

可靠的可观测性包括采集失败本身的监控、保留期限、查询权限和成本预算。它的目标不是保存所有细节，而是在正常运行和意外故障中，以可接受成本获得足够证据支持判断。

资料依据

• Google：Site Reliability Engineering Books，https://sre.google/books/
• Carnegie Mellon University Software Engineering Institute：Reasoning About Software Quality Attributes，https://www.sei.cmu.edu/library/reasoning-about-software-quality-attributes/