监控系统是否启动并运行并不等同于理解其行为原因，而混淆这两件事是工程团队在扩展分布式架构时所犯的最昂贵的错误。绿色仪表板并不意味着用户拥有良好的体验。它仅意味着服务响应 ping。这两种说法之间的距离正是最难发现的错误、无声降级以及需要数小时才能诊断的事件的地方。
监控与可观察性的区别
监控从预先已知的问题开始：服务器是否响应？队列是否越来越长？错误率是否超过阈值？您定义指标、配置警报并等待某些内容超过阈值。当系统简单且故障模式可预测时，它效果很好。
可观察性不同。该术语借用自控制理论，描述了从系统输出推断系统内部状态的能力。实际上，这意味着能够回答您在构建系统时不知道会问的问题。为什么这个特定用户得到 503 而其他用户却没有？为什么仅圣保罗的客户结账延迟就增加了 40%？为什么该服务在周二下午 2 点之后消耗的 CPU 量是原来的两倍？
这些问题没有预先配置的警报。他们需要丰富的、相关的数据和足够的背景来指导真正的调查。
为什么仅靠日志不能解决问题
多年来，“如何在生产中调试”的标准答案是“添加更多日志”。日志很有用——记录离散事件、捕获错误消息、允许审计。但在分布式架构中，它们由于结构原因而变得不够。
经过十个服务的请求会在十个不同的位置生成日志。如果没有在整个链中正确传播的相关标识符，就不可能重建请求所采用的路径。即使使用相关 ID，您也需要将分散的文本片段组合在一起，并尝试手动拼凑出连贯的叙述。活动事件所花费的时间是用户在没有服务的情况下花费的时间。
指标解决了部分问题——它们显示总体趋势并启用快速警报——但它们在设计上就失去了背景。您知道平均延迟增加了，但您不知道哪个具体操作、哪个[数据库0、哪个外部调用负责。
痕迹弥补了这一差距。跟踪从头到尾跟踪请求，遍历每个服务、每个银行呼叫、每个外部集成，记录每个步骤的持续时间和属性。有了跟踪，以前需要在日志文件中进行数小时 grep 的调查现在只需几分钟即可对每个跨度所花费的时间进行可视化分析。
OpenTelemetry 来解决的问题
在 OpenTelemetry 出现之前，为[可观测性 1] 检测系统意味着选择一个供应商——Datadog、New Relic、Jaeger、Zipkin——并实现每个供应商的专有 SDK。更换供应商意味着重写整个代码库的工具。同时使用多个工具意味着维护多个具有不同语义和重复开销的 SDK。
[OpenTelemetry2 是一个 CNCF 研究生项目，由 Google、Microsoft、Splunk 和数十个其他组织贡献，以两种方式结束了该模型。首先，它为三大支柱（指标、日志和跟踪）定义了统一的规范，并且它们之间具有一致的语义。其次，它在几乎所有相关语言的 SDK 中实现了此规范，并为最常见的框架提供了自我检测。
实际结果是，检测只在代码中存在一次，并且数据目标在收集器中配置。您可以在开发期间将跟踪发送到 Jaeger，在生产中发送到 Tempo，并并行测试 Honeycomb，所有这些都无需触及任何应用程序代码。供应商锁定不再作为技术限制而存在。
如何在不停止团队的情况下实施
采用 OpenTelemetry 时的常见陷阱是尝试同时检测所有内容。智能路径是增量的，从最具诊断价值的点开始。
第一步是安装 SDK 并为服务使用的 HTTP 框架启用自检测。在Node.js、Go、Python和Java中，这会自动覆盖入站调用、出站调用和数据库连接，而无需对业务代码进行任何修改。在不到一个小时的工作时间内，您将获得具有有用上下文的痕迹。
第二步是将 OpenTelemetry Collector 配置为应用程序和可观测性后端之间的中介。收集器接收数据，可以对其进行转换、过滤并将其发送到多个目的地。这将应用程序与有关数据存储位置的任何决策分离。
大多数团队低估的第三步是定义属性策略。当您寻找特定模式时，没有上下文属性（用户 ID、租户 ID、部署版本、区域）的跟踪很难过滤。标准化每个服务必须传播的属性是一项架构决策，而不是实现决策。
生产中的调试过程有哪些变化
随着真正的可观察性的实施，事件调查的动态发生了具体的变化。该团队不是通过咨询基础设施仪表板并尝试将 CPU 警报与延迟峰值关联起来来启动事件，而是从受影响的用户体验开始。
报告问题的用户的跟踪准确显示了延迟集中的位置、哪个服务返回了错误、哪个银行查询花费的时间是正常时间的三倍。该假设源于数据，而不是源于对可能发生变化的假设。
这缩短了“出了问题”和“这是根本原因和负责的代码行”之间的距离。具有成熟可观察性的团队会根据证据进行事后分析，而不是根据碎片日志进行粗略重建。
这种变化不仅仅是技术上的。在开发期间（而不仅仅是在事件期间）良好地制定仪表规范并积极使用跟踪的团队会积累对系统的理解，这是任何架构文档都无法替代的。如果认真对待，可观察性就会成为一种持续学习软件在现实世界中行为方式的工具。
另请阅读
- [分布式系统中的可观察性：日志、指标和跟踪3
- [OpenTelemetry 的可观察性：指标、日志和分布式跟踪4
- [Workers：调试、日志和 Workers Tail — 无需日志服务器即可在边缘进行观察5
- [应用程序的无服务器：日常生活中的架构6
- [生产中的 Cloudflare Workers：hello world 之后发生了什么变化7
- [人工智能在医疗诊断中的应用：医疗保健系统的实践发生了哪些变化8