本文翻译自上述Oreilly出版的电子书《Distributed systems Observability》(By Cindy Sridharan)第二章。
任何关于可观测性的讨论都离不开与监控的对比。可观测性既不能替代监控，也不意味着监控不再必要——二者是互补关系。如图2-1所示，监控与可观测性的目标截然不同。
可观测性是监控的超集。它不仅提供系统健康状况的高层概览，还能深入揭示系统潜在的故障模式。此外，可观测系统会提供丰富的内部运作上下文，从而帮助发现更深层次的系统性问题。
而监控最擅长的则是报告系统整体健康状况并触发告警。
基于监控数据的告警
告警本质上是以故障和人为核心的。过去，针对以下特征的系统故障症状进行"监控"和告警是合理的：
- 具有可预测性
- 会严重影响用户
- 需要人工尽快干预修复
随着系统日益分布式化，先进工具和平台的出现抽象掉了许多传统人工故障监控所发现的问题。Kubernetes等平台开箱即用的健康检查、负载均衡和故障服务自动剔除功能，使运维人员无需再为此类故障接收告警。
黑盒与白盒监控
传统上，大多数告警源自黑盒监控。黑盒监控指从外部观察系统（例如Nagios式检查）。这类监控能有效识别问题症状（如"错误率上升"或"DNS解析失败"），但无法追踪分布式系统中导致症状的跨组件诱因。
白盒监控则指从系统内部报告数据的技术。对于组织内部系统而言，源自黑盒监控的告警正逐渐被淘汰，因为系统内部报告的数据能产生比外部探测更有价值、更具操作性的告警。不过黑盒监控仍有用武之地，特别是当基础设施（甚至全部）外包给第三方软件时，外部监控成为唯一选择。
但这里存在悖论：虽然基础设施管理日益自动化，但理解应用生命周期却变得更困难。现代故障模式往往具有以下特征：
- 可容忍（通过最终一致性、多级缓存等机制放宽一致性保证）
- 可缓解（通过背压、重试、超时、熔断、限流等优雅降级机制）
- 可主动触发（如负载激增时通过主动降级避免服务完全崩溃）
基于宽松保证构建的系统在设计上就注定不会始终保持100%健康状态。试图预测所有可能导致功能降级的情况并触发人工告警变得不再必要。现代系统设计中，只有极小部分的故障领域属于需要紧急人工干预的硬性故障。这引出了核心问题：告警的定位何在？
告警最佳实践
告警仍应聚焦硬性故障和人工干预。即便告警范围缩小，利用监控数据进行告警的目标始终未变。
监控数据应持续提供分布式系统的鸟瞰图，记录并展示所有组件（负载均衡器、缓存、队列、数据库和无状态服务）随时间变化的高层指标。告警附带的监控数据应支持快速钻取系统组件单元，作为故障响应时诊断影响范围和粗略性质的第一入口。
此外，故障发生时，监控数据须立即呈现故障影响范围及修复措施效果。
最后，为确保值班体验人性化且可持续，所有告警（及其衍生监控信号）必须具可操作性。
选择哪些监控指标进行告警
优秀的监控指标包括USE指标和RED指标。《站点可靠性工程》一书中，Rob Ewaschuk提出四大黄金信号（延迟、错误、流量、饱和度）作为告警监控的最小可行集。
USE方法由Brendan Gregg提出，要求测量系统资源的利用率（如可用内存）、饱和度（如CPU运行队列长度）和错误率（如设备错误）。
RED方法由Tom Wilkie提出，主张监控请求速率、错误率和请求持续时间（通常以直方图表示），这对请求驱动的应用层指标监控至关重要。
调试“不可监控”的故障
理解持续处于弹性与熵增状态的分布式系统病理，关键在于基于证据而非假设进行调试。系统的可观测程度直接决定其可调试性。
调试通常是迭代过程，包含以下步骤：
- 从高层级指标入手
- 通过系统各部分的细粒度上下文观察进行深入探查
- 做出正确推断
- 验证理论合理性
证据无法凭空产生，也不能从聚合数据、平均值、百分位数或历史模式中推断。当系统以无法预监控的方式故障时，不可观测的系统可能根本无法调试。
可观测性不是万能药
Brian Kernighan在1979年《Unix入门》中写道：
“最有效的调试工具仍是缜密的思考，辅以精心布置的打印语句。”
调试单机单进程时，GDB等工具能帮助观察给定输入下的应用状态。而对于分布式系统，在缺乏分布式调试器的情况下，必须依赖系统各组件的可观测数据才能有效调试。
必须强调：可观测性不能取代深入思考。虽然可观测数据能指引答案，但决定暴露哪些信息、如何分析现有证据（观测结果）以推断生产环境系统异常的原因，仍需要开发者具备扎实的系统知识、领域理解和敏锐直觉。
更重要的是，亟需更高级的抽象（如优秀的可视化工具）来整合海量异构数据源。
结论
可观测性≠监控，也不仅是运维关注点。下一章我们将探讨如何在系统设计、编码和测试阶段构建可观测性。