k8s—Prometheus原理

一、Prometheus

1.Prometheus介绍

Prometheus 是一个开源的系统监控和报警系统，现在已经加入到 CNCF 基金会，成为继k8s 之后第二个在 CNCF 托管的项目，在 kubernetes 容器管理系统中，通常会搭配prometheus 进行监控，同时也支持多种 exporter 采集数据，还支持 pushgateway 进行数据上报， Prometheus 性能足够支撑上万台规模的集群；

1.1 Prometheus特点

1）多维度数据模型

每一个时间序列数据都由 metric 度量指标名称和它的标签 labels 键值对集合唯一确定：这个 metric 度量指标名称指定监控目标系统的测量特征（如：http_requests_total- 接收 http 请求的总计数）。labels 开启了 Prometheus 的多维数据模型：对于相同的度量名称，通过不同标签列表的结合, 会形成特定的度量维度实例。(例如：所有包含度量名称为/api/tracks 的 http 请求，打上 method=POST 的标签，则形成了具体的 http 请求)。这个查询语言在这些度量和标签列表的基础上进行过滤和聚合。改变任何度量上的任何标签值，则会形成新的时间序列图

2）灵活的查询语言

3）可以直接在本地部署，不依赖其他分布式存储；

4）通过基于 HTTP 的 pull 方式采集时序数据；

5）可以通过中间网关 pushgateway 的方式把时间序列数据推送到 prometheus server 端；

6）可通过服务发现或者静态配置来发现目标服务对象（targets）。

7）高效的存储，每个采样数据占 3.5 bytes 左右，300 万的时间序列，30s 间隔，保留 60 天，消耗磁盘大概 200G。

8）做高可用，可以对数据做异地备份，联邦集群

1.2 样本

在时间序列中的每一个点称为一个样本（sample），样本由三部分组成：

指标（metric）：指标名称和描述当前样本特征的 labelsets；

时间戳（timestamp）：一个精确到毫秒的时间戳；

样本值（value）： 一个 folat64 的浮点型数据表示当前样本的值。

表达方式：<metric name>{<label name>=<label value>, ...}

例如，指标名称为 api_http_requests_total，标签为 method="POST"handler="/messages"

的时间序列可以表示为：

api_http_requests_total{method="POST", handler="/messages"}

2. Prometheus组件介绍

1）Prometheus Server: 用于收集和存储时间序列数据。

2）Client Library: 客户端库，检测应用程序代码，当 Prometheus 抓取实例的 HTTP 端点时，客户端库会将所有跟踪的 metrics 指标的当前状态发送到 prometheus server 端。

3）Exporters: prometheus 支持多种 exporter，通过 exporter 可以采集 metrics 数据，然后发送到prometheus server 端，所有向 promtheus server 提供监控数据的程序都被称为exporter

4）Alertmanager: 从 Prometheus server 端接收到 alerts 后，会进行去重，分组，并路由到相应的接收方，发出报警，常见的接收方式有：电子邮件，微信，钉钉, slack 等。

5）Grafana：监控仪表盘，可视化监控数据

6）pushgateway: 各个目标主机可上报数据到 pushgateway，然后 prometheus server 统一从pushgateway 拉取数据

从上图可发现，Prometheus 整个生态圈组成主要包括 prometheus server，Exporter，

pushgateway，alertmanager，grafana，Web ui 界面；

Prometheus server 由三个部分组成， Retrieval，Storage，PromQL

1）Retrieval 负责在活跃的 target 主机上抓取监控指标数据

2）Storage 存储主要是把采集到的数据存储到磁盘中

3） PromQL 是 Prometheus 提供的查询语言模块

3.Prometheus工作流程

1）Prometheus server 可定期从活跃的（up）目标主机上（target）拉取监控指标数据，目标主机的监控数据可通过配置静态 job 或者服务发现的方式被 prometheus server 采集到，这种方式默认的 pull 方式拉取指标；也可通过 pushgateway 把采集的数据上报到 prometheus server 中；还可通过一些组件自带的 exporter 采集相应组件的数据；

