乐趣区

关于prometheus:号称下一代监控系统来看看它有多牛逼

jiezi

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，在这篇文章中，他们介绍到，他们须要的监控零碎必须满足上面四个个性：

简略来说，就是上面四个个性：

  • 多维度数据模型
  • 不便的部署和保护
  • 灵便的数据采集
  • 弱小的查询语言

实际上，多维度数据模型和弱小的查询语言这两个个性，正是时序数据库所要求的，所以 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 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：

$ ./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 页面：

第一次拜访这个页面可能会手足无措，咱们能够先看看其余菜单下的内容，比方：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 标签中能够看得更显著：

3.1 数据模型

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

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。

尽管 Prometheus 里存储的数据都是 float64 的一个数值，但如果咱们按类型来分，能够把 Prometheus 的数据分成四大类：

  • Counter
  • Gauge
  • Histogram
  • Summary

Counter 用于计数，例如：申请次数、工作实现数、谬误产生次数，这个值会始终减少，不会缩小。Gauge 就是个别的数值，可大可小，例如：温度变动、内存应用变动。Histogram 是直方图，或称为柱状图，罕用于跟踪事件产生的规模，例如：申请耗时、响应大小。

它特别之处是能够对记录的内容进行分组，提供 count 和 sum 的性能。Summary 和 Histogram 十分相似，也用于跟踪事件产生的规模，不同之处是，它提供了一个 quantiles 的性能，能够按百分比划分跟踪的后果。例如：quantile 取值 0.95，示意取采样值外面的 95% 数据。

这四种类型的数据只在指标的提供方作辨别，也就是下面说的 Exporter，如果你须要编写本人的 Exporter 或者在现有零碎中裸露供 Prometheus 抓取的指标，你能够应用 Prometheus client libraries，这个时候你就须要思考不同指标的数据类型了。如果你不必本人实现，而是间接应用一些现成的 Exporter，而后在 Prometheus 里查查相干的指标数据，那么能够不必太关注这块，不过了解 Prometheus 的数据类型，对写出正确正当的 PromQL 也是有帮忙的。

3.2 PromQL 入门

咱们从一些例子开始学习 PromQL，最简略的 PromQL 就是间接输出指标名称，比方：

# 示意 Prometheus 是否抓取 target 的指标，用于 target 的健康检查  
up

这条语句会查出 Prometheus 抓取的所有 target 以后运行状况，譬如上面这样：

up{instance="192.168.0.107:9090",job="prometheus"}    1  
up{instance="192.168.0.108:9090",job="prometheus"}    1  
up{instance="192.168.0.107:9100",job="server"}    1  
up{instance="192.168.0.108:9104",job="mysql"}    0

也能够指定某个 label 来查问：

up{job="prometheus"}

这种写法被称为 Instant vector selectors，这里不仅能够应用 = 号，还能够应用 !=、=~、!~，比方上面这样：

up{job!="prometheus"}  
up{job=~"server|mysql"}  
up{job=~"192\.168\.0\.107.+"}  
#=~ 是依据正则表达式来匹配，必须合乎 RE2 的语法。

和 Instant vector selectors 相应的，还有一种选择器，叫做 Range vector selectors，它能够查出一段时间内的所有数据：

http_requests_total[5m]

这条语句查出 5 分钟内所有抓取的 HTTP 申请数，留神它返回的数据类型是 Range vector，没方法在 Graph 上显示成曲线图，个别状况下，会用在 Counter 类型的指标上，并和 rate() 或 irate() 函数一起应用（留神 rate 和 irate 的区别）。

# 计算的是每秒的平均值，实用于变动很慢的 counter  
# per-second average rate of increase, for slow-moving counters  
rate(http_requests_total[5m])  
   
# 计算的是每秒刹时减少速率，实用于变动很快的 counter  
# per-second instant rate of increase, for volatile and fast-moving counters  
irate(http_requests_total[5m])

此外，PromQL 还反对 count、sum、min、max、topk 等 聚合操作，还反对 rate、abs、ceil、floor 等一堆的 内置函数，更多的例子，还是上官网学习吧。如果感兴趣，咱们还能够把 PromQL 和 SQL 做一个比照，会发现 PromQL 语法更简洁，查问性能也更高。

3.3 HTTP API

咱们不仅仅能够在 Prometheus 的 Graph 页面查问 PromQL，Prometheus 还提供了一种 HTTP API 的形式，能够更灵便的将 PromQL 整合到其余零碎中应用，譬如上面要介绍的 Grafana，就是通过 Prometheus 的 HTTP API 来查问指标数据的。实际上，咱们在 Prometheus 的 Graph 页面查问也是应用了 HTTP API。

