实战 Prometheus 搭建监控系统

前言：Prometheus已经成为了事实上的监控标准，本篇文章是根据参考书籍《Prometheus监控技术与实践》、《深入浅出Prometheus》两本书籍的介绍搭建普罗米修斯系统。
参考书籍《Prometheus监控技术与实践》、《深入浅出Prometheus》
链接: https://pan.baidu.com/s/1qmdi… 提取码: n82k
https://pan.baidu.com/s/1pM7_… 提取码: 6eiw

：Prometheus已经成为了事实上的监控标准。 是一款基于时序数据库的开源监控告警系统，说起 Prometheus 则不得不提 SoundCloud，这是一个在线音乐分享的平台，类似于做视频分享的 YouTube，由于他们在微服务架构的道路上越走越远，出现了成百上千的服务，使用传统的监控系统 StatsD 和 Graphite 存在大量的局限性，于是他们在 2012 年开始着手开发一套全新的监控系统。Prometheus 的原作者是 Matt T. Proud，他也是在 2012 年加入 SoundCloud 的，实际上，在加入 SoundCloud 之前，Matt 一直就职于 Google，他从 Google 的集群管理器 Borg 和它的监控系统 Borgmon 中获取灵感，开发了开源的监控系统 Prometheus，和 Google 的很多项目一样，使用的编程语言是 Go。

很显然，Prometheus 作为一个微服务架构监控系统的解决方案，它和容器也脱不开关系。早在 2006 年 8 月 9 日，Eric Schmidt 在搜索引擎大会上首次提出了云计算（Cloud Computing）的概念，在之后的十几年里，云计算的发展势如破竹。在 2013 年，Pivotal 的 Matt Stine 又提出了云原生（Cloud Native）的概念，云原生由微服务架构、DevOps 和以容器为代表的敏捷基础架构组成，帮助企业快速、持续、可靠、规模化地交付软件。为了统一云计算接口和相关标准，2015 年 7 月，隶属于 Linux 基金会的 云原生计算基金会（CNCF，Cloud Native Computing Foundation） 应运而生。第一个加入 CNCF 的项目是 Google 的 Kubernetes，而 Prometheus 是第二个加入的（2016 年）。

目前 Prometheus 已经广泛用于 Kubernetes 集群的监控系统中，对 Prometheus 的历史感兴趣的同学可以看看 SoundCloud 的工程师 Tobias Schmidt 在 2016 年的 PromCon 大会上的演讲：The History of Prometheus at SoundCloud 。

一、Prometheus 概述
我们在 SoundCloud 的官方博客中可以找到一篇关于他们为什么需要新开发一个监控系统的文章 Prometheus: Monitoring at SoundCloud，在这篇文章中，他们介绍到，他们需要的监控系统必须满足下面四个特性：

A multi-dimensional data model, so that data can be sliced and diced at will, along dimensions like instance, service, endpoint, and method.
Operational simplicity, so that you can spin up a monitoring server where and when you want, even on your local workstation, without setting up a distributed storage backend or reconfiguring the world.
Scalable data collection and decentralized architecture, so that you can reliably monitor the many instances of your services, and independent teams can set up independent monitoring servers.
Finally, a powerful query language that leverages the data model for meaningful alerting (including easy silencing) and graphing (for dashboards and for ad-hoc exploration).
简单来说，就是下面四个特性：

多维度数据模型
方便的部署和维护
灵活的数据采集
强大的查询语言
实际上，多维度数据模型和强大的查询语言这两个特性，正是时序数据库所要求的，所以 Prometheus 不仅仅是一个监控系统，同时也是一个时序数据库。那为什么 Prometheus 不直接使用现有的时序数据库作为后端存储呢？这是因为 SoundCloud 不仅希望他们的监控系统有着时序数据库的特点，而且还需要部署和维护非常方便。纵观比较流行的时序数据库（参见下面的附录），他们要么组件太多，要么外部依赖繁重，比如：Druid 有 Historical、MiddleManager、Broker、Coordinator、Overlord、Router 一堆的组件，而且还依赖于 ZooKeeper、Deep storage（HDFS 或 S3 等），Metadata store（PostgreSQL 或 MySQL），部署和维护起来成本非常高。而 Prometheus 采用去中心化架构，可以独立部署，不依赖于外部的分布式存储，你可以在几分钟的时间里就可以搭建出一套监控系统。

此外，Prometheus 数据采集方式也非常灵活。要采集目标的监控数据，首先需要在目标处安装数据采集组件，这被称之为 Exporter，它会在目标处收集监控数据，并暴露出一个 HTTP 接口供 Prometheus 查询，Prometheus 通过 Pull 的方式来采集数据，这和传统的 Push 模式不同。不过 Prometheus 也提供了一种方式来支持 Push 模式，你可以将你的数据推送到 Push Gateway，Prometheus 通过 Pull 的方式从 Push Gateway 获取数据。目前的 Exporter 已经可以采集绝大多数的第三方数据，比如 Docker、HAProxy、StatsD、JMX 等等，官网有一份 Exporter 的列表。