2）Prometheus server 把采集到的监控指标数据保存到本地磁盘或者数据库；

3）Prometheus 采集的监控指标数据按时间序列存储，通过配置报警规则，把触发的报警发送到alertmanager

4）Alertmanager 通过配置报警接收方，发送报警到邮件，微信或者钉钉等

5）Prometheus 自带的 web ui 界面提供 PromQL 查询语言，可查询监控数据

6）Grafana 可接入 prometheus 数据源，把监控数据以图形化形式展示出

4.Prometheus和zabbix对比分析

Zabbix	Prometheus
后端用C开发，界面用PHP开发，定制化难度很高	后端用golang开发，前端是GRafana、json编辑即可解决，定制化难度较低
集群规模上限为10000个节点	支持更大的集群规模，速度也更快
更适合监控物理机环境	更适合云环境的监控，对openstack、kubernetes有更好的集成
监控数据存储在关系型数据库内，如MySQL	监控数据存储在基于时间序列的数据库内，便于对已有数据进行新的聚合
安装简单，zabbix-server一个软件包中有所有的服务端功能	安装相对复杂，监控、告警和界面部分属于不同的组件
图形化界面比较成熟，界面上基本能完成全部的配置操作	界面相对较弱，很多配置需要修改配置文件
发展时间更长，对于很多监控场景都有现成的解决方案	发展时间较短，成熟度不及zabbix

5.Prometheus的部署模式

5.1基本高可用模式

基本的 HA 模式只能确保 Promthues 服务的可用性问题，但是不解决 Prometheus Server 之间的数据 一致性问题以及持久化问题(数据丢失后无法恢复)，也无法进行动态的扩展。因此这种部署方式适合监 控规模不大，Promthues Server 也不会频繁发生迁移的情况，并且只需要保存短周期监控数据的场景；

5.2基本高可用+远程存储

在解决了 Promthues 服务可用性的基础上，同时确保了数据的持久化，当 Promthues Server 发生宕 机或者数据丢失的情况下，可以快速的恢复。同时 Promthues Server 可能很好的进行迁移。因此，该 方案适用于用户监控规模不大，但是希望能够将监控数据持久化，同时能够确保 Promthues Server 的可 迁移性的场景；

5.3基本高可用+远程存储+联邦集群方案

Promthues 的性能瓶颈主要在于大量的采集任务，因此用户需要利用 Prometheus 联邦集群的特性，将不同类型的采集任务划分到不同的 Promthues 子服务中，从而实现功能分区

6.Prometheus的四种数据类型

6.1Counter计数器类型

counter用于累计值，数值一直增加，不会减少；重启进程后会被重置；

6.2gauge测量器类型

gauge是常规数值，可变大变小；重启进程后会被重置；

6.3 histogram柱状图

在一段时间范围内对数据进行采样（通常是请求持续时间或响应大小等），并将其计入可配置的存储桶（bucket）中. 后续可通过指定区间筛选样本，也可以统计样本总数，最后一般将数据展示为直方图；对每个采样点值累计和(sum)；对采样点的次数累计和(count)；

如果定义一个度量类型为 Histogram，则 Prometheus 会自动生成三个对应的指标

6.4 summary

对于每个采样点进行统计，并形成分位图。（如：正态分布一样，统计低于 60 分不及格的同学比例，统计低于 80 分的同学比例，统计低于 95 分的同学比例）；统计班上所有同学的总成绩(sum)；统计班上同学的考试总人数(count)

7.Prometheus能监控什么

Databases-数据库、Hardware related-硬件相关、Messaging systems-消息服务、Storage-存储、HTTP-网站服务、APIs 、Logging-日志、Other monitoring systems 、Miscellaneous、Software exposing Prometheus metrics-度量指标；