咱们看下 Prometheus 的 HTTP API 官网文档，它提供了上面这些接口：

GET /api/v1/query
GET /api/v1/query_range
GET /api/v1/series
GET /api/v1/label/<label_name>/values
GET /api/v1/targets
GET /api/v1/rules
GET /api/v1/alerts
GET /api/v1/targets/metadata
GET /api/v1/alertmanagers
GET /api/v1/status/config
GET /api/v1/status/flags

从 Prometheus v2.1 开始，又新增了几个用于治理 TSDB 的接口：

POST /api/v1/admin/tsdb/snapshot
POST /api/v1/admin/tsdb/delete_series
POST /api/v1/admin/tsdb/clean_tombstones

四、装置 Grafana

尽管 Prometheus 提供的 Web UI 也能够很好的查看不同指标的视图，然而这个性能非常简单，只适宜用来调试。要实现一个弱小的监控零碎，还须要一个能定制展现不同指标的面板，能反对不同类型的展示形式（曲线图、饼状图、热点图、TopN 等），这就是仪表盘（Dashboard）性能。

因而 Prometheus 开发了一套仪表盘零碎 PromDash，不过很快这套零碎就被废除了，官网开始举荐应用 Grafana 来对 Prometheus 的指标数据进行可视化，这不仅是因为 Grafana 的性能十分弱小，而且它和 Prometheus 能够完满的无缝交融。

Grafana 是一个用于可视化大型测量数据的开源零碎，它的性能十分弱小，界面也十分丑陋，应用它能够创立自定义的控制面板，你能够在面板中配置要显示的数据和显示方式，它 反对很多不同的数据源，比方：Graphite、InfluxDB、OpenTSDB、Elasticsearch、Prometheus 等，而且它也 反对泛滥的插件。

上面咱们就体验下应用 Grafana 来展现 Prometheus 的指标数据。首先咱们来装置 Grafana，咱们应用最简略的 Docker 装置形式：

$ docker run -d -p 3000:3000 grafana/grafana

运行下面的 docker 命令，Grafana 就装置好了！你也能够采纳其余的装置形式，参考 官网的装置文档。装置实现之后，咱们拜访 http://localhost:3000/ 进入 Grafana 的登陆页面，输出默认的用户名和明码（admin/admin）即可。

要应用 Grafana，第一步当然是要配置数据源，通知 Grafana 从哪里取数据，咱们点击 Add data source 进入数据源的配置页面：

咱们在这里顺次填上：

  • Name: prometheus
  • Type: Prometheus
  • URL: http://localhost:9090
  • Access: Browser

要留神的是，这里的 Access 指的是 Grafana 拜访数据源的形式，有 Browser 和 Proxy 两种形式。Browser 形式示意当用户拜访 Grafana 面板时，浏览器间接通过 URL 拜访数据源的；而 Proxy 形式示意浏览器先拜访 Grafana 的某个代理接口（接口地址是 /api/datasources/proxy/），由 Grafana 的服务端来拜访数据源的 URL，如果数据源是部署在内网，用户通过浏览器无奈间接拜访时，这种形式十分有用。

配置好数据源，Grafana 会默认提供几个曾经配置好的面板供你应用，如下图所示，默认提供了三个面板：Prometheus Stats、Prometheus 2.0 Stats 和 Grafana metrics。点击 Import 就能够导入并应用该面板。

咱们导入 Prometheus 2.0 Stats 这个面板，能够看到上面这样的监控面板。如果你的公司有条件，能够申请个大显示器挂在墙上，将这个面板投影在大屏上，实时察看线上零碎的状态，能够说是十分 cool 的。

五、应用 Exporter 收集指标

目前为止，咱们看到的都还只是一些没有理论用处的指标，如果咱们要在咱们的生产环境真正应用 Prometheus，往往须要关注各种各样的指标，譬如服务器的 CPU 负载、内存占用量、IO 开销、入网和出网流量等等。

正如下面所说，Prometheus 是应用 Pull 的形式来获取指标数据的，要让 Prometheus 从指标处取得数据，首先必须在指标上装置指标收集的程序，并暴露出 HTTP 接口供 Prometheus 查问，这个指标收集程序被称为 Exporter，不同的指标须要不同的 Exporter 来收集，目前曾经有大量的 Exporter 可供使用，简直囊括了咱们罕用的各种零碎和软件。

