关于prometheus:实战-Prometheus-搭建监控系统

5次阅读

共计 7890 个字符，预计需要花费 20 分钟才能阅读完成。

前言：Prometheus 曾经成为了事实上的监控规范，本篇文章是依据参考书籍《Prometheus 监控技术与实际》、《深入浅出 Prometheus》两本书籍的介绍搭建普罗米修斯零碎。

：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 监控技术与实际》、《深入浅出 Prometheus》
链接: https://pan.baidu.com/s/1qmdi… 提取码: n82k
https://pan.baidu.com/s/1pM7_… 提取码: 6eiw

咱们在 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 的整体架构图（图片起源）：

从上图能够看出，Prometheus 生态系统蕴含了几个要害的组件：Prometheus server、Pushgateway、Alertmanager、Web UI 等，然而大多数组件都不是必须的，其中最外围的组件当然是 Prometheus server，它负责收集和存储指标数据，反对表达式查问，和告警的生成。接下来咱们就来装置 Prometheus server。

Prometheus 能够反对多种装置形式，包含 Docker、Ansible、Chef、Puppet、Saltstack 等。上面介绍最简略的两种形式，一种是间接应用编译好的可执行文件，开箱即用，另一种是应用 Docker 镜像，更多的装置形式能够参考这里。

首先从官网的下载页面获取 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](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

应用 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"

],

[...]

正如下面两节看到的，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 裸露了哪些指标；

更多的配置参数能够参考这里。

通过下面的步骤装置好 Prometheus 之后，咱们当初能够开始体验 Prometheus 了。Prometheus 提供了可视化的 Web UI 不便咱们操作，间接拜访 http://localhost:9090/ 即可，它默认会跳转到 Graph 页面：

第一次拜访这个页面可能会手足无措，咱们能够先看看其余菜单下的内容，比方：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 的配置文件时，能够看到 scrape_interval 参数是 15s，也就是说 Prometheus 每 15s 拜访一次 /metrics 页面，所以咱们过 15s 刷新下页面，能够看到指标值会自增。在 Graph 标签中能够看得更显著：

要学习 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 也是有帮忙的。

正文完