《Kubernetes 最佳实践》第二版

第 3 章 Kubernetes 中的监控和日志记录 Kubernetes 中的监控和日志记录

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

在本章中，我们将讨论 Kubernetes 监控和日志记录的最佳实践。我们将深入探讨不同监控模式的细节、收集的重要指标以及根据这些原始指标构建仪表盘。最后，我们将举例说明如何为 Kubernetes 集群实施监控。

指标与日志

首先，您需要了解日志收集和指标收集之间的区别。它们互为补充，但目的不同：

衡量标准

在一段时间内测量的一系列数字。

日志

日志记录 程序运行过程中发生的情况，包括任何错误、警告或值得注意的事件。

例如，当应用程序性能不佳时，您就需要同时使用指标和日志。我们发现问题的第一个迹象可能是托管应用程序的 pod 上出现了高延迟警报，但指标可能无法很好地说明问题。这时，我们就可以查看日志，调查应用程序中出现的错误。

监测技术

封闭式监控侧重于从应用程序外部进行监控，传统上用于监控系统的 CPU、内存、存储等组件。闭箱监控对于基础架构层面的监控仍然有用，但它缺乏对应用程序运行情况的深入了解和上下文。例如，为了测试集群是否健康，我们可能会调度一个 pod，如果调度成功，我们就知道集群内的调度器和服务发现是健康的，因此我们可以认为集群组件是健康的。

开箱监控侧重于应用程序状态背景下的细节，如 HTTP 请求总数、500 错误数、请求延迟等。通过开箱监控，我们可以开始了解系统状态的原因。它允许我们问："为什么磁盘会填满？"而不仅仅是说："磁盘填满了"。

监测模式

您可能会在 上看到监控，然后说："这有什么难的？我们一直都在监控我们的系统。监控的概念并不新鲜，我们有很多工具可以帮助我们了解系统的运行情况。但 Kubernetes 等平台的动态性和瞬时性更强，因此你需要改变监控这些环境的思路。例如，在监控虚拟机（VM）时，您希望虚拟机全天候运行，并保留其所有状态。而在 Kubernetes 中，pod 可能是非常动态和短暂的，所以你需要有能够处理这种动态和短暂性质的监控。

在监控分布式系统时，有两种监控模式值得关注。USE方法（ ）由 Brendan Gregg 推广，其重点如下：

• U 使用

• S 饱和度

• E 错误

这种方法主要针对基础架构监控，因为在应用级监控中使用这种方法会受到限制。USE 方法被描述为 "对于每种资源，检查利用率、饱和度和错误率"。此方法可让您快速识别系统的资源限制和错误率。例如，要检查集群中节点的网络健康状况，就需要监控利用率、饱和度和错误率，以便能够轻松识别网络堆栈中的任何网络瓶颈或错误。USE 方法是更大工具箱中的一个工具，并不是监控系统的唯一方法。

汤姆-威尔基（Tom Wilkie）推广了另一种监测方法，称为 RED法。RED 方法的重点如下：

• R 比率

• E 错误

• D-持续时间

这一理念源自谷歌的 "四大黄金信号"：

延迟

送达申请需要多长时间

交通

对系统的要求有多高

错误

请求失败率

饱和度

您的服务利用率有多高

举例来说，您可以用这种方法来监控 Kubernetes 中运行的前端服务，计算出以下结果：

• 我的前端服务正在处理多少个请求？

• 服务用户收到多少个 500 错误？

• 服务是否因请求而被过度使用？

从前面的例子可以看出，这种方法更注重用户的服务体验。

USE 和 RED 方法是互补的，因为 USE 方法侧重于基础设施组件，而 ...