官网列出了一份 罕用 Exporter 的清单，各个 Exporter 都遵循一份端口约定，防止端口抵触，即从 9100 开始顺次递增，这里是 残缺的 Exporter 端口列表。另外值得注意的是，有些软件和零碎无需装置 Exporter，这是因为他们自身就提供了裸露 Prometheus 格局的指标数据的性能，比方 Kubernetes、Grafana、Etcd、Ceph 等。

这一节就让咱们来收集一些有用的数据。

5.1 收集服务器指标

首先咱们来收集服务器的指标，这须要装置 node_exporter，这个 exporter 用于收集 *NIX 内核的零碎，如果你的服务器是 Windows，能够应用 WMI exporter。

和 Prometheus server 一样，node_exporter 也是开箱即用的：

$ wget https://github.com/prometheus/node_exporter/releases/download/v0.16.0/node_exporter-0.16.0.linux-amd64.tar.gz  
$ tar xvfz node_exporter-0.16.0.linux-amd64.tar.gz  
$ cd node_exporter-0.16.0.linux-amd64  
$ ./node_exporter

node_exporter 启动之后，咱们拜访下 /metrics 接口看看是否能失常获取服务器指标：

$ curl http://localhost:9100/metrics

如果所有 OK，咱们能够批改 Prometheus 的配置文件，将服务器加到 scrape_configs 中：

scrape_configs:  
  - job_name: 'prometheus'  
    static_configs:  
      - targets: ['192.168.0.107:9090']  
  - job_name: 'server'  
    static_configs:  
      - targets: ['192.168.0.107:9100']

批改配置后，须要重启 Prometheus 服务，或者发送 HUP 信号也能够让 Prometheus 从新加载配置：

$ killall -HUP prometheus

在 Prometheus Web UI 的 Status -> Targets 中，能够看到新加的服务器：

在 Graph 页面的指标下拉框能够看到很多名称以 node 结尾的指标，譬如咱们输出 node_load1 察看服务器负载：

如果想在 Grafana 中查看服务器的指标，能够在 Grafana 的 Dashboards 页面 搜寻 node exporter，有很多的面板模板能够间接应用，譬如：Node Exporter Server Metrics 或者 Node Exporter Full 等。咱们关上 Grafana 的 Import dashboard 页面，输出面板的 URL（https://grafana.com/dashboards/405）或者 ID（405）即可。

注意事项

个别状况下，node_exporter 都是间接运行在要收集指标的服务器上的，官网不举荐用 Docker 来运行 node_exporter。如果逼不得已肯定要运行在 Docker 里，要特地留神，这是因为 Docker 的文件系统和网络都有本人的 namespace，收集的数据并不是宿主机实在的指标。能够应用一些变通的办法，比方运行 Docker 时加上上面这样的参数：

docker run -d \  
  --net="host" \  
  --pid="host" \  
  -v "/:/host:ro,rslave" \  
  quay.io/prometheus/node-exporter \  
  --path.rootfs /host

对于 node_exporter 的更多信息，能够参考 node_exporter 的文档 和 Prometheus 的官网指南 Monitoring Linux host metrics with the Node Exporter。

5.2 收集 MySQL 指标

mysqld_exporter 是 Prometheus 官网提供的一个 exporter，咱们首先 下载最新版本 并解压（开箱即用）：

$ wget https://github.com/prometheus/mysqld_exporter/releases/download/v0.11.0/mysqld_exporter-0.11.0.linux-amd64.tar.gz  
$ tar xvfz mysqld_exporter-0.11.0.linux-amd64.tar.gz  
$ cd mysqld_exporter-0.11.0.linux-amd64/

mysqld_exporter 须要连贯到 mysqld 能力收集它的指标，能够通过两种形式来设置 mysqld 数据源。第一种是通过环境变量 DATA_SOURCE_NAME，这被称为 DSN（数据源名称），它必须合乎 DSN 的格局，一个典型的 DSN 格局像这样：user:password@(host:port)/。

$ export DATA_SOURCE_NAME='root:123456@(192.168.0.107:3306)/'  
$ ./mysqld_exporter

另一种形式是通过配置文件，默认的配置文件是 ~/.my.cnf，或者通过 –config.my-cnf 参数指定：

$ ./mysqld_exporter --config.my-cnf=".my.cnf"

配置文件的格局如下：

