利用 Prometheus 监控测试服务器集群实践详解（精心讲解）

公司有几台测试服务器（由于测试服务器本来性能和线上机器硬件就不一样，所以让运维老师去掉了测试服务器报警），测试团队自己使用 Prometheus 监控几台测试服务器，当出现故障的时候，把报警数据直接发送到企业微信中。

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% 数据。

依赖镜像

部署 prometheus

配置

yml 内容

yml 中配置了一个 prometheus 自己和一台 linux 监控

启动 prometheus

启动的时候挂载了 prometheus.yml 文件

查看目标机器

如果出现 status 是 down 的情况说明没有连接成功 , 需要检查对应服务是否启动成功及对应端口

出现下图 , 说明配置成功。

查看采集 metrics

点击下面这个接口 , 会跳转到 metrics 页面 , 通过轮训的方式更新数据

部署 node-exporter

node-exporter 启动后会在服务器上启动一个进程采集数据 ,prometheus 会每隔几秒通过接口获取服务器的 metrics 数据 .

注意本地 mac 启动不能加--net="host"

部署 Grafana

启动 grafana

grafana 地址

登录账号密码:admin/admin

grafana 配置

prometheus 配置

配置 prometheus 数据源

grafana 模版

导入 dashboards 模版

展示

配置多个机器监控 , 需要在每一台机器部署 node-exporter.

配置告警规则

报警规则配置

rules.yml 中配置监控服务的内存、cpu、磁盘告警策略

Server: '{{$labels.instance}}'
    summary: "{{$labels.instance}}: High Memory usage detected"
    explain: " 内存使用量超过 90%，目前剩余量为：{{ $value }}M"
    description: "{{$labels.instance}}: Memory usage is above 90% (current value is: {{ $value }})"

- alert: CPU 报警
  expr: (100 - (avg by (instance)(irate(node_cpu_seconds_total{mode="idle"}[5m])) * 100)) > 90
for: 2m
  labels:
    team: node
  annotations:
Alert_type: CPU 报警
Server: '{{$labels.instance}}'
    explain: "CPU 使用量超过 90%，目前剩余量为：{{ $value }}"
    summary: "{{$labels.instance}}: High CPU usage detected"
    description: "{{$labels.instance}}: CPU usage is above 90% (current value is: {{ $value }})"

- alert: 磁盘报警
  expr: 100.0 - 100 * ((node_filesystem_avail_bytes{mountpoint=~"/", device!="rootfs"} / 1000 / 1000 ) / (node_filesystem_size_bytes{mountpoint=~"/", device!="rootfs"} / 1024 / 1024)) > 90
for: 2m
  labels:
    team: node
  annotations:
Alert_type: 磁盘报警
Server: '{{$labels.instance}}'
    explain: " 磁盘使用量超过 90%，目前剩余量为：{{ $value }}G"
    summary: "{{$labels.instance}}: High Disk usage detected"
    description: "{{$labels.instance}}: Disk usage is above 90% (current value is: {{ $value }})"

- alert: 服务器下线告警
    expr: up == 0
for: 1m
    labels:
      user: admin
    annotations:
      summary: "Instance {{ $labels.instance }} down"
      description: "{{ $labels.instance }} of job {{ $labels.job }} has been down for more than 1 minutes."