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（
 贤蛋大眼萌
|