$ cat .my.cnf  
[client]  
host=localhost  
port=3306  
user=root  
password=123456

如果要把 MySQL 的指标导入 Grafana，能够参考 这些 Dashboard JSON。

注意事项

这里为简略起见，在 mysqld_exporter 中间接应用了 root 连贯数据库，在实在环境中，能够为 mysqld_exporter 创立一个独自的用户，并赋予它受限的权限（PROCESS、REPLICATION CLIENT、SELECT），最好还限度它的最大连接数（MAX_USER_CONNECTIONS）。

CREATE USER 'exporter'@'localhost' IDENTIFIED BY 'password' WITH MAX_USER_CONNECTIONS 3;  
GRANT PROCESS, REPLICATION CLIENT, SELECT ON *.* TO 'exporter'@'localhost';
5.3 收集 Nginx 指标

官网提供了两种收集 Nginx 指标的形式。

  • 第一种 是 Nginx metric library，这是一段 Lua 脚本（prometheus.lua），Nginx 须要开启 Lua 反对（libnginx-mod-http-lua 模块）。为不便起见，也能够应用 OpenResty 的 OPM（OpenResty Package Manager）或者 luarocks（The Lua package manager）来装置。
  • 第二种 是 Nginx VTS exporter，这种形式比第一种要弱小的多，装置要更简略，反对的指标也更丰盛，它依赖于 nginx-module-vts 模块，vts 模块能够提供大量的 Nginx 指标数据，能够通过 JSON、HTML 等模式查看这些指标。Nginx VTS exporter 就是通过抓取 /status/format/json 接口来将 vts 的数据格式转换为 Prometheus 的格局。

不过，在 nginx-module-vts 最新的版本中减少了一个新接口：/status/format/prometheus，这个接口能够间接返回 Prometheus 的格局，从这点这也能看出 Prometheus 的影响力，预计 Nginx VTS exporter 很快就要服役了（TODO：待验证）。

除此之外，还有很多其余的形式来收集 Nginx 的指标，比方：nginx_exporter 通过抓取 Nginx 自带的统计页面 /nginx_status 能够获取一些比较简单的指标（须要开启 ngx_http_stub_status_module 模块）；nginx_request_exporter 通过 syslog 协定 收集并剖析 Nginx 的 access log 来统计 HTTP 申请相干的一些指标；nginx-prometheus-shiny-exporter 和 nginx_request_exporter 相似，也是应用 syslog 协定来收集 access log，不过它是应用 Crystal 语言 写的。还有 vovolie/lua-nginx-prometheus 基于 Openresty、Prometheus、Consul、Grafana 实现了针对域名和 Endpoint 级别的流量统计。

有须要或感兴趣的同学能够对照阐明文档本人装置体验下，这里就不一一尝试了。

5.4 收集 JMX 指标

最初让咱们来看下如何收集 Java 利用的指标，Java 利用的指标个别是通过 JMX（Java Management Extensions）来获取的，顾名思义，JMX 是治理 Java 的一种扩大，它能够不便的治理和监控正在运行的 Java 程序。

JMX Exporter 用于收集 JMX 指标，很多应用 Java 的零碎，都能够应用它来收集指标，比方：Kafaka、Cassandra 等。首先咱们下载 JMX Exporter：

$ wget https://repo1.maven.org/maven2/io/prometheus/jmx/jmx_prometheus_javaagent/0.3.1/jmx_prometheus_javaagent-0.3.1.jar

JMX Exporter 是一个 Java Agent 程序，在运行 Java 程序时通过 -javaagent 参数来加载：

$ java -javaagent:jmx_prometheus_javaagent-0.3.1.jar=9404:config.yml -jar spring-boot-sample-1.0-SNAPSHOT.jar

其中，9404 是 JMX Exporter 裸露指标的端口，config.yml 是 JMX Exporter 的配置文件，它的内容能够 参考 JMX Exporter 的配置阐明。而后查看下指标数据是否正确获取：

$ curl http://localhost:9404/metrics

六、告警和告诉

至此，咱们能收集大量的指标数据，也能通过弱小而好看的面板展现进去。不过作为一个监控零碎，最重要的性能，还是应该能及时发现零碎问题，并及时告诉给零碎负责人，这就是 Alerting（告警）。

Prometheus 的告警性能被分成两局部：一个是告警规定的配置和检测，并将告警发送给 Alertmanager，另一个是 Alertmanager，它负责管理这些告警，去除反复数据，分组，并路由到对应的接管形式，发出报警。常见的接管形式有：Email、PagerDuty、HipChat、Slack、OpsGenie、WebHook 等。

