Observability

概述

参考：
CNCF 博客，What was observability again?
中文翻译：公众号，云原生技术爱好者社区-什么是可观测性
CNCF 可观测性白皮书(中文)
CNCF 全景图
Wiki, Observability
宋净超-云原生资料库-OpenTelemetry 可观测性的未来
公众号，云原生社区-构建适合组织的云原生可观测性能力
Goole 文章

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

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

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

什么是可观测性

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

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

可观测性的三大支柱

具有可观测的系统通常具有三个部分

Metrics(指标) 监控 # 随着时间推移产生的一些与监控相关的可聚合数据点
Logging(日志) 监控 # 离散式的日志或事件
Tracing(链路追踪) 监控 # 追踪程序的函数

CNCF 将可观测性和数据分析归类为一个单独的类别，且划分成 4 个子类

监控系统 # 以 Prometheus 等为代表
日志系统 # 以 Elastic Stack 和 PLG Stack 等为代表
追踪系统 # 以 Jaeger、Zipkiin、SkyWalking、Pinpoint 等为代表
- 可以监控两个程序之间调用时，程序内部都调用了哪些函数。类似 Linux 的 Strace 命令，只不过这些监控是实时的。
混沌工程系统 # 以 ChaosMonkey 和 ChaosBlade 等为代表

Metrics(指标)

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

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

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

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

Logging(日志)

在编写应用程序时，您的团队通常会添加日志代码。当代码执行经过一个主要事件时，这些显式的指令将产生一个日志行，即一堆有意义的文本。例如，用户X已登录或用户Y身份验证失败，等等。这几行是问你的客户他们是否尝试清理浏览器缓存并重新加载或实际监控他们之间的区别。日志记录是非常明确的:您的团队需要添加日志记录代码，并且需要预见要记录什么。经验法则是，所有主要的边界事件都需要被记录。有些应用程序错误只在生产环境中出现，所以您应该选择 日志过多 而不是 日志不足。否则，大量时间就会浪费在寻找所谓的 海森堡bug(heisenbug) 上: 这种 bug 很难复现，但却会引起用户的不满。日志记录会产生大量的数据。为了节省成本，最好考虑短期和长期日志。短期日志-例如，最近 7 天-应该是 可搜索的，也就是说，你应该能够在几秒钟内执行全文搜索。像 Elasticsearch/Kibana 和 Loki 这样的项目最适合这个目的。长期日志可以以最便宜的形式存储，通常是对象存储。它们不能立即搜索，因此，需要通过它们进行搜索的可能性也很小。事实上，如果您希望在隐私方面犯错，最好避免长期日志。

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

Tracing(追踪)

最后

告警

警报就像系统 呼救，请求人类的注意。通常，如果给定的指标超过了阈值，随叫随到的人员就会收到 Slack 或微软团队中的电子邮件、短信或消息。可以实现自动升级，例如，如果第一个随叫人在 30 分钟内没有响应警报，第二个随叫人就会得到警报。警报是棘手的。警报太多，系统就会变成狼来了，你的团队将以警惕疲劳结束，并开始忽视甚至是重要的问题。提醒太少，你的客户就会为你做提醒……这通常不是首选的提醒渠道，至少你的会计会抱怨必须兑现太多的发票。因此，何时发出警报的门槛应该很高。这是凌晨2点或求救事件吗?也就是说，如果发生这种情况，应该叫醒某人吗?或者这是一个泛泛的事件，可以在白天处理?

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