原文发表于kubernetes中文社区，为作者原创翻译 ，原文地址
更多kubernetes文章，请多关注kubernetes中文社区
目录
Circonus最近对Kubernetes运营商进行的一项调查中，收集哪些健康状况指标是运营商面临的最大挑战之一。考虑到Kubernetes每天可以生成数百万个指标，这不足为奇。
在本文中，我们将分享哪些健康指标对于Kubernetes运营商最关键。
1. 资源和利用率指标
资源和利用率指标来自内置的metrics 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闲置在那里。
2. 状态指标
kube-state-metrics是一个组件，可提供有关集群对象（node，pod，DaemonSet，namespaces等）状态的数据。
| 指标 | 名称 | 描述 |
|---|---|---|
| 节点状态 | 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挂起，Deployment故障，DaemonSets未准备好和StatefulSets未准备好。
3. 控制平面指标
Kubernetes控制平面包含Kubernetes的“系统组件”，可以帮助进行集群管理。在Google或Amazon提供的托管环境中，控制平面由云提供商管理，你通常不必担心监视这些指标。但是，如果你管理自己的集群，则需要了解如何监视控制平面。
| 指标 | 名称 | 描述 |
|---|---|---|
| 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调度到节点上所花费的总时间。 |
4. 控制平面健康状况
你应该监视控制平面上的以下健康状况：
etcd集群中是否有leader
etcd集群应始终有一个leader（在更改leader的过程中除外，这种情况很少见）。你应该密切注意所有etcd_server_has_leader指标，因为如果很多集群成员没有leader，那么集群性能将会下降。另外，如果你在etcd_server_leader_changes_seen_total中看到leader变更很多次，则可能表明etcd集群存在连接性或资源问题。
API请求延迟
如果将apiserver_request_latencies_count划分为apiserver_request_latencies_sum，则将获得API服务器每个请求的平均延迟。跟踪随时间不断变化的平均请求延迟可以让你知道服务器何时不堪重负。
工作队列延迟
工作队列是由controller manager管理的队列，用于处理集群中的所有自动化流程。监视workqueue_queue_duration_seconds的增加，将使你知道队列延迟何时增加。如果发生这种情况，你可能需要深入研究controller manager日志以查看发生了什么。
调度程序问题
调度程序有两个方面值得关注。首先，你应该监视scheduler_schedule_attempts_total {result：unschedulable}，因为无法调度的Pod的增加可能意味着你的集群存在资源问题。其次，你应该使用上面指示的延迟指标之一来监视调度程序延迟。Pod调度延迟的增加可能会导致其他问题，也可能表明集群中存在资源问题。
5. 事件
除了从Kubernetes集群中收集数值指标外，从集群中收集和跟踪事件也很有用。集群事件可以帮助你监视Pod生命周期并观察重大Pod故障，并且监视从集群流出的事件的速率可以是一个很好的预警指标。如果事件发生率突然显着变化，则可能表明发生了问题。
6. 应用程序指标
与我们上面检查的指标和事件不同，应用程序指标不是从Kubernetes本身发出的，而是从集群运行的工作负载发出的。从应用程序的角度来看，这种监控可以是你认为重要的任何事情：错误响应，请求延迟，处理时间等。
关于如何收集应用程序度量标准，有两种方式。第一个是，应该将指标数据从应用程序“推送”到收集端点。这意味着必须将像StatsD这样的客户端与每个应用程序捆绑在一起，以提供一种将指标标准数据推出该应用程序的机制。该技术需要更多的管理开销，以确保正确地检测集群中运行的每个应用程序，因此它在集群管理器中不受欢迎。
第二种是，指标收集原理（正在被越来越广泛地采用），指标应由收集代理从应用程序中“拉取”。这使应用程序更易于编写，因为它们所要做的只是适当地发布了它们的指标标准，但是应用程序不必担心这些度量标准是如何被提取或删除的。这是OpenMetrics的工作方式，也是Kubernetes集群指标收集的方式。当此技术与收集代理的服务发现相结合时，它将创建一种功能强大的方法，用于从集群应用程序中收集你需要的任何类型的指标。
总结
Kubernetes每天可以生成数百万个新指标。这会带来两个大挑战。首先，许多常规的监视系统无法正确监视Kubernetes集群的大量指标。其次，数据"庞杂"使你难以跟上并知道哪些指标最重要。
你的Kubernetes监视解决方案必须具有处理所有这些数据的能力，并能够自动分析，图形化和警告要注意的最关键指标。这样，你就知道自己已经收集了期望的一切，过滤掉了不必要的数据，并自动缩小了相关数据的范围。因此，你可以节省大量时间，并确保一切都能正常进行。
译文链接：https://thenewstack.io/which-kubernetes-health-metrics-should-be-monitored/