6.1 配置告警规定

咱们在下面介绍 Prometheus 的配置文件时理解到，它的默认配置文件 prometheus.yml 有四大块：global、alerting、rule_files、scrape_config，其中 rule_files 块就是告警规定的配置项，alerting 块用于配置 Alertmanager，这个咱们下一节再看。当初，先让咱们在 rule_files 块中增加一个告警规定文件：

rule_files:  
  - "alert.rules"

而后参考 官网文档，创立一个告警规定文件 alert.rules：

groups:  
- name: example  
  rules:  
   
  # Alert for any instance that is unreachable for >5 minutes.  
  - alert: InstanceDown  
    expr: up == 0  
    for: 5m  
    labels:  
      severity: page  
    annotations:  
      summary: "Instance {{$labels.instance}} down"  
      description: "{{$labels.instance}} of job {{$labels.job}} has been down for more than 5 minutes."  
   
  # Alert for any instance that has a median request latency >1s.  
  - alert: APIHighRequestLatency  
    expr: api_http_request_latencies_second{quantile="0.5"} > 1  
    for: 10m  
    annotations:  
      summary: "High request latency on {{$labels.instance}}"  
      description: "{{$labels.instance}} has a median request latency above 1s (current value: {{ $value}}s)"

这个规定文件里，蕴含了两条告警规定：InstanceDown 和 APIHighRequestLatency。顾名思义，InstanceDown 示意当实例宕机时（up === 0）触发告警，APIHighRequestLatency 示意有一半的 API 申请提早大于 1s 时（api_http_request_latencies_second{quantile=”0.5″} > 1）触发告警。

配置好后，须要重启下 Prometheus server，而后拜访 http://localhost:9090/rules 能够看到刚刚配置的规定：

拜访 http://localhost:9090/alerts 能够看到依据配置的规定生成的告警：

这里咱们将一个实例停掉，能够看到有一条 alert 的状态是 PENDING，这示意曾经触发了告警规定，但还没有达到告警条件。这是因为这里配置的 for 参数是 5m，也就是 5 分钟后才会触发告警，咱们等 5 分钟，能够看到这条 alert 的状态变成了 FIRING。

6.2 应用 Alertmanager 发送告警告诉

尽管 Prometheus 的 /alerts 页面能够看到所有的告警，然而还差最初一步：触发告警时主动发送告诉。这是由 Alertmanager 来实现的，咱们首先 下载并装置 Alertmanager，和其余 Prometheus 的组件一样，Alertmanager 也是开箱即用的：

$ wget https://github.com/prometheus/alertmanager/releases/download/v0.15.2/alertmanager-0.15.2.linux-amd64.tar.gz  
$ tar xvfz alertmanager-0.15.2.linux-amd64.tar.gz  
$ cd alertmanager-0.15.2.linux-amd64  
$ ./alertmanager

Alertmanager 启动后默认能够通过 http://localhost:9093/ 来拜访，然而当初还看不到告警，因为咱们还没有把 Alertmanager 配置到 Prometheus 中，咱们回到 Prometheus 的配置文件 prometheus.yml，增加上面几行：

alerting:  
  alertmanagers:  
  - scheme: http  
    static_configs:  
    - targets:  
      - "192.168.0.107:9093"

这个配置通知 Prometheus，当产生告警时，将告警信息发送到 Alertmanager，Alertmanager 的地址为 http://192.168.0.107:9093。也能够应用命名行的形式指定 Alertmanager：

$ ./prometheus -alertmanager.url=http://192.168.0.107:9093

这个时候再拜访 Alertmanager，能够看到 Alertmanager 曾经接管到告警了：

上面的问题就是如何让 Alertmanager 将告警信息发送给咱们了，咱们关上默认的配置文件 alertmanager.ym：

global:  
  resolve_timeout: 5m  
   
route:  
  group_by: ['alertname']  
  group_wait: 10s  
  group_interval: 10s  
  repeat_interval: 1h  
  receiver: 'web.hook'  
receivers:  
- name: 'web.hook'  
  webhook_configs:  
  - url: 'http://127.0.0.1:5001/'  
inhibit_rules:  
  - source_match:  
      severity: 'critical'  
    target_match:  
      severity: 'warning'  
    equal: ['alertname', 'dev', 'instance']

