文章目录
Prometheus-operator监控告警方案说明
一、Prometheus介绍
简介
Prometheus 是一套开源的系统监控报警框架。它启发于 Google 的 borgmon 监控系统，由工作在 SoundCloud 的 google 前员工在 2012 年创建，作为社区开源项目进行开发，并于 2015 年正式发布。2016 年，Prometheus 正式加入 Cloud Native Computing Foundation，成为受欢迎度仅次于 Kubernetes 的项目。
作为新一代的监控框架，Prometheus 具有以下特点：
- 强大的多维度数据模型
① 时间序列数据通过 metric 名和键值对来区分
② 所有的 metrics 都可以设置任意的多维标签
③ 数据模型更随意，不需要刻意设置为以点分隔的字符串
④ 可以对数据模型进行聚合，切割和切片操作
⑤ 支持双精度浮点类型，标签可以设为全 unicode
灵活而强大的查询语句（PromQL）：在同一个查询语句，可以对多个 metrics 进行乘法、加法、连接、取分数位等操作
易于管理： Prometheus server 是一个单独的二进制文件，可直接在本地工作，不依赖于分布式存储
高效：平均每个采样点仅占 3.5 bytes，且一个 Prometheus server 可以处理数百万的 metrics
使用 pull 模式采集时间序列数据，这样不仅有利于本机测试而且可以避免有问题的服务器推送坏的 metrics
可以采用 push gateway 的方式把时间序列数据推送至 Prometheus server 端
可以通过服务发现或者静态配置去获取监控的 targets
有多种可视化图形界面
易于伸缩
随着容器技术的迅速发展，Kubernetes 已然成为大家追捧的容器集群管理系统。Prometheus 作为生态圈 Cloud Native Computing Foundation（简称：CNCF）中的重要一员,其活跃度仅次于 Kubernetes, 现已广泛用于 Kubernetes 集群的监控系统中。本文将简要介绍 Prometheus 的组成和相关概念，并实例演示 Prometheus 的安装，配置及使用，以便开发人员和云平台运维人员可以快速的掌握 Prometheus。
Prometheus组成及架构
Prometheus 生态圈中包含了多个组件，其中许多组件是可选的：
Prometheus Server: 用于收集和存储时间序列数据
Client Library: 客户端库，为需要监控的服务生成相应的 metrics 并暴露给 Prometheus server。当 Prometheus server 来 pull 时，直接返回实时状态的 metrics
Push Gateway: 主要用于短期的 jobs。由于这类 jobs 存在时间较短，可能在 Prometheus 来 pull 之前就消失了。为此，这次 jobs 可以直接向 Prometheus server 端推送它们的 metrics。这种方式主要用于服务层面的 metrics，对于机器层面的 metrices，需要使用 node exporter
Exporters: 用于暴露已有的第三方服务的 metrics 给 Prometheus
Alertmanager: 从 Prometheus server 端接收到 alerts 后，会进行去除重复数据，分组，并路由到对收的接受方式，发出报警。常见的接收方式有：电子邮件，pagerduty，OpsGenie, webhook 等
一些其他的工具
架构图：
从上图可以看出，Prometheus 的主要模块包括：Prometheus server, exporters, Pushgateway, PromQL, Alertmanager 以及图形界面。
其大概的工作流程是：
① Prometheus server 定期从配置好的 jobs 或者 exporters 中拉 metrics，或者接收来自 Pushgateway 发过来的 metrics，或者从其他的 Prometheus server 中拉 metrics。
② Prometheus server 在本地存储收集到的 metrics，并运行已定义好的 alert.rules，记录新的时间序列或者向 Alertmanager 推送警报。
③ Alertmanager 根据配置文件，对接收到的警报进行处理，发出告警。
④ 在图形界面中，可视化采集数据。
二、概述
2.1 总体目标
从监控平台本身的业务需求来看，至少应该通过平台获取到以下的监控数据
- 性能指标(如：CPU, Memory等）
① 容器相关的性能指标数据
② 主机节点相关的性能指标数据
③ K8S平台组件Kubelet的性能指标数据
④ 容器内某个具体进程的性能指标数据
⑤ K8S上应用的网络性能，如http、tcp等数据
- 健康状态指标
① K8S资源对象（Deployment、Daemonset、Pod等）的状态指标
获取监控数据之后，还需要对监控进行可视化展示，以及对监控中出现的异常情况进行告警。
2.2 主流监控方案
目前对于kubernetes的主流监控方案主要有以下几种：
Heapster+InfluxDB+Grafana
每个K8S节点的Kubelet内含cAdvisor，暴露出API，Kubelet从cAdvisor获取数据。Heapster通过apiserver发现集群的所有节点，并通过访问每个节点的Kubelet API(nodeIP:10255/stats/summary)获取监控数据。它支持多种储存方式，常用的是InfluxDB。这套方案的缺点是数据来源单一、缺乏报警功能以及InfluxDB的单点问题，而且Heapster也已经在新版本中被deprecated(被metrics-server取代)了。
Metrics-Server+InfluxDB+Grafana
K8S从1.8版本开始，CPU、内存等资源的metrics信息可以通过 Metrics API来获取，用户还可以通过kubectl top（1.10版开始）直接获取这些metrics信息。Metrics API需要部署Metrics-Server。Metrics-Server是Kubernetes1.9版本以上的首选方法。
各种Exporter+Prometheus+Grafana
通过各种export采集不同维度的监控指标，并通过Prometheus支持的数据格式暴露出来，Prometheus定期pull数据并用Grafana展示，异常情况使用AlertManager告警。本方案下文详细叙述。
三、架构
3.1 实现思路
- 采集
① 通过cadvisor采集容器相关的性能指标数据
② 通过prometheus-node-exporter采集主机的性能指标数据
③ 通过kube-state-metrics采集K8S资源对象以及K8S组件的健康状态指标数据
④ 通过kubelet自身暴露的接口采集kubelet指标、另外，由于K8S平台其他组件是以static pod的形式启动，所以K8S组件的健康指标可以从K8S资源对象（pod）的指标中获取。
⑤ 采集应用实例中某个进程暴露的性能指标数据（暴露指标的功能由应用自己实现，并添加平台侧约定的annotation，平台侧负责根据annotation实现Prometheus的scrape）
⑥ 通过blackbox-exporter采集应用的网络性能(http、tcp、icmp等)数据
- 存储
通过prometheus pull并存储各种exporter的监控数据
- 展示
通过grafana展示监控信息
- 告警
通过alertmanager进行告警
四、监控指标采集实现
4.1 容器相关的性能指标数据—cAdvisor
cAdvisor是谷歌开源的一个容器监控工具，目前cAdvisor集成到了kubelet组件内，可以在kubernetes集群中每个启动了kubelet的节点使用cAdvisor提供的metrics接口获取该节点所有容器相关的性能指标数据。
1.7.3版本以前，cadvisor的metrics数据集成在kubelet的metrics中，在1.7.3以后版本中cadvisor的metrics被从kubelet的metrics独立出来了，在prometheus采集的时候变成两个scrape的job。
cAdvisor对外提供的默认端口为4194
Prometheus格式指标接口：nodeIP:4194/metrics(或者通过kubelet暴露的cadvisor接口nodeIP:10255/metrics/cadvisor);
WebUI界面接口：nodeIP:4194/containers/
Prometheus作为一个时间序列数据收集，处理，存储的服务，能够监控的对象必须通过http api暴露出基于Prometheus认可的数据模型的监控数据，cAdvisor接口（nodeIP:4194/metrics）暴露的监控指标数据如下所示：
可以看到以上接口的数据是按prometheus的格式输出的。
配置Prometheus来定期拉取cAdvisor的metrics：
4.2 主机节点性能指标数据-----node-exporter
Prometheus社区提供的NodeExporter项目可以对主机的关键度量指标进行监控，通过Kubernetes的DeamonSet可以在各个主机节点上部署有且仅有一个NodeExporter实例，实现对主机性能指标数据的监控。
配置Prometheus来定期拉取node-exporter的metrics：
通过NodeExporter暴露的metrics接口(nodeIP:9100/metrics)查看采集到的数据，可以看到是按Prometheus的格式
4.3 K8S平台组件kubelet性能指标
kubelet服务暴露的metrics端口默认为10255：
kubelet提供的prometheus格式指标接口：nodeIP:10255/metrics，本篇文章使用Prometheus从这里取数据
kubelet提供的stats/summary接口：nodeIP:10255/stats/summary，heapster和最新的metrics-server从这里获取数据
配置Prometheus来定期拉取node-exporter的metric
4.4 源对象（Deployment、Pod等）的状态-----kube-state-metrics
kube-state-metrics是一个简单的服务，它监听Kubernetes API服务器并生成有关对象状态的指标。
它不关注单个Kubernetes组件的运行状况，而是关注内部各种对象的运行状况，如下：
CronJob Metrics DaemonSet Metrics Deployment Metrics Job Metrics LimitRange Metrics Node Metrics PersistentVolume Metrics PersistentVolumeClaim Metrics Pod Metrics ReplicaSet Metrics ReplicationController Metrics ResourceQuota Metrics Service Metrics StatefulSet Metrics Namespace Metrics Horizontal Pod Autoscaler Metrics Endpoint Metrics Secret Metrics ConfigMap Metrics
配置Prometheus来定期拉取kube-state-metrics的metrics：
注：kube-state-metrics与Heapster
Heapster是一个项目，它从Kubernetes API服务器和节点获取指标（例如CPU和内存利用率），并将它们发送到各种时间序列后端，例如InfluxDB或Google Cloud Monitoring。它目前最重要的功能是实现Kubernetes组件的某些度量API，如水平pod自动缩放器查询来做出决策。
虽然Heapster的重点是转发已由Kubernetes生成的指标，但kube-state-metrics的重点是从Kubernetes的对象状态生成全新的指标（例如，基于部署，副本集等的指标）。不使用kube-state-metrics的能力扩展Heapster的原因是因为关注点根本不同：Heapster只需要获取，格式化和转发已经存在的指标，特别是来自Kubernetes组件的指标，并将它们写入接收器，这些接收器是实际的监控系统。相比之下，kube-state-metrics在内存中保存了Kubernetes状态的完整快照，并不断生成基于它的新指标，但不负责在任何地方导出指标。
换句话说，kube-state-metrics本身被设计为Heapster的另一个源（尽管目前不是这种情况）。
此外，一些监控系统（如Prometheus）根本不使用Heapster进行度量收集，而是实现自己的，但 Prometheus可以从heapster本身获取指标，以警告Heapster的健康状况。将kube-state-metrics作为单独的项目，可以从这些监视系统访问这些指标。
4.5 通过blackbox-exporter采集应用的网络性能数据
blackbox导出器允许通过HTTP，HTTPS，DNS，TCP和ICMP对端点进行黑盒探测。
五、Prometheus的AlertManager原理
AlertManager用于接收Prometheus发送的告警并对于告警进行一系列的处理后发送给指定的用户。系统的整体设计图如下面所示，并且支持HA高可用部署。
5.1 AlertManager接收告警
Prometheus或者告警发送系统可以通过API的方式发送给Alertmanager，收到告警后将告警分别存储在AlertProvider中（当前实现是存储在内存中，可以通过接口的方式自行实现其他存储方式比如MySQL或者ES）。
AlertManager内部的Dispatcher通过订阅的方式获得告警信息更新（获得Alerts的迭代器，通过for循环不断的获得发送到信道中的Alerts,通过route的match函数获得匹配的route对象（比如基于标签的正则表达，传递到不同的邮件或者slack信道路由）,并且每隔一段时间将执行一次清理操作（当ag中的告警数量为空的时候），删除之前的记录。收到的Alert通过标签匹配的方式被送到不同的聚合组中等待Pipeline流程进行处理。
聚合组用来管理具有相同属性信息的告警，通过将相同类型的告警进行分组可以统一的管理，因为有时候告警处理是大量同时出现的（比如一个数据中心的失效将导致成百上千的告警产生，通过分组可以聚合相同标签到一个邮件或者接收者中）。分组创建将依赖于处理route路由和告警的labels标签，不同的告警labels将产生不同的聚合组，所有接受到的告警将首先计算一个聚合组的Fingerprint如果找到则直接插入到该组，否则创建一个新的聚合组，每次新创建的聚合组都会启动一个goroutine来执行实际的pipeline work.
每一个聚合组在管理告警上都会通过内部的run方法来不断的循环获取一段时间内的告警，并对于时间段的告警进行聚合处理，如下面的代码所示，当接收到完成信号时候退出run方法结束该组。默认的GroupInterval时间为5分钟
执行的flush函数将首先对于alerts进行排序（依赖于job和instance）,排序后的alerts组将被传递给notify函数进行处理 。
5.2 Pipeline
Pipeline用来定义告警处理流程，Alertmanager当前对于告警处理支持的流程包括：Inhibitor, Silencer。
- Inhibit 管理
Inhibitor用于管理相同的告警配置，比如配置定义了当告警名称alertname一致的时候，如果严重告警存在的时候，同级别告警将被过滤掉。
查询流程上将获得的alert的label进行检查，匹配检查的内容满足target匹配但是source不匹配的标记为Inhibited.
其中的inhibited.marker是一个结构体对象实现了Marker接口,通过这个接口实现，可以用来管理告警状态比如设置Inhibited和Silieced状态，获取统计信息和按状态列出指定的类别告警。
- Silence管理
Silencer用来取消告警，比如直接配置告警在某一段时间内不触发任何消息，可以基于正则表达式的匹配，该配置可以通过alertmanager的WebUI或者API接口配置。
在Pipeline中执行的过程，当流程传递到Silence步骤时候，Silence模块将循环检查每一个告警是否满足匹配，比如设置某一个告警标签出现后取消告警。当查询结束后返回一个sils（Silence的结构体，用来指定某一类告警的Silence在一段时间内的处理对象。）一个告警可能会被多个Silence同时管理。
同时要实现集群管理，彼此之间的Silence状态也要共享（告警发送给多个AM），因此系统设计的时候加入了SilenceProvider来进行集群之间的Silence管理,彼此之间通过protoBuf来进行数据状态的同步。同时集群在接收到告警后也要进行通知，告知其他的节点关于告警的处理状态，防止多个通知同时被发送。
六、场景应用场景案例
6.1 集群级别
6.1.1 k8s系统组件运行不正常告警
1） 通过命名空间kube-system角度实现
2）、通过指定系统组件pod名称
6.1.2 pod，deployment，statefulSet，发生异常事件时
1）、pod发生异常
2）、deployment发生异常
3）、statefulSet发生异常
6.1.3 集群宿主机异常时，CPU，内存，超过阈值时
1）、CPU超过阈值
2）、内存超过阈值
3）磁盘超过阈值
4）、主机异常
6.1.4 Kubelet监控
6.1.5 ApiServer监控
6.1.6 KubeScheduler监控
6.1.7 KubeController监控
6.2 用户级别
6.2.1 指定pod运行状态，指未运行，未调度，重启
6.2.2 pod运行CPU，内存使用超过某个阈值时告警
1）、指定pod运行CPU使用超过某个阈值时告警
2）、指定pod运行内存使用超过某个阈值时告警
83
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
