k8s集群监控
目前，监控K8S集群较为流行的方案如下：
方案一：Heapster + influxDB + Grafana
Heapster 是 Kubernetes 原生的集群监控方案。Heapster 以 Pod 的形式运行，在其配置文件内传入kubernetes master的地址，Heapster就会自动发现集群节点、从节点上的 Kubelet 获取监控数据。Kubelet 则是从节点上的 cAdvisor 收集数据。Heapster将数据存储到预先配置的 backend 并进行可视化展示，Heapster 当前支持的 backend 有很多种，如 InfluxDB，而Grafana则是influxDB的dashboard，提供了强大的图表展示功能。
注：cadvisor是google用来分析运行中的docker的容器的资源占用以及host性能特性的工具，它会将数据的数据给kublet，kublet已集成cadvisor，无需安装。
方案二：Prometheus+ grafana
Prometheus是一套开源的集时间序列数据存储、dashboard、报警功能的组合组件，监控范围覆盖容器、主机、存储、数据库、各种中间件，同时还具备完善的时序数据存储、告警处理等能力。它的服务过程是由Prometheus daemon 负责定时去目标上抓取 metrics(指标) 数据，每个抓取目标需要暴露一个http服务的接口给它定时抓取。之后将抓取的数据存入本地或远端存储。而Grafana是将Prometheus中存储的数据完美的展现出来。同时Prometheus 可配置 rules，进行Alert Rule 配置管理。prometheus会定时查询数据，当条件触发的时候，会将 alert（警告） 推送（pushalerts）到配置的 Alertmanager。
两个方案的对比：
1.监控数据采集
heapster的监控采集依赖cAdvisor,只能监控node和容器，监控的数据范围有限，对k8s和容器中的服务却无能为力；而对于prometheus来说，支持Prometheus端点或是提供http端口的metrics转换器都可以手动拉取数据，而且k8s支持prometheus http的度量端点。意味着可以去pull k8s各种资源的metrics数据。
2.功能
prometheus提供了heapster没有的报警功能。
具体地，以下为prometheus方案。
主要分为以下几个部分：
————————
监控告警：Prometheus + Exporters + AlertManager + 企业微信
监控视图：Prometheus + Exporters + Grafana
两个者都有 Prometheus + Exporters，其中：
1、Prometheus：时序数据库，用于存储监控的指标（Metrics）数据，它定时从 Exporters 拉取数据。其具备定期清理功能，无需担心数据增长问题。
2、Exporters：各种 Exporter，用于提供监控指标（Metrics），各个 exporter，以HTTP /metrics 暴露 API，供 Prometheus拉取数据。
3、AlertManager：对接 Prometheus，当 Prometheus 根据自己的报警规则，发现有规则触发时，会将告警信息传递给 AlertManager，由 AlertManager自己的一套流程下发告警，Prometheus只管发告警数据给AlertManager，无需关心以什么形式下发给接受者。
4、Grafana：监控视图展示，它支持直接从 Prometheus 查询，进而在自己的页面上进行展示。
5、企业微信：对接 AlertManager，AlertManager 将告警信息，发送给企业微信后端接口，然后接受用户即可通过企业微信收到告警信息。
主组件选型条件：
————————
Prometheus：时序数据库
Prometheus优势：
①：质量：符合CNCF基金会项目标准
②：开源及扩展性：开源，700+共享者，几百个第三方支持。基于Golang编写，可定制。
③：K8S支持：对接K8S友好，对于监控K8S和容器本身友好，对部署到K8S内部的自定义监控指标同样友好。
④：告警：自带告警功能
⑤：对接视图展示：本身就有视图，还支持对接更好的第三方可视化。
⑥：部署：方便，灵活，它无需在宿主机上部署专门的agent代理。
————————
Grafana：数据视图展示。
Grafana优势：
①：开源，公司内部已部署有一套Grafana系统。
②：界面干净，漂亮。
③：灵活性很好。
④：支持很多源，包括Prometheus源。
————————
企业微信：告警接收。
————————
Prometheus Alert Manager：告警信息发送组件，它和 Prometheus配套使用。（可发送给短信、企业微信等）
————————
Exporters列表：
①：kube-state-metrics：采集K8S资源对象以及K8S组件的健康状态指标数据，主要是Kubernetes集群上Pod, DaemonSet, Deployment, Job, CronJob等各种资源对象的状态，比如pod重启等。此组件需要DaemonSet模式启动，或者每个机器都启动一个。
②：blackbox-exporter：监控http、tcp、icmp网络性能。k8s本身的只能用于探测进而保活，但无法探测性能如何，blackbox-exporter为性能探测提供了一种可能。它可以探测一个应用的性能概览，从dns解析->链接建立->tls握手->等待应用响应数据->数据传输等时间。
③：node-directory-size-metrics：主要用于读取节点目录，获取磁盘使用metric数据。注意，它只检测/mnt目录下的目录的磁盘使用，如果你有需检测某个机器上某个目录的变化，使用这个组件比较合适，前提是需要把那个目录，挂载到 /mnt目录下。同样，需要 DaemonSet模式启动。
④：cadvisor：收集容器的信息，如CPU、内存、磁盘IO等等，这个组件是监控容器的核心。同样，需要 DaemonSet模式启动。
⑤：node-exporter：用于收集宿主机信息，如：CPU、内存、宿主机文件IO、ipvs信息等。同样，需要 DaemonSet模式启动。
监控告警告警部分的指标列表：
————————
针对k8s，要接收告警信息需要有：
1、k8s节点异常
2、k8s磁盘使用率告警
3、pod crash
4、pod未运行
5、pod内存使用超限
6、Pod的CPU使用超限
7、Pod OOM重启
8、Daemonset 创建后卡住，也就是无法创建实例出来（rollout stuck）
9、Deployment 创建后卡住（rollout stuck）
10、Daemonset 创建后无法调度
11、Deployment 创建后无法调度
12、Node NodeNotReady
12、K8SManyNodesNotReady
13、k8s节点 OutOfDisk（磁盘耗尽）
14、K8s节点磁盘压力
15、k8s节点内存压力
16、k8s节点CPU压力
17、k8s节点不可调度
18、pod 内存增长过快（比如短时间增长超过512M）
19、k8s节点的内存需求超过k8s节点本身内存的一个阈值（比如80%）
20、pod的磁盘IO过高
————————
针对宿主机部分：
1、磁盘使用率
2、宿主机是否挂掉
3、宿主机CPU占用率
4、宿主机文件IO高（蚂蜂窝目前的磁盘IO，到600就几乎不行了，阈值可以设置为450）
5、宿主机网络流量
6、宿主机内存使用率
————————
针对Prometheus本身
1、配置reload失败
2、Prometheus丢弃通知数量过高
3、Promehtues通知队列过高
————————
针对容器
- 磁盘占用率
- Cup占用率
- 内存使用率
- 磁盘IO高