其中 global 块示意一些全局配置；route 块示意告诉路由，能够依据不同的标签将告警告诉发送给不同的 receiver，这里没有配置 routes 项，示意所有的告警都发送给上面定义的 web.hook 这个 receiver；如果要配置多个路由，能够参考 这个例子：

routes:  
- receiver: 'database-pager'  
  group_wait: 10s  
  match_re:  
    service: mysql|cassandra  
   
- receiver: 'frontend-pager'  
  group_by: [product, environment]  
  match:  
    team: frontend

紧接着，receivers 块示意告警告诉的接管形式，每个 receiver 蕴含一个 name 和一个 xxx_configs，不同的配置代表了不同的接管形式，Alertmanager 内置了上面这些接管形式：

email_config
hipchat_config
pagerduty_config
pushover_config
slack_config
opsgenie_config
victorops_config
wechat_configs
webhook_config

尽管接管形式很丰盛，然而在国内，其中大多数接管形式都很少应用。最罕用到的，莫属 email_config 和 webhook_config，另外 wechat_configs 能够反对应用微信来告警，也是相当符合国情的了。

其实告警的告诉形式是很难做到八面玲珑的，因为音讯软件各种各样，每个国家还可能不同，不可能齐全笼罩到，所以 Alertmanager 曾经决定不再增加新的 receiver 了，而是举荐应用 webhook 来集成自定义的接管形式。能够参考 这些集成的例子，譬如 将钉钉接入 Prometheus AlertManager WebHook。

七、学习更多

到这里，咱们曾经学习了 Prometheus 的大多数性能，联合 Prometheus + Grafana + Alertmanager 齐全能够搭建一套十分残缺的监控零碎。不过在真正应用时，咱们会发现更多的问题。

7.1 服务发现

因为 Prometheus 是通过 Pull 的形式被动获取监控数据，所以须要手工指定监控节点的列表，当监控的节点增多之后，每次减少节点都须要更改配置文件，十分麻烦，这个时候就须要通过服务发现（service discovery，SD）机制去解决。

Prometheus 反对多种服务发现机制，能够主动获取要收集的 targets，能够参考 这里，蕴含的服务发现机制包含：azure、consul、dns、ec2、openstack、file、gce、kubernetes、marathon、triton、zookeeper（nerve、serverset），配置办法能够参考手册的 Configuration 页面。能够说 SD 机制是十分丰盛的，但目前因为开发资源无限，曾经不再开发新的 SD 机制，只对基于文件的 SD 机制进行保护。

对于服务发现网上有很多教程，譬如 Prometheus 官网博客中这篇文章 Advanced Service Discovery in Prometheus 0.14.0 对此有一个比拟零碎的介绍，全面的解说了 relabeling 配置，以及如何应用 DNS-SRV、Consul 和文件来做服务发现。

另外，官网还提供了 一个基于文件的服务发现的入门例子，Julius Volz 写的 Prometheus workshop 入门教程中也 应用了 DNS-SRV 来当服务发现。

7.2 告警配置管理

无论是 Prometheus 的配置还是 Alertmanager 的配置，都没有提供 API 供咱们动静的批改。一个很常见的场景是，咱们须要基于 Prometheus 做一套可自定义规定的告警零碎，用户可依据本人的须要在页面上创立批改或删除告警规定，或者是批改告警告诉形式和联系人，正如在 Prometheus Google Groups 里的 这个用户的问题：How to dynamically add alerts rules in rules.conf and prometheus yml file via API or something？

不过遗憾的是，Simon Pasquier 在上面说到，目前并没有这样的 API，而且当前也没有这样的打算来开发这样的 API，因为这样的性能更应该交给譬如 Puppet、Chef、Ansible、Salt 这样的配置管理系统。

7.3 应用 Pushgateway

Pushgateway 次要用于收集一些短期的 jobs，因为这类 jobs 存在工夫较短，可能在 Prometheus 来 Pull 之前就隐没了。官网对 什么时候该应用 Pushgateway 有一个很好的阐明。

总结

最近两年 Prometheus 的倒退十分迅速，社区也十分沉闷，国内钻研 Prometheus 的人也越来越多。随着微服务，DevOps，云计算，云原生等概念的遍及，越来越多的企业开始应用 Docker 和 Kubernetes 来构建本人的零碎和利用，像 Nagios 和 Cacti 这样的老牌监控零碎会变得越来越不实用，置信 Prometheus 最终会倒退成一个最适宜云环境的监控零碎。

起源：aneasystone.com/archives/2018/11/prometheus-in-action.html

退出移动版