prometheus | Final

type

status

date

slug

summary

category

icon

password

开源系统监控和报警工具集合，由SoundCloud创建

1、prometheus特性

基于time series时间序列模型

时间序列是一系列有序的数据，通常是等时间间隔的采样数据

基于K/V的数据模型（键/值概念）

最大的好处就是数据格式简单、速度快、易维护开发

采样数据查询，完全基于数学运算，并提供专有的查询console

此特点很独特，如(增量(A) +增量(B) )/总增量(C) >固定百分比

采用http pull/push两种对应的数据采集传输方式

开源，且已有大量的社区成品插件 prometheus.io

push方法非常灵活，此种采集方法几乎任何形式的数据都可以实现

本身自带图形调试，虽不能与grafana相比，但平时可帮助运维做调试

精细数据采样

多数开源监控，一般采样精确到半分钟或一分钟左右

商品化监控，为了缩小数据存储成本，有的甚至5分钟采样最小间隔

prometheus理论上可达到每秒采集，且可自行定制频率（并不推荐，这样采集数据会很大）

2、prometheus目前不足之处

不支持集群化

被监控集群过大，本向性能有一定的瓶颈

偶尔发生数据丢失，在2.0版本之前，当IO和CPU占用很高时会发生数据丢失，在2.0版本之后已经彻底解决

中文资料较少，中文支持不太友好

3、运维要求

操作系统深入扎实知识，比较底层

数学思维，数学公式组成，四则运算、算法 → 微积分、代数、数论

对监控经验有较高要求，需对监控项定制，较细

4、图形展示

5、配置展示

6、targets 服务端有多少个被监控点运行

7、运行框架

prometheues采用time-series时间序列的方式以一种自定义的格式存储在磁盘上

prometheues本地time-series数据库以每两小时为间隔来分block块存储，每个块又分多个chunk文件，chunk文件是用来存放采集过来的TS数据，metadata和索引文件Index

index文件对metrics（prometheus一次K/V采集数据称metric）和labels标签进行索引之后存储在chunk中，chunk是作为存储的基本单位，index and metadata是作为子集

prometheus平时将采集的数据先存放在内存中，用于加快搜索和访问，对内存有一定的消耗，类似缓存

prometheus有一种保护机制称WAL，数据定期存入硬盘以chunk来表示，并在重启时，用以恢复进入内存

pull:指的是客户端(被监控机器)先安装各类已有exporters(由社区组织或企业开发的监控客户端插件)在系统上之后, exporters以守护进程的模式运行并开始采集数据 exporter 本身也是一个http_server可以对http请求作出响应返回数据

prometheus 用 pull 这种主动拉的方式(HTTP get) 去访问每个节点上exporter并采样回需要的数据

指的是在客户端(或者服务端)安装这个官方提供的pushgateway插件然后,使用我们运维自行开发的各种脚本把监控数据组织成k/v的形式metrics形式发送给pushgateway之后 pushgatewayg再推送给prometheus 这种是一种被动的数据采集模式

gauges 数据不确定性，上升下降

counters 数据持平一直上升

histogram 统计监控中某个数据占用百分比是多少

node_exporter会将LINUX系统和系统相关自身监控数据

pushgateway，本身是http服务器

通过定制脚本抓取自己想要的监控数据，推送到pushgateway，以POST发送给HTTP

exporter 由于数据类型采集量大，大部分数据一般使用不到，而用pushgateway定义一项数据，某一种数据时，可以节省资源

自定义pushgateway脚本远比开发一个全新的exporter简单，exporter需要使用真正的编程语言，shell脚本是不可以的，需了解prometheus编程格式才可以制作

1、修改时区

2、同时时间

3、下载prometheus

Download | Prometheus

We provide precompiled binaries and Docker images for most officially maintained Prometheus components. If a component is not listed here, check the respective repository on Github for further instructions. There is also a constantly growing number of independently maintained exporters listed at Exporters and integrations. The Prometheus monitoring system and time series database.

https://prometheus.io/download/

4、启动prometheus服务

5、配置说明

6、node_exporter

Download | Prometheus

https://prometheus.io/download/#node_exporter

7、启动node_exporter

8、使用prometheus查看

8、查看cpu使用率

idle 空间时间

所有时间总和

