一、Prometheus是什么
Prometheus中文发音为普罗米修斯，它通过多种数学算法实现强大的监控需求，并且原生支持K8S的服务发现，能监控容器的动态变化。结合Grafana绘出漂亮图形，最终使用alertmanager或Grafana实现报警。它与其他监控相比有以下主要优势：数据格式是Key/Value形式，简单、速度快；监控数据的精细程度是绝对的领先，达到秒级（但正因为数据采集精度高，对磁盘消耗大，存在性能瓶颈，而且不支持集群，但可以通过联邦能力进行扩展）；不依赖分布式存储，数据直接保存在本地，可以不需要额外的数据库配置。但是如果对历史数据有较高要求，可以结合OpenTSDB；周边插件丰富，如果对监控要求不是特别严格的话，默认的几个成品插件已经足够使用；本身基于数学计算模型，有大量的函数可用，可以实现很复杂的监控（所以学习成本高，需要有一定数学思维，独有的数学命令行很难入门）；可以嵌入很多开源工具的内部去进行监控，数据更可信。
二、Prometheus的主要组件
1、服务端
Prometheus服务端以一个进程方式启动，如果不考虑参数和后台运行的话，只需要解压安装包之后运行./prometheus脚本即可启动，程序默认监听在9090端口。每次采集到的数据叫做metrics。这些采集到的数据会先存放在内存中，然后定期再写入硬盘，如果服务重新启动的话会将硬盘数据写回到内存中，所以对内存有一定消耗。Prometheus不需要重视历史数据，所以默认只会保留15天的数据。
2、客户端
Prometheus客户端分为pull和push两种方式。如果是pull形式的话则是服务端主动向客户端拉取数据，这样需要客户端上安装exporters（导出器）作为守护进程，官网上也提供了很多exporters可以下载使用，比如使用最多的node_exporters，几乎把系统自身相关数据全部采集了，非常全面，node_exporter默认监听9100端口。
如果是push形式的话客户端需要安装pushgateway插件，然后运需要运维人员用脚本把监控数据组织成键值形式提交给pushgateway，再由它提交给服务端。它适合于现有exporters无法满足需求时，自己灵活定制。
3、metrics主要数据类型
· Gauges：最简单、使用最多的指标，获取一个返回值，这个返回值没有变化规律，不能肯定它一定是增长或是减少的状态，采集回来是多少就是多少。比如硬盘容量、CPU内存使用率都适合使用Gauges数据类型。
· Counters：计数器。数据从0开始累计，理想状态下应该是永远增长或者是不变。适合统计机器开机时间、HTTP访问量
· Histograms：和summary一样属于高级指标，用于统计数据的分布情况。比如最小值、最大值、中间值。这个类型不太好理解，比如说统计一天的日志，大部分用户响应时间都是正常的，只有少量用户异常，如果这个时候取平均值的话，这少量用户的异常情况就会被掩盖过去，而Histograms可以分别统计出全部用户的响应时间，比如0-1秒的用户有多少、1-2秒的用户有多少（其实有点像Kibana）
三、Prometheus服务端安装部署
1、到官网http://prometheus.io下载安装包
2、解压安装包后获得主配置文件prometheus.yml，下面介绍一些需要修改的主要配置，标签部分内容不是必须的，可以了解
03 |
scrape_interval: 15s #采集数据间隔，默认15秒。该配置可配置在每个job_name中 |
04 |
evaluation_interval: 15s #监控规则评估频率，比如设置了当内存使用大于70%发出报警的规则，然后每15秒来执行一次这个规则 |
15 |
- job_name: 'prometheus-server' #定义一个监控组，其下可以有多个实例配置 |
17 |
- targets: ['localhost:9090'] #节点的地址，可以写多个地址 |
19 |
- job_name: 'www_server' #定义另一个监控组 |
21 |
- targets: ['10.160.2.107:9100','192.168.1.100:9100'] #组内多个被监控主机 |
22 |
labels: #自定义标签，可以通过标签对查询数据进行分组管理 |
23 |
idc:beijing #将上面2个主机打上idc标签，值为beijing |
29 |
# - job_name: 'mysql_node' |
31 |
# - targets: ['10.160.2.110:9100','192.168.1.111:9100'] |
32 |
# metric_relable_configs: #通过正则重命名标签 |
33 |
# - action: replace #replace替换是默认动作。此外还有keep（只参加匹配标签的实例）、drop（不采集匹配正则的实例）、labelkeeplabeldrop(对标签进行过滤处理而非实例)等动作 |
34 |
# source_labels: ['job'] #原标签，job是默认就会产生的标签，这里job标签的值是node |
35 |
# regex: (.*) #正则匹配，这里匹配job标签内的内容，也就是node |
36 |
# replacement: beijing #替换成什么内容，如果写$1就是将正则里的内容拿过来 |
37 |
# target_label: idc #把替换到的内容赋值给idc标签 |
38 |
# - action: labeldrop #删除标签 |
39 |
# regex: job #把原有的job标签删除不显示 |
3、在运行./prometheus脚本之前可以进行一次配置文件检查
1 |
protool check config prometheus.yml |
4、配置文件检查没有问题后就可以启动服务了，服务默认监听在9090端口。如果不加任何参数，监控数据会存放在/usr/local/prometheus/data下，那些一长串一长串的文件夹都是已经写入到磁盘中的历史数据。写入磁盘前的数据是放在内存中的，如果发生断电等情况就会使用硬盘中的数据进行恢复。下面是一些Prometheus脚本常用选项
1 |
prometheus --config.file="/usr/local/prometheus-2.16.0.linux-amd64/prometheus.yml" --web.listen-address="0.0.0.0:9090" --storage.tsdb.path="/data/prometheus" --storage.tsdb.retention.time=15d --web.enable-lifecycle & |
3 |
# --config.file="/usr/local/prometheus/prometheus.yml" #指定配置文件路径 |
4 |
# --web.listen-address="0.0.0.0:9090" #指定服务端口 |
5 |
# --storage.tsdb.path="/data/prometheus" #指定数据存储路径 |
6 |
# --storage.tsdb.retention.time=15d #数据保留时间 |
7 |
# --collector.systemd #开启systemd的服务状态监控，开启后在WEB上可以看到多出相关监控项 |
8 |
# --collector.systemd.unit-whitelist=(sshd|nginx).service #对systemd具体要监控的服务名 |
9 |
# --web.enable-lifecycle #开启热加载配置 |
两种热加载方式，一个是直接用kill命令发送HUP信号，一个是开启web.enable-lifecycle选项后使用curl命令
1 |
kill -HUP `pidof prometheus` |
2 |
curl -X POST http://localhost:9090/-/reload |
5、通过浏览器访问9090端口可以进入到Prometheus WEB管理界面。如下图就是查看已经监控的节点列表
6、在进行数据查询时有一个统一的查询语法，根据metric_name指标名称和label标签进行过滤和聚合
1 |
#语法：<metric name>{<labelname>=<lablevalue>,...}[time] |
2 |
http_requests_total{environment=~"staging|testing|development",method!="GET"} |
3 |
# labelname=value #选择标签满足表达式定义的时间序列 |
4 |
# labelname!=value #根据标签匹配排除时间序列 |
5 |
# labelname=~regx #选择标签符合正则表达式定义的时间序列 |
6 |
# labelname!~regx #排除符合正则表达式定义的时间序列 |
8 |
http_request_total{}[5m] #选择最近5分钟内的所有样本数据，还支持s,h,d,w,y等单位 |
9 |
http_request_total{}[1d] offset 1d #区间向量表达式是以当前时间为基准，如果想查询昨天一天的区间数据可以使用位移操作offset |
