什么是可观测性

想象一下，在没有财务预测的情况下经营企业，甚至不知道银行剩下多少钱。您怎么知道您是在巨大的现金缓冲中游泳还是由于资金不足而需要跳过客户午餐？如果不注意自己的财务状况，根本就不可能开展健康的业务。同样，如果不观察您的计算基础架构，就不可能保持应用程序运行正常。

事实上，可观测性非常重要，到2021年2月，云原生计算基金会(CNCF)列出了102个可观察性项目。可观测性不仅重要，而且昂贵。Netflix被戏称为一个产生大量日志的平台，同时也是一个流视频平台。可观测性之所以昂贵，有两个原因:

• 可观测性比被观测系统至少可靠一个数量级。否则，你将继续调试你的可观察性堆栈，而不是使用它来保持你的应用程序运行。
• 因为你永远不知道要观察什么，直到事件发生后，观察多于需要的东西是很常见的。一个好的汽车司机不仅要向前看，而且还要不断扫视周围以避免事故。

在这篇文章中，让我们深入探讨一下可观测性:它是什么，不同类型的可观测性，以及实现可观测性在技术上意味着什么。在这篇文章的最后，你会明白为什么你应该抵制住诱惑，然后在可观测性上节省资金。

什么是可观测性

可观测性有许多名称，如监测、审计、遥测、仪器。忽略这些细微差别，所有这些词本质上的意思都是一样的:度量您的基础设施、平台和应用程序，以了解它是如何运行的。正如彼得·德鲁克(Peter Drucker)曾经说过的:

如果你无法量化它，你就无法管理它。

如果你熟悉精益思维——即构建-度量-学习——那么可观察性就会自然而然地出现在你身上。可观测性通过测量阶段闭合反馈回路。它允许您的团队对应用程序进行快速更改，快速适应其用户基础和环境，而不会产生不必要的意外。良好的可观测性可以将凌晨2点被唤醒转换为日常检查。

真正的可观测性是什么

当谈到可观测性时，我们通常尝试回答三个问题:

• 我的用户满意吗?
• 我的应用是否令人满意?
• 我的服务令人高兴吗?

我们通过三种方式做到这一点:跟踪、日志和指标。前者产生更多的数据，但不一定更多的洞察力。如今，这些技术都有望接近实时。(你愿意要一个告诉你昨天的心率的心率监测器吗?)

让我们来看看日志记录和度量标准，这两个您绝对应该拥有的。

Kibana的截图，它和Elasticsearch一起，是优秀日志解决方案。

在编写应用程序时，您的团队通常会添加日志代码。当代码执行经过一个主要事件时，这些显式的指令将产生一个日志行，即一堆有意义的文本。例如，用户X已登录或用户Y身份验证失败，等等。这几行是问你的客户他们是否尝试清理浏览器缓存并重新加载或实际监控他们之间的区别。

日志记录是非常明确的:您的团队需要添加日志记录代码，并且需要预见要记录什么。经验法则是，所有主要的边界事件都需要被记录。有些应用程序错误只在生产环境中出现，所以您应该选择日志过多而不是日志不足。否则，大量时间就会浪费在寻找所谓的海森堡bug(heisenbug)上:这种bug很难复现，但却会引起用户的不满。

日志记录会产生大量的数据。为了节省成本，最好考虑短期和长期日志。短期日志-例如，最近7天-应该是可搜索的，也就是说，你应该能够在几秒钟内执行全文搜索。像Elasticsearch/Kibana和Loki这样的项目最适合这个目的。

长期日志可以以最便宜的形式存储，通常是对象存储。它们不能立即搜索，因此，需要通过它们进行搜索的可能性也很小。事实上，如果您希望在隐私方面犯错，最好避免长期日志。

有时，您并不关心确切的日志行，而是关心特定事件发生的次数。这些信息可以从日志中提取，但是有一种更有效的方法:指标。

指标

Grafana的截图，一个用于可视化指标的优秀项目

指标——也称为服务水平指标(SLI)或关键性能指标(KPI)——是数字值的时间序列。可以把它想象成每小时记录所有大城市的室外温度。指标使用最少的空间，提供最多的洞察力(为它们使用的空间)。它们可以记录每小时活动用户的数量、应用程序收到的请求的数量、可用磁盘空间的数量等。关注指标可以确保您的用户在使用应用程序时获得良好的体验，同时还可以降低基础设施的成本。

度量标准是相当明确的。您的团队需要添加用于收集和公开给定度量的代码。然而，市面上最常用的工具，如Nginx、Kubernetes或MySQL，已经输出了大量的指标，这些指标应该可以为您提供良好的态势感知。

像Prometheus这样的项目可以帮助您以应用程序所需的最少支持来收集度量，而Grafana可以帮助可视化度量。事实上，我认为布满Grafana仪表盘的屏幕可以很好地装饰办公室的墙壁。这样你很清楚，上班的时候有什么事情可以处理。

到目前为止，我们讨论了可视化，也就是一种更有意为之的可观测性。但是，如果这个系统现在需要关注呢?

告警

警报就像系统呼救，请求人类的注意。通常，如果给定的指标超过了阈值，随叫随到的人员就会收到Slack或微软团队中的电子邮件、短信或消息。可以实现自动升级，例如，如果第一个随叫人在30分钟内没有响应警报，第二个随叫人就会得到警报。

警报是棘手的。警报太多，系统就会变成狼来了，你的团队将以警惕疲劳结束，并开始忽视甚至是重要的问题。提醒太少，你的客户就会为你做提醒……这通常不是首选的提醒渠道，至少你的会计会抱怨必须兑现太多的发票。

因此，何时发出警报的门槛应该很高。这是凌晨2点或求救事件吗?也就是说，如果发生这种情况，应该叫醒某人吗?或者这是一个泛泛的事件，可以在白天处理?

幸运的是，像Prometheus这样的项目不仅能发出警报，还能进行预测。知道磁盘将在72小时内被填满，可以防止客户因停机而失望，也可以防止破坏团队成员的良好睡眠。

总结

缺乏可观测性就像闭着眼睛开车:你不知道离灾难有多近。你开得越快，路越忙，你就越要小心。

可观测性也是一样:你越想让你的团队越快地添加功能，你就越应该在可观测性上投资。而且，虽然在可观测性上节省一些钱可能很诱人，但这些节省将在下一次缓慢修复事件中迅速消失。