CPU的使⽤率 = （所有⾮空闲状态的CPU使⽤时间总和）/ （所有状态CPU时间的总和）

CPU被使⽤在⽤户态的时间⼀共是 8分钟 CPU被使⽤在内核态的时间⼀共是 1.5分钟 CPU被使⽤在IO等待状态的时间⼀共是 0.5分钟 CPU被使⽤在Idle（空闲状态）的时间⼀共是 20分钟 (idle空闲状态的CPU时间其实就是CPU处于没事⼉⼲的时间) CPU被使⽤在其他⼏个状态的时间是0

计算30分钟CPU使用率

(user(8mins) + sys(1.5mins) + iowa(0.5min) + 0 + 0 + 0 + 0 ) /(30mins) = 10分钟 / 30分钟 = 30%

换一种思路

空闲时间/总时间=空闲CPU比例

idle(20mins) / (30mins) => 70%

100%-70%=30%

若使用方法1算出1分钟内CPU总平均时间，没办法精确计算某一分钟内平均值

node_exporter

八种CPU状态 → 每个核心都可抓取

在运维实际情况当中，并不太关注每一个CPU核表现如何，一般只需知道CPU表现如何

每个CPU核心单独监控曲线图意义不是很大，若CPU核心太多，图看起来过于混乱

sum()函数，加所有的VALUE加起来作运算

sum(increase(node_cpu_seconds_total[1m])) 获取了 CPU总使⽤时间在1分钟内的增量

CPU计算公式拆分

1、选择key，直接输出没有意义

node_cpu_seconds_total

2、将idle空间的CPU时间和全部CPU时间计算出来

node_cpu_seconds_total{mode="idle"}

3、使用increase将⼀分钟的增量的CPU时间给取出来

increase 函数在promethes中，是⽤来针对Counter 这种持续增长的数值，截取其中⼀段时间的增量

increase(node_cpu_seconds_total{mode="idle"}[1m])

4、使⽤ sum() 再包⼀层把所有核数值加合

sum(increase(node_cpu_seconds_total{mode="idle"}[1m]))

5、此是会发现采集计算的是多台服务器的监控数据，由sum函数原因导致的

sum()函数其实默认状况下是把所有数据不管是什么内容全部进⾏整合在一起

不单单是将每一台机器多个核心加一起，而是把所有机器的CPU加一起，变成服务器集群的总CPU平均值

如何解决此类问题

6、引用新函数 by (instance) 可以把 sum加合到⼀起的数值按照指定的⼀个⽅式进⾏⼀层的拆分

instance代表的是机器名

sum(increase(node_cpu_seconds_total{mode="idle"}[1m])) by(instance)

单台服务器CPU空闲时间 1分钟增量

sum(increase(node_cpu_seconds_total{mode="idle"}[1m])) by(instance)

单台服务CPU所有时间 1分钟增量

sum(increase(node_cpu_seconds_total[1m])) by(instance)

计算CPU空闲1分钟百分比

sum(increase(node_cpu_seconds_total{mode="idle"}[1m])) by(instance) / sum(increase(node_cpu_seconds_total[1m])) by(instance)

计算CPU空闲1分钟的百分比，以百分比的形式展现（⽤ 1 去减掉整个上⾯的公式再 * 100）

(1-(sum(increase(node_cpu_seconds_total{mode="idle"}[1m])) by(instance) / sum(increase(node_cpu_seconds_total[1m])) by(instance)))*100

以上面的思路，计算其他CPU类型的使用率，mode有8种，根据mode类型计算

(1-(sum(increase(node_cpu_seconds_total{mode="system"}[1m])) by(instance) / sum(increase(node_cpu_seconds_total[1m])) by(instance)))*100

(1-(sum(increase(node_cpu_seconds_total{mode="user"}[1m])) by(instance) / sum(increase(node_cpu_seconds_total[1m])) by(instance)))*100

(1-(sum(increase(node_cpu_seconds_total{mode="iowait"}[1m])) by(instance) / sum(increase(node_cpu_seconds_total[1m])) by(instance)))*100

prometheus命令行扩展

自定义一个key

采集数据使用node_exporter或自行开发脚本采集，默认都会提供几项标签

⾃⾏定义并且使⽤ bash 脚本 + pushgateway的⽅法推送到 prometheus server采集

