应该监控哪些 Kubernetes 健康指标

应该监控哪些 Kubernetes 健康指标

我之前写过一篇关于您应该监控的 12 种最常见健康状况的文章，以确保 Kubernetes 以最佳方式运行。 但是，您应该收集和分析哪些导致这些健康状况（以及更多）的指标？

在 Circonus 最近对 Kubernetes 运营商进行的一项调查中，围绕要收集哪些指标的不确定性是监控运营商面临的最大挑战之一。 鉴于 Kubernetes 每天可以生成数百万个指标，这并不奇怪。

在本文中，我们将分享哪些健康指标对于 Kubernetes 运营商收集和分析最重要。 我们将查看这些指标的三个来源，按来源定义和命名每个指标，以及它们与您应该监控的健康状况相关联。

#1：资源和利用率指标

资源和利用率指标来自内置指标 API，由 Kubelets 本身提供。 我们仅将 CPU 使用情况用作关键的健康状况，但监控内存使用情况和网络流量也很重要。

指标	名称	描述
CPU使用率	usageNanoCores	节点或Pod每秒使用的CPU核数。
CPU容量	capacity_cpu	节点上可用的CPU内核数量（不适用于Pod）。
内存使用情况	used{resource:memory,units:bytes}	节点或Pod使用的内存量（以字节为单位）。
内存容量	capacity_memory{units:bytes}	节点可用的内存容量（不适用于Pod），以字节为单位。
网络流量	rx{resource:network,units:bytes} tx{resource:network,units:bytes}	节点（或Pod）看到的总网络流量（已接收（传入）流量和已传输（传出）流量），以字节为单位。

高 CPU 使用率是监控和警告使用这些指标的关键健康状况。 这是最容易理解的：您应该跟踪您的节点使用了多少 CPU 周期。 出于两个原因，这对监控很重要。 首先，您不想耗尽应用程序的处理资源。 如果您的应用程序受 CPU 限制，则需要增加 CPU 分配或向集群添加更多节点。 其次，你不希望你的 CPU 坐在那里闲置。 如果您的 CPU 使用率一直很低，则您可能过度分配了资源并可能浪费金钱。 您应该将利用率{resource:cpu} 与特定时间窗口内的预先确定的阈值进行比较（例如它是否超过阈值超过 5 分钟？），以确定您的 CPU 使用率是否过高。

#2: 状态指标

kube-state-metrics 是一个组件，它提供有关集群对象（节点、pod、DaemonSet、命名空间等）状态的数据。 它通过提供资源和利用率指标的相同指标 API 提供其指标。

指标	名称	描述
节点状态	kube_node_status_condition {status:true,condition:OutOfDisk| MemoryPressure|PIDPressure| DiskPressure|NetworkUnavailable}	当status为true时，指示该节点当前正在经历该条件。
循环崩溃(Crash Loops)	kube_pod_container_status_waiting_reason {reason： CrashLoopBackOff}	指示pod中的容器是否正在发生循环崩溃。
任务状态（失败）	kube_job_status_failed	指示任务是否失败。
持久卷状态（失败）	kube_persistentvolume_status _phase {phase：Failed}	指示持久卷是否失败。
Pod状态（Pending）	kube_pod_status_phase{phase:Pending}	指示Pod是否处于挂起状态。
Deployment	kube_deployment_metadata _generation	代表Deployment的序列号。
Deployment	kube_deployment_status_observed_generation	代表控制器观察到的当前Deployment生成的序列号。
DaemonSet期望的节点数	kube_daemonset_status_ desired_number_scheduled	DaemonSet期望的节点数。
DaemonSet当前的节点数	kube_daemonset_status_ current_number_scheduled	DaemonSet运行中的节点数。
期望的StatefulSet副本	kube_statefulset_status_replicas	每个StatefulSet期望的副本数。
准备就绪的StatefulSet副本	kube_statefulset_status_replicas _ready	每个StatefulSet准备好的副本数。

使用这些指标，您应该监控并发出警报：崩溃循环、磁盘压力、内存压力、PID 压力、网络不可用、作业失败、持久性卷失败、Pod 挂起延迟、部署故障、DaemonSet 未就绪和 StatefulSet 未就绪。

#3 控制平面指标

Kubernetes 控制平面包含 Kubernetes 被视为“系统组件”的部分，用于帮助进行集群管理。 在像谷歌或亚马逊提供的托管环境中，控制平面由云提供商管理，您通常不必担心监控这些指标。 但是，如果您管理自己的集群，您会想知道如何监控您的控制平面。 当它们可用时，大多数这些指标都可以通过指标 API 找到。

