我们在日常测试工作中,除了在产品开发过程中需要进行测试保证质量,在产品上线后,对产品各个指标的实时监控也是保证产品质量的重要环节。最近在项目中调研并使用了开源监控系统框架 Prometheus,本文将主要介绍一下 Prometheus 监控系统的基础知识,并且将在本地部署并运行一个 Prometheus Server 实例,通过 Node Exporter 采集当前主机的系统资源使用情况, 并通过 Grafana 创建一个简单的可视化仪表盘来可视化监控数据。
Prometheus 是一套开源的系统监控报警框架。它启发于 Google 的 borgmon 监控系统,由工作在 SoundCloud 的 google 前员工在 2012 年创建,作为社区开源项目进行开发,并于 2015 年正式发布。2016 年,Prometheus 正式加入 Cloud Native Computing Foundation,成为受欢迎度仅次于 Kubernetes 的项目。
作为新一代的监控框架,Prometheus 具有以下特点:
强大的多维度数据模型:
1.时间序列数据通过 metric 名和键值对来区分。
2.所有的 metrics 都可以设置任意的多维标签。
3.数据模型更随意,不需要刻意设置为以点分隔的字符串。
4.可以对数据模型进行聚合,切割和切片操作。
5.支持双精度浮点类型,标签可以设为全 unicode。
① 灵活而强大的查询语句(PromQL):在同一个查询语句,可以对多个 metrics 进行乘法、加法、连接、取分数位等操作。
② 易于管理: Prometheus server 是一个单独的二进制文件,可直接在本地工作,不依赖于分布式存储。
③ 高效:平均每个采样点仅占 3.5 bytes,且一个 Prometheus server 可以处理数百万的 metrics。
④ 使用 pull 模式采集时间序列数据,这样不仅有利于本机测试而且可以避免有问题的服务器推送坏的 metrics。
⑤ 可以采用 push gateway 的方式把时间序列数据推送至 Prometheus server 端。
⑥ 可以通过服务发现或者静态配置去获取监控的 targets。
⑦ 有多种可视化图形界面。
⑧ 易于伸缩。
1.Prometheus 组成及架构
Prometheus 生态圈中包含了多个组件,其中许多组件是可选的:
① Prometheus Server: 用于收集和存储时间序列数据。
② Client Library: 客户端库,为需要监控的服务生成相应的 metrics 并暴露给 Prometheus server。当 Prometheus server 来 pull 时,直接返回实时状态的 metrics。
③ Push Gateway: 主要用于短期的 jobs。由于这类 jobs 存在时间较短,可能在 Prometheus 来 pull 之前就消失了。为此,这次 jobs 可以直接向 Prometheus server 端推送它们的 metrics。这种方式主要用于服务层面的 metrics,对于机器层面的 metrices,需要使用 node exporter。
① Exporters: 用于暴露已有的第三方服务的 metrics 给 Prometheus。
② Alertmanager: 从 Prometheus server 端接收到 alerts 后,会进行去除重复数据,分组,并路由到对方的接受方式,发出报警。常见的接收方式有:电子邮件,pagerduty,OpsGenie, webhook 等。
下图是 Prometheus 官网上给出的架构图:
2.数据模型
Prometheus 中存储的数据为时间序列,是由 metric 的名字和一系列的标签(键值对)唯一标识的,不同的标签则代表不同的时间序列。
① metric 名字:该名字应该具有语义,一般用于表示 metric 的功能,例如:http_requests_total, 表示 http 请求的总数。其中,metric 名字由 ASCII 字符,数字,下划线,以及冒号组成,且必须满足正则表达式 [a-zA-Z_:][a-zA-Z0-9_:]。
② 标签:使同一个时间序列有了不同维度的识别。例如 http_requests_total{method="Get"} 表示所有 http 请求中的 Get 请求。当 method="post" 时,则为新的一个 metric。标签中的键由 ASCII 字符,数字,以及下划线组成,且必须满足正则表达式 [a-zA-Z_:][a-zA-Z0-9_:]。
③ 样本:实际的时间序列,每个序列包括一个 float64 的值和一个毫秒级的时间戳。
④ 格式:{=, …},例如:http_requests_total{method="POST",endpoint="/api/tracks"}。
3.四种 Metric 类型
Prometheus 客户端库主要提供四种主要的 metric 类型:
Counter
① 一种累加的 metric,典型的应用如:请求的个数,结束的任务数,出现的错误数等等。
例如,查询 http_requests_total{method="get", job="Prometheus", handler="query"} 返回 8,10 秒后,再次查询,则返回 14。
Gauge
① 一种常规的 metric,典型的应用如:温度,运行的 goroutines 的个数。
② 可以任意加减。
例如:go_goroutines{instance="172.17.0.2", job="Prometheus"} 返回值 147,10 秒后返回 124。
Histogram
① 可以理解为柱状图,典型的应用如:请求持续时间,响应大小。
② 可以对观察结果采样,分组及统计。
例如,查询 http_request_duration_microseconds_sum{job="Prometheus", handler="query"} 时,返回结果如下:
Summary
① 类似于 Histogram, 典型的应用如:请求持续时间,响应大小。
② 提供观测值的 count 和 sum 功能。
③ 提供百分位的功能,即可以按百分比划分跟踪结果。
4.instance 和 jobs
instance: 一个单独 scrape 的目标,一般对应于一个进程。
jobs: 一组同种类型的 instances(主要用于保证可扩展性和可靠性)
介绍完 Prometheus 的基本概念后,我们来实际安装部署一个 Prometheusserver 并对当前主机进行监控实践。
Prometheus 基于 Golang 编写,编译后的软件包,不依赖于任何的第三方依赖。用户只需要下载对应平台的二进制包,解压并且添加基本的配置即可正常启动 Prometheus Server。
对于非 Docker 用户,可以从https://prometheus.io/download/Prometheus找到最新版本的 Sevrer 软件包,对于 Docker 用户,直接使用 Prometheus 的镜像即可启动 Prometheus Server。
启动完成后,可以通过http://localhost:9090Prometheus 的 UI 界面:访问
使用 Node Exporter 采集主机数据和可视化
安装 Node Exporter
在 Prometheus 的架构设计中,Prometheus Server 并不直接服务监控特定的目标,其主要任务负责数据的收集,存储并且对外提供数据查询支持。因此为了能够能够监控到某些东西,如主机的 CPU 使用率,我们需要使用到 Exporter。Prometheus 周期性的从 Exporter 暴露的 HTTP 服务地址(通常是/metrics)拉取监控样本数据。
从上面的描述中可以看出 Exporter 可以是一个相对开放的概念,其可以是一个独立运行的程序独立于监控目标以外,也可以是直接内置在监控目标中。只要能够向 Prometheus 提供标准格式的监控样本数据即可。
这里为了能够采集到主机的运行指标如 CPU, 内存,磁盘等信息。我们可以使用 Node Exporter。
Node Exporter 同样采用 Golang 编写,并且不存在任何的第三方依赖,只需要下载,解压即可运行。可以从https://prometheus.io/download/node获取最新的 exporter 版本的二进制包。
curl -OL https://github.com/prometheus/node_exporter/releases/download/v0.15.2/node_exporter-0.15.2.darwin-amd64.tar.gz
tar -xzf node_exporter-0.15.2.darwin-amd64.tar.gz
运行 node exporter:
cd node_exporter-0.15.2.darwin-amd64
cp node_exporter-0.15.2.darwin-amd64/node_exporter /usr/local/bin/node_exporter
启动成功后,可以看到以下输出:
INFO[0000] Listening on :9100
source="node_exporter.go:76"
访问http://localhost:9100/可以看到以下页面:
访问http://localhost:9100/metricsnode,可以看到当前 exporter 获取到的当前主机的所有监控数据,如下所示:
从 Node Exporter 收集监控数据
为了能够让 Prometheus Server 能够从当前 node exporter 获取到监控数据,这里需要修改 Prometheus 配置文件。编辑 prometheus.yml 并在 scrape_configs 节点下添加以下内容:
重新启动 Prometheus Server
访问http://localhost:9090Prometheus,进入到 Server。如果输入 “up” 并且点击执行按钮以后,可以看到如下结果:
Prometheus UI 提供了快速验证 PromQL 以及临时可视化支持的能力,而在大多数场景下引入监控系统通常还需要构建可以长期使用的监控数据可视化面板(Dashboard)。这时用户可以考虑使用第三方的可视化工具如 Grafana,Grafana 是一个开源的可视化平台,并且提供了对 Prometheus 的完整支持。
我们通过 docker 安装并启动 grafana:
docker run -d -p 3000:3000 grafana/grafana
访问http://localhost:3000Grafana 的界面中,默认情况下使用账户 admin/admin 进行登录。在 Grafana 首页中显示默认的使用向导,包括:安装、添加数据源、创建 Dashboard、邀请成员、以及安装应用和插件就可以进入到
这里将添加 Prometheus 作为默认的数据源,如下图所示,指定数据源类型为 Prometheus 并且设置 Prometheus 的访问地址即可,在配置正确的情况下点击 “Add” 按钮,会提示连接成功的信息:
在完成数据源的添加之后就可以在 Grafana 中创建我们可视化 Dashboard 了。Grafana 提供了对 PromQL 的完整支持,如下所示,通过 Grafana 添加 Dashboard 并且为该 Dashboard 添加一个类型为 “Graph” 的面板。并在该面板的 “Metrics” 选项下通过 PromQL 查询需要可视化的数据:
通过上面的介绍,我们初步了解了 Prometheus 监控系统的基本概念和使用方法,可以为读者在选择监控解决方案时,提供一定的参考。同时我们介绍了 Prometheus 的生态以及核心能力,在本地使用 Prometheus 和 NodeExporter 搭建了一个主机监控的环境,并且对数据进行了聚合以及可视化,相信读者通过本文能够对 Prometheus 有一个直观的认识。后续可以对 Prometheus 的 PromQL 查询语句进行深入探索,将监控指标与实际业务进行关联,甚至可以通过预测模型的提取,能够帮助用户将传统的面向结果转变为面向预测的方式。从而更有效的为业务和系统的正常运行保驾护航。