可观测性是什么？

客座文章最初由Elastisys高级云架构师Cristian Klein在Elastisys博客[1]上发表

想象一下，在没有财务预测的情况下经营一家企业，甚至不知道银行里还剩下多少钱。你如何知道你是在一个巨大的现金缓冲中游泳，或者如果你需要跳过客户的午餐由于资金不足？不注意财务状况，就不可能经营健康的企业。类似地，如果不观察计算基础设施，就不可能保持应用程序健康运行。

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

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

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

可观测性是什么？

可观测性有许多名称，如监测、审计、遥测、测仪。忽略这些细微差别，所有这些词本质上的意思都是一样的：度量你的基础设施、平台和应用程序，以了解它是如何运行的。正如Peter Drucker曾经说过的：“如果你不能测量它，你就无法管理它。”

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

但是可观测性究竟是什么呢？

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

1. 我的用户满意吗？
2. 我的应用令人满意？
3. 我的服务器良好吗？

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

让我们来看看日志记录和指标，这两个你绝对应该拥有的。

日志记录

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

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

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

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

长期日志可以以最便宜的形式存储，通常是对象存储。它们不能立即“谷歌化”，因此，需要通过它们进行搜索的可能性也很小。

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

指标

Grafana的截图，一个用于可视化指标的领先项目。

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

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

像Prometheus[5]这样的项目可以帮助你从应用程序中收集所需的指标，而Grafana可以帮助你可视化它们。事实上，我认为满是Grafana仪表板的屏幕是办公室墙壁的一个很好的装饰。你知道，当我们能去办公室工作的时候。

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

警报

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

警报是棘手的。警报太多，系统就会“呼狼来了”。你的团队将以“警惕疲劳”结束，并开始忽视甚至是重要的问题。提醒太少，你的客户就会为你“做提醒”……

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

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

总结

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

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

要寻找通过CNCF认证的开源Kubernetes发行版，该发行版带有用于日志、指标和警报的预先配置工具吗？查看Compliant Kubernetes文档[6]，请考虑使用它！我们欢迎贡献。

参考资料

[1]

Elastisys博客: https://elastisys.com/what-was-observability-again/

[2]

102个可观察性项目: https://landscape.cncf.io/card-mode?category=observability-and-analysis&grouping=category

[3]

Elasticsearch/Kibana: https://opendistro.github.io/for-elasticsearch/

[4]

Loki: https://grafana.com/oss/loki/

[5]

Prometheus: https://prometheus.io/

[6]

Compliant Kubernetes文档: https://compliantkubernetes.io/