指标	名称	描述
etcd集群是否有leader	etcd_server_has_leader	指示该成员是否知道其leader是谁。
etcd集群中leader变动总数	etcd_server_leader_changes_ seen_total	etcd集群中leader变更总数。
API延迟数	apiserver_request_latencies_count	API请求总数；用于计算每个请求的平均延迟。
API延迟总和	apiserver_request_latencies_sum	所有API请求持续时间的总和；用于计算每个请求的平均延迟。
队列等待时间	workqueue_queue_duration_ seconds	每个控制器管理器中的工作队列等待所花费的总时间。
队列持续时间	workqueue_work_duration_ seconds	每个控制器管理器中的工作队列处理操作所花费的总时间。
调度失败Pod的总尝试次数	scheduler_schedule_attempts _total {result：unschedulable}	调度程序尝试在节点上调度失败了Pod的总尝试次数。
Pod调度延迟	scheduler_e2e_scheduling_ delay_microseconds（<v1.14） 或 scheduler_e2e_scheduling_ duration_seconds	将Pod调度到节点上所花费的总时间。

控制平面健康状况

您应该监控以下控制平面运行状况：

etcd Leaders

etcd 集群应该总是有一个领导者（除了在改变领导者的过程中，这应该很少发生）。你应该密切关注你所有的 etcd_server_has_leader 指标，因为如果太多集群成员不认识他们的领导者，你的集群性能将会下降。此外，如果您看到 etcd_server_leader_changes_seen_total 中反映了大量领导者更改，则可能表明 etcd 集群中存在连接或资源问题。

API 请求延迟

如果您将 apiserver_request_latencies_count 划分为 apiserver_request_latencies_sum，您将获得 API 服务器每个请求的平均延迟。随着时间的推移跟踪平均请求延迟可以让您知道您的服务器何时不堪重负。

工作队列延迟

工作队列是由控制器管理器管理的动作队列，用于处理集群中的所有自动化进程。观察 workqueue_queue_duration_seconds 或 workqueue_queue_duration_seconds 的增加会让您知道队列延迟何时增加。如果发生这种情况，您可能需要深入研究控制器管理器日志以查看发生了什么。

调度程序问题

调度器有两个方面值得关注。首先，您应该监控 scheduler_schedule_attempts_total{result:unschedulable}，因为不可调度 pod 的增加可能意味着您的集群存在资源问题。其次，您应该使用上面指出的延迟指标之一（指标名称和单位随 v1.14 更改）密切关注调度程序延迟。 Pod 调度延迟的增加可能会导致其他问题，也可能表明集群中存在资源问题。

事件

除了从 Kubernetes 集群收集数字指标之外，从集群收集和跟踪事件也很有用。集群事件将让您监控 pod 生命周期并观察重大的 pod 故障，并且观察从集群流出的事件速率可以是一个很好的早期预警指标。如果事件发生率突然或显着变化，则可能表明出现问题。

应用指标

与我们上面检查的其他指标和事件不同，应用程序指标不是从 Kubernetes 本身发出的，而是从集群运行的工作负载发出的。从应用程序的角度来看，这种遥测可以是您认为重要的任何内容：错误响应、请求延迟、处理时间等。

关于如何收集应用程序指标有两种哲学。

第一个（直到最近才被广泛采用）是指标应该从应用程序“推送”到收集端点。这意味着像 StatsD 这样的客户端必须与每个应用程序捆绑在一起，以提供一种机制来将度量数据推出该应用程序。这种技术需要更多的管理开销来确保集群中运行的每个应用程序都得到正确的检测，因此它开始不受集群管理器的青睐。

第二个指标收集理念（越来越广泛采用）是指标应该由收集代理从应用程序中“拉取”。这使得应用程序更容易编写，因为他们所要做的就是适当地发布他们的指标——但应用程序不必担心这些指标是如何被提取或抓取的。这就是 OpenMetrics 的工作方式，也是收集 Kubernetes 集群指标的方式。当此技术与您的收集代理的服务发现相结合时，它创建了一种强大的方法来从您的集群应用程序中收集您需要的任何类型的指标。

结语

Kubernetes 每天可以生成数百万个新指标。这会带来两大挑战。首先，许多传统的监控系统无法跟上正确监控 Kubernetes 集群所需的大量独特指标。其次，所有这些数据“噪音”使得很难跟上并了解哪些指标最重要。

您的 Kubernetes 监控解决方案必须能够处理所有这些数据，并自动分析、绘制图表并就需要关注的最关键指标发出警报。这样，您就知道您已经收集了所需的一切，过滤掉了不必要的数据，并自动缩小了最相关的数据。因此，您可以节省大量时间，并确保一切正常运行。

参考文档：
[1]: https://thenewstack.io/which-kubernetes-health-metrics-should-be-monitored/