《构建微服务》，第二版

第 10 章 从监测到可观测

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

正如我迄今为止所展示的那样，我希望将我们的系统拆分成更小、更细粒度的微服务能带来多种好处。同时，正如我们深入探讨过的那样，它也增加了大量新的复杂性。在任何情况下，复杂性的增加都不会比了解生产环境中系统的行为更明显。从一开始，你就会发现，那些在相对简单的单进程单体应用程序中行之有效的工具和技术，在微服务架构中却不那么适用。

在本章中，我们将探讨与监控微服务架构相关的挑战，我会告诉大家，虽然新工具可以提供帮助，但从根本上说，你可能需要转变整个思维方式，才能弄清生产中到底发生了什么。我们还将讨论对可观察性概念的更多关注--了解如何才能对系统提出问题，从而找出问题所在。

生产之痛

只有在生产中运行微服务架构并为实际流量提供服务时，你才能真正体会到微服务架构可能带来的痛苦、折磨和烦恼。

干扰、恐慌和混乱

图片 场景：这是一个宁静的周五下午，团队正期待着早点溜出去去酒吧，开始一个远离工作的周末。突然，电子邮件来了。网站出现问题！推特（Twitter）上充斥着公司的种种纰漏，你的老板在唠叨你的耳朵，一个安静周末的前景荡然无存。

很少有事情能像下面这条推文一样，把问题总结得如此透彻：

我们用微型服务取代了单体服务，因此每次故障都更像是一场谋杀之谜。¹

我们首先要做的就是追查出了什么问题，以及问题的起因。但是，如果我们有一长串嫌疑人，这就变得很困难。

在单进程单体应用程序的世界里，我们至少可以从一个非常明显的地方开始调查。网站运行缓慢？是单体。网站出现奇怪的错误？是单体。CPU 占用 100%？是巨石。烧焦味？嗯，你懂的。²有了单点故障，故障调查就简单多了！

现在，让我们想想我们自己基于微服务的系统。我们为用户提供的功能由多个微服务提供，其中一些微服务与更多的微服务通信以完成任务。这种方法有很多优点（这是好事，否则这本书就白写了），但在监控领域，我们面临着一个更复杂的问题。

我们现在有多个服务器需要监控，多个日志文件需要筛选，还有多个网络延迟可能导致问题的地方。我们的故障表面积增加了，需要调查的事情也增加了。那么，我们该如何处理呢？我们需要理清本来可能是一团混乱、纠缠不清的东西--这是我们每个人在周五下午（或者说在任何时候！）最不想处理的事情。

首先，我们需要对细小的事情进行监控，并提供汇总，让我们能够看到更大的画面。然后，我们需要确保我们有可用的工具来切分这些数据，作为我们调查的一部分。最后，我们需要更聪明地思考系统健康问题，接受生产测试等概念。我们将在本章中逐一讨论这些必要条件。让我们开始吧。

单一微服务，单一服务器

图 10-1展示了 一个非常简单的设置：一台主机运行一个微服务实例。现在我们需要对其进行监控，以便在出错时知道情况，从而进行修复。那么，我们应该注意什么呢？

图 10-1. 单台主机上的单个微服务实例

首先，我们要从主机本身获取信息。CPU、内存--所有这些都很有用。其次，我们需要访问微服务实例本身的日志。如果用户报告了一个错误，我们应该能在这些日志中看到错误，希望这能让我们找到出错的原因。此时，由于只有一台主机，我们只需在主机上记录本地日志，然后使用命令行工具查看日志即可。

最后，我们可能需要监控应用程序本身--从外部观察它。至少，监控微服务的响应时间是个好主意。如果你的微服务实例前面有一个网络服务器，你也许可以只查看网络服务器的日志。或者，你也可以更高级一些，使用健康检查端点之类的东西来查看微服务是否正常运行（我们稍后会探讨这意味着什么）。 ...