仪表板是绿色的，但顾客却抱怨结账系统坏了。如果您处于这个位置，您已经了解监控与可观察性之间的区别。你的监控只检查了你想检查的内容，而这次失败是新的。

本指南在没有营销语言的情况下解释了这两种想法，并跟踪一个虚构事件从警报到根本原因。日志、痕迹和数字是为了说明该过程而发明的。您还应该知道，供应商和从业者以不同的方式划定这条线，有些人认为这在一定程度上是营销上的区别。我们专注于实践部分。

简短的回答

监控是一项活动。您可以提前决定要监视的内容，例如 CPU、错误率或磁盘空间，并设置触发警报的阈值。它回答：“我担心的事情发生了吗？”

可观察性 是系统的一个属性。该术语来自控制理论，它描述了从外部输出推断系统内部状态的能力。在实践中，它回答：“正在发生什么以及为什么发生，包括我从未预料到的问题？”

想想一辆车。仪表盘上的警示灯正在监控。它们涵盖了一系列已知问题。机械师的完整诊断端口可以让人们提出有关发动机任何部分的新问题，更接近于可观察性。

监控与可观察性并存

这不是两者之间的选择。您仍然需要警报来告诉您何时查看。

为什么仅仅监控还不够

对于一台服务器上的一个应用程序，可能出现问题的列表相当短，因此您可以全部查看。现代系统可能拥有数十个服务、队列和第三方 API，以及来来去去的容器。失败会变成无人预料到的组合：一个地区、一种客户类型、特定的应用程序版本和单一的缓慢依赖项。

你不能为一个你没有想到的问题提前写一个仪表板。您需要数据以便您事后询问。

日志、指标和跟踪

这三种类型的遥测通常被称为可观测性的支柱。每个人都回答不同的问题：

指标

http_requests_total{service="checkout", status="500"} 1832
http_request_duration_seconds{service="checkout", quantile="0.95"} 2.4

指标的存储成本低且查询速度快，这使得它们非常适合仪表板和警报。在许多度量系统中要警惕高基数标签，例如用户 ID，因为它们会急剧增加成本。

痕迹

跟踪跟踪跨服务的一个请求。每个步骤都是一个 span，具有开始时间和持续时间：

POST /checkout                      2410 ms
├─ auth-service: verify token         18 ms
├─ cart-service: load cart            42 ms
├─ pricing-service: calculate       2290 ms   <-- slow
│  └─ SELECT coupons ...            2265 ms
└─ payment-service: not reached

跟踪使缓慢的步骤变得明显，这在来自不同服务的单独日志中很难看到。

日志

日志提供某一时刻所发生事件的详细信息。我们稍后会研究如何使它们变得有用。

事件演练

以下是一个虚构的例子，这些部分是如何组合在一起的。

监控处理了第 1 步。之后的一切都是可观察性的。请注意每个问题是如何从前一个答案中得出的。没有人可以提前为“今天活动的移动应用优惠券查询”构建仪表板。对于修复本身，我们的 SQL 查询优化指南 展示了如何阅读此类计划。

更好的日志

纯文本日志是为人眼而制作的，很难查询。 结构化日志使用机器可以过滤的字段：

# Hard to search
ERROR Payment failed for user 42 after 3 tries

# Easy to search
{"level":"error","event":"payment_failed","user_id":"42",
 "attempts":3,"provider":"acme","trace_id":"a1b2c3","duration_ms":2410}

使用第二种形式，您可以立即询问“过去一小时内每个提供商有多少次失败？” trace_id 字段特别有价值，因为它将日志行链接到整个请求，跨越它所涉及的每个服务。

切勿记录密码、令牌或卡号，并妥善保管个人数据。正如我们的指南所解释的，JWT 可以被从日志中读取它们的任何人重复使用。

黄金信号

不确定要监控什么？ Google 的《站点可靠性工程》一书为面向用户的系统提出了四个信号：

使用百分位数表示延迟，因为平均值隐藏了缓慢的请求，如我们在负载测试与压力测试中所示。

提醒人们信任

如果警报一直发出，人们就会停止阅读它们。好的人遵循一些规则：

• 针对用户感受到的症状发出警报。“结帐错误超过 2%”胜过“CPU 为 85%”。不伤害任何人的高 CPU 不应该唤醒任何人。
• 使每个警报都可操作。如果没有人需要执行任何操作，请将其设为仪表板项目或将其删除。
• 运行手册链接。 告诉响应者在哪里查看以及尝试什么。
• 定期查看它们。删除或修复上个月被忽略的所有警报。

服务水平目标

SLO 将“网站应该快速且可靠”转变为可衡量的目标，例如“99.9% 的结帐请求在 30 天内成功”。这允许大约 0.1% 的失败，称为错误预算。如果你还有足够的，你可以更快地发货，如果快用完了，你可以优先考虑可靠性。这是解决交付速度和稳定性之间争论的有用方法。

OpenTelemetry 和工具

OpenTelemetry 是一种开源、供应商中立的标准，用于生成和导出遥测数据。它是云原生计算基金会的一个项目。使用它意味着您可以稍后更改后端而无需重写代码。它本身不是存储或仪表板产品，因此您可以将其与以下产品配对：

请自行检查当前功能和定价，因为这些产品经常变化。成本会随着数据量的增加而快速增长，因此请使用采样并设置保留限制。

如何开始

1. 从黄金信号开始为您提供最重要的服务。
2. 针对用户注意到的症状添加一两个警报。
3. 切换到结构化日志， 每行都有一个请求 ID。
4. 添加追踪到您使用 OpenTelemetry 的主要用户旅程，因为自动检测可以涵盖许多常见框架。
5. 将部署链接到您的图表，以便您可以查看 CI/CD 管道中的发布是否导致了更改。
6. 从每个事件中学习。 在每个事件之后，询问哪些数据可以让问题更快地得到解决，然后添加该数据。

只提供一项服务的小团队不需要庞大的平台。基本指标、良好的日志和一些警报可能就足够了。随着服务数量的增加，追踪也能获得收入。

常见错误

• 购买一个工具并将其称为可观察性。价值来自良好的仪器以及如何使用数据。
• 将三个支柱视为清单。 单独的数据无法链接，这会让您在选项卡中寻找。共享 ID 很重要。
• 收集所有内容。未经过滤的遥测数据成本高昂，而且会增加噪音。
• 仪表板太多。 一些受信任的视图胜过了一百个没有人打开的视图。
• 认为它取代了测试。 在发布之前你仍然需要测试。不过，金丝雀发布与这些信号很好地搭配。

最后的话

监控会告诉您出现了问题，而可观察性则为您提供了找出原因的方法。实际测试很简单：当出现不熟悉的问题时，你能在不发布新代码的情况下找到原因吗？下次遇到事故时，写下您无法回答的每个问题。该列表就是您的路线图。

常见问题

继续学习