rate函数

专门搭建counter数据类型使用

按设置一个时间段，取counter这个时间段中的平均每秒增量

建议，以后使用任何counter数据类型时，其他先不要做，先加上一个rate()或者increase()

细化，按⽹络接收字节数示例解释

从 23:44开始到 23:45 ⽐如累积量从440011229804456 到了 -> 440011229805456 1分钟内增加了 1000bytes （假设）

从 23:45开始到 23:50 ⽐如累积量从440011229805456 到了 -> 440011229810456

5分钟内增加了 5000bytes（假设）

使用rate(.[1m])之后，1000/60=~16

1000bytes 除以 1m*60秒， =～16bytes/s

那么5分钟也这样计算，也会得到16

两种不同的公式，结果一样，图形会不一样？

当然在实际应用中，不可能这么平均

取1分钟会更细致，更精确，若取5分钟会将5分钟时间内进行平均化，不会太突出

rate(node_network_receive_bytes_total[5m])

那么如何选择实际中取值，根据实现情况

increase函数

increase函数其实和rate的概念及使用方法非常相似

rate是取一段时间增量的平均每秒数量

increase则是取一段时间增量的总量

increase(node_network_receive_bytes_total[1m]) 取的是 1分钟内的增量总量

rate(node_network_receive_bytes_total[1m]) 取的是 1分钟内的增量除以 60秒每秒数量

可以取示例进行计算 rate的值*60 =~ increase

监控获取采集数据源时，如何选择哪种函数合适

频率如5m时，按rate取值，形成图形会有断点，那么选择increase较合适

采集数据不频繁时选择increase较合适

若精确使用rate，如cpu、内存、IO、网络流量，推荐使用rate

sum函数

sum() 的后⾯加上 by (instance) 对机器进行选择，默认是所有

若需要对集群总量输出，比如将10台WEB服务器定义一个集群名称，6台数据库定义一个集群名称

sum() by (cluster_name) ，默认node_exporter没办法提供cluster_name标签，仅能按照不同的机器名去划分

topk函数

取前几位最高值

支持Gauge数据类型和Counter类型数据使用

topk(3,rate(node_network_receive_bytes_total[5m])) by (interval)

数字3表示取前3位

count函数

输出条目数

一般用于模糊监控判断

找出当前（或者历史的）当TCP等待数⼤于200的机器数量

⽐如说企业中有100台服务器，那么当只有10台服务器CPU⾼于80%的时候这个时候不需要报警但是当符合80%CPU的服务器数量超过 30台的时候那么就会触发报警 count()

count(count_netstat_wait_connections > 200)

prometheus启动参数

历史数据会生成随机字符串目录名进行存放，近期数据实际是保留在内存中

近期数据会存在左wal目录中，防止突然断电或者重启，恢复内存中的数据

使用prometheus运行终端查询生成的图形是临时的，关闭浏览器则会自动销毁，需配置ganfana

pushgateway

是一种被动采集监控数据方式，并不是exporter主动获取，是prometheus获取监控数据的插件

Download | Prometheus

https://prometheus.io/download/#pushgateway

优势

pushgateway这种自定义的采集方式非常的快速而且极其灵活几乎不收到任何约束

劣势

pushgateway会形成一个单点瓶颈，假设多个脚本同时运行发送给pushgateway进程，若进程没了，那么监控数据会丢失（服务器不宕机，实际运行很稳定，就算有太多的脚本同时发送给pushgateway，接收数据会变慢，目前没有丢失的情况，比exporter稳定，exporters开发较复杂，越简单越稳定）

pushgateway并不能对发送过来的脚本采集数据进行智能判断，若脚本处理有问题，pushgateway也会接收并发送给prometheus（体现脚本能力，细心点，推荐使用bash，开发快较简单）

exporters

编写exporte流程

1、自身是HTTP服务器可以响应从外发过来的HTTP GET请求

2、自身需要运行在后台,并可以定期触发抓取本地的监控数据

3、返回给prometheus_server的内容是需要符合 prometheus规定的metrics类型(Key-Value)

4、返回数据类型，整数或者浮点数，不被别字符串

grafana

图形绘制

报警

一般用户态 CPU使用率较高

内存使用率