|利用 Prometheus 监控测试服务器集群实践详解
本文为霍格沃兹测试学院优秀学员的学习和实践总结，想一起系统进阶的同学文末加群交流。
公司有几台测试服务器（由于测试服务器本来性能和线上机器硬件就不一样，所以让运维老师去掉了测试服务器报警），测试团队自己使用 Prometheus
监控几台测试服务器，当出现故障的时候，把报警数据直接发送到企业微信中。
Prometheus 特点介绍
Prometheus（普罗米修斯）是一套开源的监控 & 报警 & 时间序列数据库的组合，起始是由 SoundCloud
公司开发的。随着发展，越来越多公司和组织接受采用 Prometheus，社区也十分活跃，他们便将它独立成开源项目，并且有公司来运作。Google SRE
的书内也曾提到跟他们 BorgMon 监控系统相似的实现是 Prometheus。现在最常见的 Kubernetes 容器管理系统中，通常会搭配
Prometheus 进行监控。
Prometheus 基本原理是通过 HTTP 协议周期性抓取被监控组件的状态，这样做的好处是任意组件只要提供 HTTP
接口就可以接入监控系统，不需要任何斯达克学院测试或者其他的集成过程。这样做非常适合虚拟化环境比如 VM 或者 Docker 。
Prometheus 应该是为数不多的适合 Docker、Mesos、Kubernetes 环境的监控系统之一。
输出被监控组件信息的 HTTP 接口被叫做 exporter 。目前互联网公司常用的组件大部分都有 exporter 可以直接使用，比如
Varnish、Haproxy、Nginx、MySQL、Linux 系统信息
(包括磁盘、内存、CPU、网络等等)，具体支持的源看：https://github.com/prometheus。
与其他监控系统相比，Prometheus 的主要特点是：
- 一个多维数据模型（时间序列由指标名称定义和设置键 / 值尺寸）。
- 非常高效的存储，平均一个采样数据占~3.5bytes 左右，320 万的时间序列，每 30 秒采样，保持 60 天，消耗磁盘大概 228G。
- 一种灵活的查询语言。
- 不依赖分布式存储，单个服务器节点。
- 时间集合通过 HTTP 上的 PULL 模型进行。
- 通过中间网关支持推送时间。
- 通过服务发现或静态配置发现目标。
- 多种模式的图形和仪表板支持。
Prometheus 架构概览
它的服务过程是这样的 Prometheus daemon 负责定时去目标上抓取 metrics(指标) 数据，每个抓取目标需要暴露一个 HTTP
服务的接口给它定时抓取。
Prometheus
支持通过配置文件、文本文件、zookeeper、Consul、DNS SRV lookup 等方式指定抓取目标。支持很多方式的图表可视化，例如十分精美的
Grafana，自带的 Promdash，以及自身提供的模版引擎等等，还提供 HTTP API 的查询方式，自定义所需要的输出。
Alertmanager
Alertmanager 是独立于 Prometheus 的一个组件，可以支持 Prometheus 的查询语句，提供十分灵活的报警方式。
PushGateway：这个组件是支持 Client 主动推送 metrics 到 PushGateway，而 Prometheus 只是定时去
Gateway 上抓取数据。
如果有使用过 statsd 的用户，则会觉得这十分相似，只是 statsd 是直接发送给服务器端，而 Prometheus 主要还是靠进程主动去抓取。
Prometheus 的数据模型
Prometheus 从根本上所有的存储都是按时间序列去实现的，相同的 metrics(指标名称) 和 label(一个或多个标签)
组成一条时间序列，不同的 label 表示不同的时间序列。为了支持一些查询，有时还会临时产生一些时间序列存储。
metrics name&label 指标名称和标签。
每条时间序列是由唯一的” 指标名称” 和一组” 标签（key=value）” 的形式组成。
指标名称 ：一般是给监测对像起一名字，例如 httprequeststotal 这样，它有一些命名规则，可以包字母数字 _
之类的的。通常是以应用名称开头 _ 监测对像 _ 数值类型 _
单位这样。例如：pushtotal、userloginmysqldurationseconds、appmemoryusage_bytes。
标签 ：就是对一条时间序列不同维度的识别了，例如一个 http 请求用的是 POST 还是 GET，它的 endpoint
是什么，这时候就要用标签去标记了。最终形成的标识便是这样了：httprequeststotal{method=”POST”,endpoint=”/api/tracks”}。
记住，针对 httprequeststotal 这个 metrics name 无论是增加标签还是删除标签都会形成一条新的时间序列。
查询语句就可以跟据上面标签的组合来查询聚合结果了。
如果以传统数据库的理解来看这条语句，则可以考虑 httprequeststotal 是表名，标签是字段，而 timestamp 是主键，还有一个
float64 字段是值了。（Prometheus 里面所有值都是按 float64 存储）。
prometheus 四种数据类型
Gauge
Gauge 常规数值，例如 温度变化、内存使用变化。可变大，可变小。重启进程后，会被重置。例如：
memoryusagebytes{host=”master-01″} 100 <
抓取值、memoryusagebytes{host=”master-01″} 30、memoryusagebytes{host=”master-01″}
50、memoryusagebytes{host=”master-01″} 80 < 抓取值。
Histogram
Histogram（直方图）可以理解为柱状图的意思，常用于跟踪事件发生的规模，例如：请求耗时、响应大小。它特别之处是可以对记录的内容进行分组，提供
count 和 sum 全部值的功能。
例如：{小于 10=5 次，小于 20=1 次，小于 30=2 次}，count=7 次，sum=7 次的求和值。
Summary
Summary 和 Histogram 十分相似，常用于跟踪事件发生的规模，例如：请求耗时、响应大小。同样提供 count 和 sum 全部值的功能。
例如：count=7 次，sum=7 次的值求值。
它提供一个 quantiles 的功能，可以按 % 比划分跟踪的结果。例如：quantile 取值 0.95，表示取采样值里面的 95% 数据。
依赖镜像
1. docker pull prom/node-exporter
2.
3. 2. docker pull prom/prometheus
4.
5. 3. docker pull grafana/grafana
6.
7.
8.
部署 prometheus
配置
1. mkdir /opt/prometheus
2.
3. 2. cd /opt/prometheus/
4.
5. 3. vim prometheus.yml
6.
7.
8.
yml 内容
yml 中配置了一个 prometheus 自己和一台 linux 监控
1. global: 2. scrape_interval: 60s 3. evaluation_interval: 60s 4. 5. scrape_configs: 6. - job_name: prometheus 7. static_configs: 8. - targets: ['localhost:9090'] 9. labels: 10. instance: prometheus 11. 12. - job_name: linux 13. static_configs: 14. - targets: ['192.168.91.132:9100'] 15. labels: 16. instance: localhost
启动 prometheus
启动的时候挂载了 prometheus.yml 文件
1. docker run -d \ 2. -p 9090:9090 \ 3. -v /Users/qamac/Documents/script/docker_prometheus/prometheus.yml:/etc/prometheus/prometheus.yml \ 4. prom/prometheus
查看目标机器
1. http://192.168.143.242:9090/targets
2.
3.
4.
如果出现 status 是 down 的情况说明没有连接成功 , 需要检查对应服务是否启动成功及对应端口
出现下图 , 说明配置成功。
查看采集 metrics
点击下面这个接口 , 会跳转到 metrics 页面 , 通过轮训的方式更新数据
1. http://192.168.143.242:9090/metrics
部署 node-exporter
node-exporter 启动后会在服务器上启动一个进程采集数据 ,prometheus 会每隔几秒通过接口获取服务器的 metrics 数据 .
注意本地 mac 启动不能加–net="host"
1. docker run -d -p 9100:9100 \
2.
3. 2. -v "/proc:/host/proc:ro" \
4.
5. 3. -v "/sys:/host/sys:ro" \
6.
7. 4. -v "/:/rootfs:ro" \
8.
9. 5. --net="host" \
10.
11. 6. prom/node-exporter
12.
13.
14.
部署 Grafana
启动 grafana
1. docker run -d -p 3000:3000 grafana
2.
3.
4.
grafana 地址
登录账号密码:admin/admin
1. http://192.168.143.242:3000
2.
3.
4.
grafana 配置
prometheus 配置
配置 prometheus 数据源
grafana 模版
导入 dashboards 模版
1. https://grafana.com/grafana/dashboards/8919
2.
3.
4.
展示
配置多个机器监控 , 需要在每一台机器部署 node-exporter.
配置告警规则
报警规则配置
rules.yml 中配置监控服务的内存、cpu、磁盘告警策略
1. Server: '{{$labels.instance}}' 2. summary: "{{$labels.instance}}: High Memory usage detected" 3. explain: " 内存使用量超过 90%，目前剩余量为：{{ $value }}M" 4. description: "{{$labels.instance}}: Memory usage is above 90% (current value is: {{ $value }})" 5. 6. - alert: CPU 报警 7. expr: (100 - (avg by (instance)(irate(node_cpu_seconds_total{mode="idle"}[5m])) * 100)) > 90 8. for: 2m 9. labels: 10. team: node 11. annotations: 12. Alert_type: CPU 报警 13. Server: '{{$labels.instance}}' 14. explain: "CPU 使用量超过 90%，目前剩余量为：{{ $value }}" 15. summary: "{{$labels.instance}}: High CPU usage detected" 16. description: "{{$labels.instance}}: CPU usage is above 90% (current value is: {{ $value }})" 17. 18. - alert: 磁盘报警 19. expr: 100.0 - 100 * ((node_filesystem_avail_bytes{mountpoint=~"/", device!="rootfs"} / 1000 / 1000 ) / (node_filesystem_size_bytes{mountpoint=~"/", device!="rootfs"} / 1024 / 1024)) > 90 20. for: 2m 21. labels: 22. team: node 23. annotations: 24. Alert_type: 磁盘报警 25. Server: '{{$labels.instance}}' 26. explain: " 磁盘使用量超过 90%，目前剩余量为：{{ $value }}G" 27. summary: "{{$labels.instance}}: High Disk usage detected" 28. description: "{{$labels.instance}}: Disk usage is above 90% (current value is: {{ $value }})" 29. 30. - alert: 服务器下线告警 31. expr: up == 0 32. for: 1m 33. labels: 34. user: admin 35. annotations: 36. summary: "Instance {{ $labels.instance }} down" 37. description: "{{ $labels.instance }} of job {{ $labels.job }} has been down for more than 1 minutes."
加载配置
prometheus.yml 加载 rule_files
1. # Alertmanager configuration 2. alerting: 3. alertmanagers: 4. - static_configs: 5. - targets: ["192.168.1.232:9093"] 6. # - alertmanager:9093 7. 8. 9. # Load rules once and periodically evaluate them according to the global 'evaluation_interval'. 10. rule_files: 11. - "rules.yml"
启动 prometheus
1. docker run -d -p 9090:9090 --name=prometheus1 \
2.
3. 2. -v /Users/qamac/Documents/script/docker_prometheus/prometheus.yml:/etc/prometheus/prometheus.yml \
4.
5. 3. -v /Users/qamac/Documents/script/docker_prometheus/memory_over.yml:/etc/prometheus/rules.yml \
6.
7. 4. prom/prometheus
8.
9.
10.
部署 alertmanager
邮箱配置
可以通过邮件的形式发送告警邮件
1. global:
2.
3. 2. smtp_smarthost: 'smtp.126.com:25' #163 服务器
4.
5. 3. smtp_from: '[email protected]' #发邮件的邮箱
6.
7. 4. smtp_auth_username: '[email protected]' #发邮件的邮箱用户名，也就是你的邮箱
8.
9. 5. smtp_auth_password: 'xxxxx' #发邮件的邮箱密码
10.
11. 6.
12.
13.
14. 7. route:
15.
16. 8. group_by: ['alertname']
17.
18. 9.
19.
20.
21. 10. repeat_interval: 1h
22.
23. 11.
24.
25.
26. 12. receiver: live-monitoring
27.
28. 13.
29.
30.
31. 14. receivers:
32.
33. 15. - name: 'live-monitoring'
34.
35. 16. email_configs:
36.
37. 17. - to: '[email protected]' #收邮件的邮箱
38.
39.
40.
webhook 配置
因为我司用企业微信比较多，再加上平时也不怎么看邮件。所以想自定义一个 webhook 地址，把告警发到企业微信群中。
1. global:
2.
3. 2. resolve_timeout: 5m
4.
5. 3.
6.
7.
8. 4. route:
9.
10. 5. group_by: ['alertname']
11.
12. 6. group_wait: 10s
13.
14. 7. group_interval: 10s
15.
16. 8. repeat_interval: 1h
17.
18. 9. receiver: 'web.hook'
19.
20. 10. receivers:
21.
22. 11. - name: 'web.hook'
23.
24. 12. webhook_configs:
25.
26. 13. - url: 'http://127.0.0.1:5000/send'
27.
28. 14. inhibit_rules:
29.
30. 15. - source_match:
31.
32. 16. severity: 'critical'
33.
34. 17. target_match:
35.
36. 18. severity: 'warning'
37.
38. 19. equal: ['alertname', 'dev', 'instance']
39.
40. 20. ~
41.
42.
43.
启动 alertmanager
1. docker run -d -p 9093:9093 -v /data/docker_alertmanager/simple.yml/:/etc/alertmanager/config.yml --name alertmanager1 prom/alertmanager
2.
3.
4.
alertmanager 的 web 页面
1. http://192.168.1.232:9093/#/status
2.
3.
4.
下图是配置的告警方式
prometheus 中报警模块
1. http://192.168.143.242:9090/alerts
2.
3.
4.
访问上面的地址 , 可以看到已经加载了告警规则
报警的几个状态
- Inactive: 既不是 pending 也不是 firing 的时候状态变为 inactive
- Pending:警报被激活，但是低于配置的持续时间。这里的持续时间即 rule 里的 FOR 字段设置的时间 . 改状态下不发送报警 .
- Firing: 警报已被激活，而且超出设置的持续时间。该状态下发送报警 .
如下图的 for 字段是配置 2 分钟循环 , 第一次触发规则是 Pending 状态 , 如果超过 2 分钟就变成了 Firing 状态 ,
才发送告警
Webhook 服务
我们需要一个 webhook 服务接受报警的消息然后在发给企业微信群中 .
这里我使用 python flask 框架开发 web 服务 .
报警消息的格式
1. {
2.
3. 2. "status": "firing",
4.
5. 3. "labels": {
6.
7. 4. "instance": "localhost",
8.
9. 5. "job": "linux",
10.
11. 6. "user": "admin",
12.
13. 7. "alertname": "NodeMemoryUsage"
14.
15. 8. },
16.
17. 9. "endsAt": "2020-01-06T08:38:59.334190464Z",
18.
19. 10. "generatorURL": "http://13b226ded726:9090/graph?g0.expr=%28node_memory_MemTotal_bytes+-+%28node_memory_MemFree_bytes+%2B+node_memory_Buffers_bytes+%2B+node_memory_Cached_bytes%29%29+%2F+node_memory_MemTotal_bytes+%2A+100+%3E+5&g0.tab=1",
20.
21. 11. "startsAt ": "2020-01-05T15:33:59.334190464Z",
22.
23. 12. "annotations": {
24.
25. 13. "description": "localhost: Memory usage is above 80% (current value is:22.168394749407362)",
26.
27. 14. "summary": "localhost: High Memory usage detected"
28.
29. 15. }
30.
31. 16. }
32.
33.
34.
定义 send 接口
解析响应数据
Dockerfile
这里使用 docker 把服务打包成镜像部署
1. FROM python3.7
2.
3. 2. RUN pip3 install requests && pip3 install flask && pip3 install logzero && pip3 install gunicorn && pip3 install flask_script
4.
5. 3. EXPOSE 5000
6.
7. 4.
8.
9.
10. 5. ENTRYPOINT ["/run.sh"]
11.
12.
13.
企业微信报警
以上，期待与各位同学多交流探讨。
** _
来霍格沃兹测试开发学社，学习更多软件测试与测试开发的进阶技术，知识点涵盖web自动化测试 app自动化测试、接口自动化测试、测试框架、性能测试、安全测试、持续集成/持续交付/DevOps，测试左移、测试右移、精准测试、测试平台开发、测试管理等内容，课程技术涵盖bash、pytest、junit、selenium、appium、postman、requests、httprunner、jmeter、jenkins、docker、k8s、elk、sonarqube、jacoco、jvm-sandbox等相关技术，全面提升测试开发工程师的技术实力
QQ交流群：484590337
公众号 TestingStudio
视频资料领取：https://qrcode.testing-studio.com/f?from=CSDN&url=https://ceshiren.com/t/topic/15844
点击查看更多信息