除了这四大特性，随着 Prometheus 的不断发展，开始支持越来越多的高级特性，比如：服务发现，更丰富的图表展示，使用外部存储，强大的告警规则和多样的通知方式。下图是 Prometheus 的整体架构图（图片来源）：

architecture.png

从上图可以看出，Prometheus 生态系统包含了几个关键的组件：Prometheus server、Pushgateway、Alertmanager、Web UI 等，但是大多数组件都不是必需的，其中最核心的组件当然是 Prometheus server，它负责收集和存储指标数据，支持表达式查询，和告警的生成。接下来我们就来安装 Prometheus server。

二、安装 Prometheus server
Prometheus 可以支持多种安装方式，包括 Docker、Ansible、Chef、Puppet、Saltstack 等。下面介绍最简单的两种方式，一种是直接使用编译好的可执行文件，开箱即用，另一种是使用 Docker 镜像，更多的安装方式可以参考 这里。

2.1 开箱即用
首先从 官网的下载页面 获取 Prometheus 的最新版本和下载地址，目前最新版本是 2.4.3（2018年10月），执行下面的命令下载并解压：

$ wget https://github.com/prometheus/prometheus/releases/download/v2.4.3/prometheus-2.4.3.linux-amd64.tar.gz

$ tar xvfz prometheus-2.4.3.linux-amd64.tar.gz

然后切换到解压目录，检查 Prometheus 版本：

$ cd prometheus-2.4.3.linux-amd64

$ ./prometheus --version

prometheus, version 2.4.3 (branch: HEAD, revision: 167a4b4e73a8eca8df648d2d2043e21bdb9a7449)

build user: root@1e42b46043e9

build date: 20181004-08:42:02

go version: go1.11.1

运行 Prometheus server：

1

$ ./prometheus --config.file=prometheus.yml

2.2 使用 Docker 镜像
使用 Docker 安装 Prometheus 更简单，运行下面的命令即可：

$ sudo docker run -d -p 9090:9090 prom/prometheus

一般情况下，我们还会指定配置文件的位置：

$ sudo docker run -d -p 9090:9090

-v ~/docker/prometheus/:/etc/prometheus/

prom/prometheus

我们把配置文件放在本地 ~/docker/prometheus/prometheus.yml，这样可以方便编辑和查看，通过 -v 参数将本地的配置文件挂载到 /etc/prometheus/ 位置，这是 prometheus 在容器中默认加载的配置文件位置。如果我们不确定默认的配置文件在哪，可以先执行上面的不带 -v 参数的命令，然后通过 docker inspect 命名看看容器在运行时默认的参数有哪些（下面的 Args 参数）：

$ sudo docker inspect 0c

[…]

“Id”: “0c4c2d0eed938395bcecf1e8bb4b6b87091fc4e6385ce5b404b6bb7419010f46”,

“Created”: “2018-10-15T22:27:34.56050369Z”,

“Path”: “/bin/prometheus”,

“Args”: [

“–config.file=/etc/prometheus/prometheus.yml”,

“–storage.tsdb.path=/prometheus”,

“–web.console.libraries=/usr/share/prometheus/console_libraries”,

“–web.console.templates=/usr/share/prometheus/consoles”

],

[…]

2.3 配置 Prometheus
正如上面两节看到的，Prometheus 有一个配置文件，通过参数 --config.file 来指定，配置文件格式为 YAML。我们可以打开默认的配置文件 prometheus.yml 看下里面的内容：

/etc/prometheus $ cat prometheus.yml

my global config

global:

scrape_interval: 15s # Set the scrape interval to every 15 seconds. Default is every 1 minute.

evaluation_interval: 15s # Evaluate rules every 15 seconds. The default is every 1 minute.

scrape_timeout is set to the global default (10s).

Alertmanager configuration

alerting:

alertmanagers:

• static_configs:

• targets:

- alertmanager:9093

Load rules once and periodically evaluate them according to the global ‘evaluation_interval’.

rule_files:

- “first_rules.yml”

- “second_rules.yml”

A scrape configuration containing exactly one endpoint to scrape:

Here it’s Prometheus itself.

scrape_configs:

The job name is added as a label job=<job_name> to any timeseries scraped from this config.

• job_name: ‘prometheus’

metrics_path defaults to ‘/metrics’

scheme defaults to ‘http’.

static_configs:

• targets: [‘localhost:9090’]

Prometheus 默认的配置文件分为四大块：

