《使用 Kubernetes 实现云原生 DevOps（第二版）》

第 15 章 可观测性和监测 可观察性和监测

本作品已使用人工智能进行翻译。欢迎您提供反馈和意见：[e-mail]

在船上，没有什么是完全正确的。

威廉-兰格维什，《亡命海

在本章中，我们将探讨云本地应用程序的可观察性和监控问题。什么是可观察性？它与监控有什么关系？如何在 Kubernetes 中进行监控、日志记录、度量和跟踪？

什么是可观察性？

可观察性（Observability）对你来说可能不是一个熟悉的术语，但它作为一种表达传统监控之外的更大世界的方式，正变得越来越流行。在了解可观察性如何扩展监控之前，让我们先来解决监控问题。

什么是监控？

您的网站正在运行吗？去看看，我们等着。了解所有应用程序和服务是否正常运行的最基本方法就是亲自查看。但是，当我们在 DevOps 环境中谈论监控时，我们主要指的是自动监控。

自动监控是以某种程序化的方式检查网站或服务的可用性或行为，通常是定期进行，如果出现问题，通常会自动向人工工程师发出警报。但问题的定义是什么？

封闭式监控

以静态网站为例。如果网站根本无法运行，它就不会有任何反应，或者你会在浏览器中看到一条错误信息。因此，对该网站最简单的监控检查就是获取主页并检查 HTTP 状态代码（200 表示请求成功）。您可以使用命令行 HTTP 客户端（如httpie 或curl ）来执行此操作。如果客户端的退出状态为非零，则表示获取网站时出现了问题。

但假设网络服务器配置出了问题，虽然服务器正常工作并以 HTTP200 OK 状态响应，但实际提供的却是空白页面（或某种默认或欢迎页面，也可能是错误的网站）。我们简单的监控检查不会发现任何问题，因为 HTTP 请求成功了；但是，网站并没有按照用户的预期运行。

更复杂的监控检查可能会在页面上查找一些你知道应该存在的特定文本，如组织名称。这样就能发现网络服务器配置错误但仍在运行的问题。

超越静态页面

可以想象，更复杂的网站可能需要更复杂的监控。例如，如果网站有用户登录功能，监控检查还可以尝试使用已知的测试用户账户登录，如果登录失败则发出警报。或者，如果网站有搜索功能，检查可能会在文本字段中填入一些搜索文本，模拟点击搜索按钮，并验证结果是否包含一些预期的文本。

对于简单的网站，回答 "是否正常运行？"这样的问题就足够了。而对于云本地应用程序（往往是更复杂的分布式系统）来说，这个问题可能会变成多个问题：

• 我的应用程序在世界各地都可以使用吗？还是只能在某些地区使用？

• 对大多数用户而言，加载需要多长时间？

• 下载速度慢的用户怎么办？

• 我网站的所有功能是否都能正常运行？

• 某些功能是否运行缓慢或根本无法运行，有多少用户受到影响？

• 如果应用程序依赖于第三方服务，那么当外部服务出现故障或不可用时，应用程序会发生什么情况？

• 云提供商发生故障时会怎样？

我们开始发现，在监控云本地分布式系统的世界里，清楚的事情并不多。

闭箱监测的局限性

然而，无论这些检查多么复杂，它们都属于同一类监控：封闭式监控。闭箱检查，顾名思义，只观察系统的外部行为，而不试图观察系统内部的情况。

直到几年前，由 Nagios、Icinga、Zabbix、Sensu 和 Check_MK 等流行工具执行的封闭式监控仍是最先进的技术。可以肯定的是，对系统进行任何形式的自动监控都比没有监控要好得多。但封闭式检查也有一些局限性：

• 它们只能检测到可预测的故障（例如，网站没有响应）。

• 它们只检查系统中暴露于外部的部分的行为。