# 流程

## 1、监控目的

（1）发现已经出现的问题；

（2）预防即将出现的问题。

## 2、监控什么内容

（1）系统基础指标（内存、CPU、IO、Disk、Network等）;

（2）服务基础信息（存活，占用的系统资源等）;

（3）服务个性化（接口、固定返回值等）;

（4）日志内容（从日志中获取报错信息）;

## 3、如何监控

（1）数据采集（要先配置采集什么内容）;

（2）数据存储（采集完数据之后，需要有数据库来进行存储）;

（3）定义报警规则（采集的数据经过分析之后，到达什么阈值满足报警规则）;

（4）配置报警方式（当触发报警规则之后，通过什么方式来报警，邮件？微信？亦或者别的）;

## 4、k8s中监控内容

（1）节点-指标；

（2）容器-指标；

（3）集群本身的组件；

## 5、Prometheus（普罗米修斯）监控

（1）`Prometheus`是一套开源的监控&报警&时间序列数据库的组合；

> 时序系列数据库：按照时间顺序记录系统、设备状态变化的数据被称为时序数据。

（2）是一系列服务的组合，并不是单个服务；

（3）系统层、中间件层、应用层监控；

## 6、Prometheus（普罗米修斯）监控的特征

（1）由`metric`名称和`kv`标识的多维数据模型；

（2）灵活的查询语言；

（3）支持`pull`、`push`两种方式添加数据；

（4）支持基于`kubernetes`服务发现的动态配置；

## 7、Prometheus（普罗米修斯）架构

![图片](https://figure-bed-1304788733.cos.ap-guangzhou.myqcloud.com/typora/202207051201376.jpeg)

**8、Prometheus（普罗米修斯）数据****类型**

## 

（1）`Counter`：用于记录累积的数值；

（2）`Gauge`：常规数值，比如监控数据的变化；

（3）`Histogram` && `Summary`统计和分析样本的结果数值；

## 9、Prometheus（普罗米修斯）数据来源

（1）服务器基础指标

![图片](https://figure-bed-1304788733.cos.ap-guangzhou.myqcloud.com/typora/202207051201354.jpeg)



（2）`k8s（Docker）`容器指标

![图片](https://figure-bed-1304788733.cos.ap-guangzhou.myqcloud.com/typora/202207051201437.jpeg)



（3）`Kubernetes`组件

![图片](https://figure-bed-1304788733.cos.ap-guangzhou.myqcloud.com/typora/202207051201302.jpeg)





# 指标

## 一、资源和利用率指标

资源和利用率指标来自内置的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闲置在那里。

## 二、状态指标

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未准备好。

## 三、控制平面指标

Kubernetes控制平面包含Kubernetes的“系统组件”，可以帮助进行集群管理。在Google或Amazon提供的托管环境中，控制平面由云提供商管理，你通常不必担心监视这些指标。但是，如果你管理自己的集群，则需要了解如何监视控制平面。

|          指标           |                             名称                             |                          描述                           |
| :---------------------: | :----------------------------------------------------------: | :-----------------------------------------------------: |
|       etcd领导者        |                    etcd_server_has_leader                    |            指示该成员是否知道其领导者是谁。             |
|     etcd领导者变动      |            etcd_server_leader_changes_ seen_total            |               etcd集群中领导者变更总数。                |
|        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领导者

etcd集群应始终有一个领导者（在更改领导者的过程中除外，这种情况很少见）。你应该密切注意所有etcd_server_has_leader指标，因为如果很多集群成员没有领导者，那么集群性能将会下降。另外，如果你在etcd_server_leader_changes_seen_total中看到大量的领导者变更，则可能表明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调度延迟的增加可能会导致其他问题，也可能表明集群中存在资源问题。

## 事件

除了从Kubernetes集群中收集数值指标外，从集群中收集和跟踪事件也很有用。集群事件可以帮助你监视Pod生命周期并观察重大Pod故障，并且监视从集群流出的事件的速率可以是一个很好的预警指标。如果事件发生率突然显着变化，则可能表明发生了问题。

## 应用程序指标

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

关于如何收集应用程序度量标准，有两种方式。第一个是，应该将指标数据从应用程序“推送”到收集端点。这意味着必须将像StatsD这样的客户端与每个应用程序捆绑在一起，以提供一种将指标标准数据推出该应用程序的机制。该技术需要更多的管理开销，以确保正确地检测集群中运行的每个应用程序，因此它在集群管理器中不受欢迎。

第二种是，指标收集原理（正在被越来越广泛地采用），指标应由收集代理从应用程序中“拉取”。这使应用程序更易于编写，因为它们所要做的只是适当地发布了它们的指标标准，但是应用程序不必担心这些度量标准是如何被提取或删除的。这是OpenMetrics的工作方式，也是Kubernetes集群指标收集的方式。当此技术与收集代理的服务发现相结合时，它将创建一种功能强大的方法，用于从集群应用程序中收集你需要的任何类型的指标。