global 块：Prometheus 的全局配置，比如 scrape_interval 表示 Prometheus 多久抓取一次数据，evaluation_interval 表示多久检测一次告警规则；
alerting 块：关于 Alertmanager 的配置，这个我们后面再看；
rule_files 块：告警规则，这个我们后面再看；
scrape_config 块：这里定义了 Prometheus 要抓取的目标，我们可以看到默认已经配置了一个名称为 prometheus 的 job，这是因为 Prometheus 在启动的时候也会通过 HTTP 接口暴露自身的指标数据，这就相当于 Prometheus 自己监控自己，虽然这在真正使用 Prometheus 时没啥用处，但是我们可以通过这个例子来学习如何使用 Prometheus；可以访问 http://localhost:9090/metrics 查看 Prometheus 暴露了哪些指标；
更多的配置参数可以参考 这里。

三、学习 PromQL
通过上面的步骤安装好 Prometheus 之后，我们现在可以开始体验 Prometheus 了。Prometheus 提供了可视化的 Web UI 方便我们操作，直接访问 http://localhost:9090/ 即可，它默认会跳转到 Graph 页面：

prometheus-index.jpg

第一次访问这个页面可能会不知所措，我们可以先看看其他菜单下的内容，比如：Alerts 展示了定义的所有告警规则，Status 可以查看各种 Prometheus 的状态信息，有 Runtime & Build Information、Command-Line Flags、Configuration、Rules、Targets、Service Discovery 等等。

实际上 Graph 页面才是 Prometheus 最强大的功能，在这里我们可以使用 Prometheus 提供的一种特殊表达式来查询监控数据，这个表达式被称为 PromQL（Prometheus Query Language）。通过 PromQL 不仅可以在 Graph 页面查询数据，而且还可以通过 Prometheus 提供的 HTTP API 来查询。查询的监控数据有列表和曲线图两种展现形式（对应上图中 Console 和 Graph 这两个标签）。

我们上面说过，Prometheus 自身也暴露了很多的监控指标，也可以在 Graph 页面查询，展开 Execute 按钮旁边的下拉框，可以看到很多指标名称，我们随便选一个，譬如：promhttp_metric_handler_requests_total，这个指标表示 /metrics 页面的访问次数，Prometheus 就是通过这个页面来抓取自身的监控数据的。在 Console 标签中查询结果如下：

prometheus-console.jpg

上面在介绍 Prometheus 的配置文件时，可以看到 scrape_interval 参数是 15s，也就是说 Prometheus 每 15s 访问一次 /metrics 页面，所以我们过 15s 刷新下页面，可以看到指标值会自增。在 Graph 标签中可以看得更明显：

prometheus-graph.jpg

3.1 数据模型
要学习 PromQL，首先我们需要了解下 Prometheus 的数据模型，一条 Prometheus 数据由一个指标名称（metric）和 N 个标签（label，N >= 0）组成的，比如下面这个例子：

1

promhttp_metric_handler_requests_total{code=“200”,instance=“192.168.0.107:9090”,job=“prometheus”} 106

这条数据的指标名称为 promhttp_metric_handler_requests_total，并且包含三个标签 code、instance 和 job，这条记录的值为 106。上面说过，Prometheus 是一个时序数据库，相同指标相同标签的数据构成一条时间序列。如果以传统数据库的概念来理解时序数据库，可以把指标名当作表名，标签是字段，timestamp 是主键，还有一个 float64 类型的字段表示值（Prometheus 里面所有值都是按 float64 存储）。

这种数据模型和 OpenTSDB 的数据模型是比较类似的，详细的信息可以参考官网文档 Data model。另外，关于指标和标签的命名，官网有一些指导性的建议，可以参考 Metric and label naming 。

虽然 Prometheus 里存储的数据都是 float64 的一个数值，但如果我们按类型来分，可以把 Prometheus 的数据分成四大类：

Counter
Gauge
Histogram
Summary
Counter 用于计数，例如：请求次数、任务完成数、错误发生次数，这个值会一直增加，不会减少。Gauge 就是一般的数值，可大可小，例如：温度变化、内存使用变化。Histogram 是直方图，或称为柱状图，常用于跟踪事件发生的规模，例如：请求耗时、响应大小。它特别之处是可以对记录的内容进行分组，提供 count 和 sum 的功能。Summary 和 Histogram 十分相似，也用于跟踪事件发生的规模，不同之处是，它提供了一个 quantiles 的功能，可以按百分比划分跟踪的结果。例如：quantile 取值 0.95，表示取采样值里面的 95% 数据。更多信息可以参考官网文档 Metric types，Summary 和 Histogram 的概念比较容易混淆，属于比较高阶的指标类型，可以参考 Histograms and summaries 这里的说明。

这四种类型的数据只在指标的提供方作区分，也就是上面说的 Exporter，如果你需要编写自己的 Exporter 或者在现有系统中暴露供 Prometheus 抓取的指标，你可以使用 Prometheus client libraries，这个时候你就需要考虑不同指标的数据类型了。如果你不用自己实现，而是直接使用一些现成的 Exporter，然后在 Prometheus 里查查相关的指标数据，那么可以不用太关注这块，不过理解 Prometheus 的数据类型，对写出正确合理的 PromQL 也是有帮助的。