一、Prometheus简介
二、Prometheus 的特点
2.1、Prometheus 适合做什么？
2.2、Prometheus 不适合做什么？
三、Prometheus 的组件与架构
3.1、Prometheus 生态圈组件
3.2、Prometheus 的架构
四、Prometheus 相关概念
4.1、Prometheus数据模型
4.2、Prometheus四种 Metric 类型
五、Prometheus 安装和配置
5.1、Prometheus server安装和配置
5.2、Node exporter 安装
5.3、Alertmanager 安装和配置
六、Prometheus告警功能演示

一、Prometheus简介

Prometheus是一套开源的系统监控报警框架。它受启发于Google的Brogmon监控系统，由工作在SoundCloud的前google员工在2012年创建，作为社区开源项目进行开发，并于 2015年正式发布。

2016年，Prometheus正式加入Cloud Native Computing Foundation（CNCF）基金会的项目，成为受欢迎度仅次于Kubernetes 的项目。2017年底发布了基于全新存储层的2.0版本，能更好地与容器平台、云平台配合。

Prometheus作为新一代的云原生监控系统，目前已经有超过650+位贡献者参与到Prometheus的研发工作上，并且超过120+项的第三方集成。

二、Prometheus 的特点

作为新一代的监控框架，Prometheus 具有以下特点：

 强大的多维度数据模型
 灵活而强大的查询语句（PromQL）：在同一个查询语句，可以对多个 metrics进行乘法、加法、连接、取分数位等操作。
 易于管理： Prometheus server 是一个单独的二进制文件，可直接在本地工作，不依赖于分布式存储。
 高效：一个 Prometheus server 可以处理数百万的 metrics。
 使用pull模式采集时间序列数据，这样不仅有利于本机测试而且可以避免有问题的服务器推送坏的metrics。
 可以采用 push gateway的方式把时间序列数据推送至Prometheus server 端。
 可以通过服务发现或者静态配置去获取监控的targets。
 支持多种绘图和仪表盘模式。
 监控目标可以通过服务发现或静态配置

2.1、Prometheus 适合做什么？

Prometheus非常适合记录纯数字的时间序列，既可以是以主机为中心的监控，也可以是以服务为导向的动态架构。在微服务的世界，它支持多维度的数据集合，查询功能非常强大。

Prometheus 是为可用性而设计，利用它你可以快速定位问题。每一个 Prometheus Server 都是独立的，不依赖于网络存储或其他的第三方服务。可以在部分基础设施出现问题时仍然使用它。

2.2、Prometheus 不适合做什么？

Prometheus 用于评估可用性。如果你想要100%的精准度，比如每个请求的账单，Prometheus就不是一个好的选择，因为收集上来的数据可能没这么细致、完整。对于这样的需求，你最好用其他的大数据系统对数据做分析。

三、Prometheus 的组件与架构

3.1、Prometheus 生态圈组件

Prometheus 的生态系统包括多个组件，大部分的组件都是用Go语言编写的，因此部署非常方便，而这些组件大部分都是可选的，主要组件介绍如下：

 Prometheus Server
Prometheus Server是Prometheus组件中的核心部分，负责实现对监控数据的获取，存储以及查询。

Prometheus Server可以通过静态配置管理监控目标，也可以配合使用Service Discovery的方式动态管理监控目标，并从这些监控目标中获取数据。

其次Prometheus Server需要对采集到的监控数据进行存储，Prometheus Server本身就是一个时序数据库，将采集到的监控数据按照时间序列的方式存储在本地磁盘当中。

最后Prometheus Server对外提供了自定义的PromQL语言，实现对数据的查询以及分析。

Prometheus Server内置的Express Browser UI，通过这个UI可以直接通过PromQL实现数据的查询以及可视化。

 推送网关（push gateway）

主要是实现接收由Client push过来的指标数据，在指定的时间间隔，由主程序来抓取。

由于Prometheus数据采集基于Pull模型进行设计，因此在网络环境的配置上必须要让Prometheus Server能够直接与Exporter进行通信。

当这种网络需求无法直接满足时，就可以利用PushGateway来进行中转。

可以通过PushGateway将内部网络的监控数据主动Push到Gateway当中。

而Prometheus Server则可以采用同样Pull的方式从PushGateway中获取到监控数据。

 Exporter

主要用来采集数据，并通过HTTP服务的形式暴露给Prometheus Server，Prometheus Server通过访问该Exporter提供的接口，即可获取到需要采集的监控数据。

常见的Exporter有很多，例如node_exporter、mysqld_exporter、statsd_exporter、blackbox_exporter、haproxy_exporter等，支持如 HAProxy，StatsD，Graphite，Redis 此类的服务监控；

 告警管理器（Alertmanager）

管理告警，主要是负责实现报警功能。

在Prometheus Server中支持基于PromQL创建告警规则，如果满足PromQL定义的规则，则会产生一条告警，而告警的后续处理流程则由AlertManager进行管理。

在AlertManager中我们可以与邮件，Slack等等内置的通知方式进行集成，也可以通过Webhook自定义告警处理方式。AlertManager即Prometheus体系中的告警处理中心。

3.2、Prometheus 的架构

下图展示了Prometheus的基本架构：

从架构图中可以看出其大概的工作流程：

1、Prometheus Server 以服务发现（如 Kubernetes 等）的方式自动发现或者静态配置添加监控目标；

2、Prometheus Server 定期从监控目标（Jobs/exporters）或 Pushgateway 中拉取数据（metrics），将时间序列数据保存到其自身的时间序列数据库（TSDB）中；

3、Prometheus Server 通过 HTTP Server 对外开放接口，可以给可视化工具（如 Prometheus web UI、Grafana 或自己开发的工具）用PromQL查询/导出数据；

4、当有告警产生时，Prometheus Server 将告警信息推送到Alertmanager ，由 Alertmanager 根据配置的策略发送告警信息到对应的接收方；

5、Pushgateway 接收 “Short-lived” 类型的 Jobs 推送过来的 metrics 并缓存，等待 Prometheus Server 抓取。

四、Prometheus 相关概念

4.1、Prometheus数据模型

promethes监控中对于采集过来的数据统⼀称为metrics数据，当我们需要为某个系统某个服务做监控、做统计，就需要⽤到Metrics。

因此，metric是⼀种对采样数据的总称（metrics 并不代表某⼀种具体的数据格式是⼀种对于度量计算单位的抽象）

Prometheus中存储的数据为时间序列T-S（time-series），是由 metric 的名字和一系列的标签（键值对）来唯一标识的，不同的标签则代表不同的时间序列。

 metric 名字：该名字应该具有语义，一般用于表示 metric 的功能，例如：http_requeststotal, 表示 http 请求的总数。其中，metric 名字由 ASCII 字符，数字，下划线，以及冒号组成，且必须满足正则表达式 [a-zA-Z:][a-zA-Z0-9_:]*。

 标签：使同一个时间序列有了不同维度的识别。例如 http_requeststotal{method=”Get”} 表示所有 http 请求中的 Get 请求。当 method=”post” 时，则为新的一个 metric。标签中的键由 ASCII 字符，数字，以及下划线组成，且必须满足正则表达式[a-zA-Z:][a-zA-Z0-9_:]*。

 样本：实际的时间序列，每个序列包括一个 float64 的值和一个毫秒级的时间戳。

 格式：<metric name>{<label name>=<label value>, …}，例如：http_requests_total{method=”POST”,endpoint=”/api/tracks”}。

4.2、Prometheus四种 Metric 类型

Prometheus 客户端库主要提供四种主要的 metric 类型，分别为：

1、Counter

一种累加的metric，典型的应用如：请求的个数，结束的任务数，出现的错误数等等。

可以把Counter理解为计数器，从数据量0开始累积计算在理想状态下只能是永远的增加，不会降低。

例如，查询http_requests_total{method=”get”, job=”Prometheus”, handler=”query”}返回 8，10 秒后，再次查询，则返回 14。

2、Gauge

一种常规的metric，典型的应用如：温度，运行的任务的个数。可以任意加减。
例如：go_goroutines{instance=”172.17.0.2”, job=”Prometheus”}返回值 147，10 秒后返回 124。

例如：如果我要监控硬盘容量或者内存的使用量，那么就应该使用Gauges的metrics格式来度量，因为硬盘的容量或者内存的使用量是随着时间的推移不断的瞬时且没有规则变化的，这种变化没有规律，当前是多少，采集回来的就是多少，可以是增加，也可以是降低，也就是是多少就是多少这种就是Gauges使用类型的代表。

3、Histogram

Histogram用来统计数据的分布情况。例如最大值，最小值，中间值，还有中位数等，这是一种特殊的metrics数据类型，代表的是一种近似的百分比估算数值，

4、Summary

类似于Histogram, 典型的应用如：请求持续时间，响应大小。提供观测值的count和sum功能。提供百分位的功能，即可以按百分比划分跟踪结果。

4.3、instance 和 jobs
被监控的具体目标是instance，监控这些instances的任务叫做job。每个job负责一类任务，可以为一个job配置多个instance，job对自己的instance执行相同的动作。

隶属于job的instance可以直接在配置文件中写死。也可以让job自动从consul、kuberntes中动态获取，这个过程就是prometheus的服务发现。

4.4、什么是Exporter
所有可以向Prometheus提供监控样本数据的程序都可以被称为一个Exporter。而Exporter的一个实例称为target，如下图所示，Prometheus通过轮询的方式定期从这些target中获取样本数据:

从Exporter的来源上来讲，主要分为两类：

 社区提供的
 用户自定义的

1、社区提供的

Prometheus社区提供了丰富的Exporter实现，涵盖了从基础设施，中间件以及网络等各个方面的监控功能。这些Exporter可以实现大部分通用的监控需求。下面列举一些社区中常用的Exporter：

2、用户自定义的

除了直接使用社区提供的Exporter程序以外，用户还可以基于Prometheus提供的Client Library创建自己的Exporter程序，目前Promthues社区官方提供了对以下编程语言的支持：Go、Java/Scala、Python、Ruby。同时还有第三方实现的如：Bash、C++、Common Lisp、Erlang,、Haskeel、Lua、Node.js、PHP、Rust等。

五、Prometheus 安装和配置

5.1、Prometheus server安装和配置

安装Prometheus之前必须要先安装ntp时间同步，因为prometheus server对系统时间的准确性要求很⾼，必须保证本机时间实时同步。这里我们以Centos7为例，先执行时间同步，执行如下计划任务：

[root@localhost ~]# timedatectl set-timezone Asia/Shanghai
[root@localhost ~]# contab -e
* * * * * ntpdate -u cn.pool.ntp.org

1、 Prometheus server下载

⾸先需要到Prometheus官网 http://prometheus.io 下载最新版本的Prometheus，这里我们下载的是prometheus-2.6.1.linux-amd64.tar.gz。

2、安装与启动Prometheus server

prometheus的安装非常简单，只需解压即可，然后执行命令可直接启动。

[root@localhost ~]# tar -xvzf prometheus-2.6.1.linux-amd64.tar.gz
[root@localhost ~]# cd prometheus-2.6.1.linux-amd64
[root@localhost ~]# ./prometheus

启动后，Prometheus UI默认运⾏在9090端口。浏览器可以直接打开访问⽆账号密码验证，如下图所示：

Prometheus UI是Prometheus内置的一个可视化管理界面，通过Prometheus UI用户能够轻松的了解Prometheus当前的配置，监控任务运行状态等。通过Graph面板，用户还能直接使用PromQL实时查询监控数据。

Promtheus作为一个时间序列数据库，其采集的数据会以文件的形似存储在本地中，默认的存储路径为执行命令的当前data目录下，会自动创建，用户也可以通过参数–storage.tsdb.path=”data/“修改本地数据存储的路径。

3、Prometheus server的配置文件

接下来我们来简单看⼀下Prometheus的主配置⽂件prometheus.yml，其实prometheus解压安装之后，就默认自带了⼀个基本的配置文件，简单修改后的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:
       - 127.0.0.1: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','172.16.213.232:9100']

对重要参加介绍如下：

   global是一些常规的全局配置，这里只列出了两个参数：
scrape_interval:     15s      #每15s采集一次数据
evaluation_interval:  15s      #每15s做一次告警检测

   rule_files指定加载的告警规则文件，告警规则放到下面来介绍。

   scrape_configs指定prometheus要监控的目标，这部分是最复杂的。

在scrape_config中每个监控目标是一个job，但job的类型有很多种。可以是最简单的static_config，即静态地指定每一个目标，例如上面的：

- job_name: prometheus

static_configs:

- targets: ['localhost:9090']

这里定义了一个job的名称：job_name: 'prometheus'，然后定义监控节点：

static_configs:

- targets: ['localhost:9090']

这是prometheus本机的一个监控节点，可以继续扩展加入其它需要被监控的节点，例如：

- job_name: 'aliyun'

static_configs:

-   targets: [‘server01:9100’,'IP:9100’,’nginxserver:9100','web006:9100’,'redis:9100','logserver:9100','redis1:9100']

可以看到targets可以并列写入多个节点，用逗号隔开，机器名+端口号，端口号主要是exporters的端口，在这里9100其实是node_exporter的默认端口。配置完成后，prometheus就可以通过配置文件识别监控的节点，持续开始采集数据，prometheus基础配置也就搭建好了。

4、prometheus server的告警规则配置

alert rules一般在单独的文件中定义，然后在prometheus.yml中引用，可以在prometheus.yml文件中看到如下内容：

rule_files:
  # - "first_rules.yml"
  # - "second_rules.yml"

默认first_rules.yml和second_rules.yml都是注释状态，需要去掉前面的“#”，rules文件格式如下：

[root@localhost ~]#cat first_rules.yml
groups:
- name: example
  rules:
  - alert:  InstanceDown
    expr: up == 0
    for: 1m
    labels:
      severity: critical
    annotations:
      summary: Instance has been down for more than 5 minutes

这里介绍下这个规则文件的含义：

在告警规则文件中，我们可以将一组相关的规则设置定义在一个group下。在每一个group中我们可以定义多个告警规则(rule)。一条告警规则主要由以下几部分组成：

 alert：告警规则的名称。
 expr：基于PromQL表达式告警触发条件，用于计算是否有时间序列满足该条件。
 for：评估等待时间，可选参数。用于表示只有当触发条件持续一段时间后才发送告警。在等待期间新产生告警的状态为pending。
 labels：自定义标签，允许用户指定要附加到告警上的一组附加标签。
 annotations：用于指定一组附加信息，比如用于描述告警详细信息的文字等，annotations的内容在告警产生时会一同作为参数发送到Alertmanager。summary描述告警的概要信息，description用于描述告警的详细信息。同时Alertmanager的UI也会根据这两个标签值，显示告警信息。

告警规则配置完成后，需要注意，还要在prometheus.yml中配置alertmanager的地址：

# Alertmanager configuration
alerting:
  alertmanagers:
  - static_configs:
    - targets:
      - 127.0.0.1:9093

这里的“127.0.0.1:9093”就是alertmanager的地址和端口，可以跟prometheus在一台机器，也可以单独部署，alertmanager的部署下面会介绍，重新加载prometheus配置文件后，可以在prometheus的rule页面看到告警规则，在alert页面看到触发的告警。如下图所示：

上图是rule页面看到告警规则以及目前状态，要查看alert页面是否有告警触发，可查看下图页面：

当有告警产生时，就会在这个alters页面出现告警。

5.2、Node exporter 安装

在Prometheus的架构设计中，Prometheus Server并不直接服务监控特定的目标，其主要任务负责数据的收集，存储并且对外提供数据查询支持。因此为了能够监控到某些数据，如主机的CPU使用率，我们需要使用到Exporter。Prometheus周期性的从Exporter暴露的HTTP服务地址（通常是/metrics）拉取监控样本数据。

从上面的描述中可以看出Exporter是一个相对开放的概念，它可以独立运行在要监控的主机上，也可以直接内置在监控目标中。只要能够向Prometheus提供标准格式的监控样本数据即可。

Node exporte主要用于采集被监控主机上的cpu负载，内存的使用情况，网络等数据，并上报数据给Prometheus server。Node_exporter 其实是⼀个以http_server⽅式运⾏在后台，并且持续不断采集 Linux系统中各种操作系统本⾝相关的监控参数的程序，其采集量是很⼤很全的，往往默认的采集项⽬就远超过了我们的实际需求，接下来看看 node_exporter如何安装。

1、Node Exporter安装与基本使用

Node Exporter同样采用Golang编写，并且不存在任何的第三方依赖，只需要下载，解压即可运行。首先从Prometheus官网https://prometheus.io/download/ 下载node_exporter：这里我们下载的版本是node_exporter-0.17.0.linux-amd64.tar.gz ，下载之后解压缩然后直接运⾏即可。
node_exporter的运⾏非常简单，过程如下所示：

[root@localhost ~]# ./node_exporter
source="node_exporter.go:97"
INFO[0000] Listening on :9100                            source="node_exporter.go:111"

运⾏起来以后我们使⽤netstats -tnlp可以来看下 node_exporter进程的状态

[root@localhost ~]# netstat -tnlp | grep node
tcp6       0      0 :::9100                 :::*                    LISTEN      21886/./node_export

这⾥就可以看出 node_exporter默认⼯作在9100端口，要关闭被监控机上的防火墙、selinux等，确保node_exporter可以响应 prometheus_server发过来的HTTP_GET请求，也可以响应其他⽅式的HTTP_GET请求，最简单的方式，在浏览器打开：

http://“node_exporter所在服务器的IP地址”:9100/metrics ，看是否有初始Node Exporter监控指标生成，我这里的node_exporter为172.16.213.232，截图如下：

可以看到，已经有监控指标生成，也可以在prometheus_server上执⾏curl操作，我们看到node_exporter是否能返回大量的这种metrics类型K/V数据。

从上图中可以看出，exporter返回的数据格式如下：

# HELP node_cpu Seconds the cpus spent in each mode.
# TYPE node_cpu counter
node_cpu{cpu="cpu0",mode="idle"} 362812.7890625
# HELP node_load1 1m load average.
# TYPE node_load1 gauge
node_load1 3.0703125

其中HELP用于解释当前指标的含义，TYPE则说明当前指标的数据类型。在上面的例子中node_cpu的注释表明当前指标是cpu0上idle进程占用CPU的总时间，CPU占用时间是一个只增不减的度量指标，从类型中也可以看出node_cpu的数据类型是计数器(counter)，与该指标的实际含义一致。又例如node_load1该指标反映了当前主机在最近一分钟以内的负载情况，系统的负载情况会随系统资源的使用而变化，因此node_load1反映的是当前状态，数据可能增加也可能减少，从注释中可以看出当前指标类型为仪表盘(gauge)，与指标反映的实际含义一致。

除了这些以外，在当前页面中根据物理主机系统的不同，还可能看到如下监控指标：

node_boot_time：系统启动时间
node_cpu：系统CPU使用量
node_disk ：磁盘IO
node_filesystem ：文件系统用量
node_load1：系统负载
node_memory ：内存使用量
node_network ：网络带宽
nodetime：当前系统时间
go：node exporter中go相关指标
process_：node exporter自身进程相关运行指标

2、使用PromQL查询监控数据

PromQL是Prometheus自定义的一套强大的数据查询语言，除了使用监控指标作为查询关键字以为，还内置了大量的函数，帮助用户进一步对时序数据进行处理。

我们可以将上图中返回的metrics直接复制在prometheus server UI的查询命令⾏来查看结果，例如：我们来看一个node_memory_MemFree的数据，此值返回的数据是被监控主机的内存信息，在prometheus server上执行如下命令查看：

[root@localhost ~]# curl http://172.16.213.232:9100/metrics|grep  node_memory_MemFree
# TYPE node_memory_MemFree_bytes gauge
node_memory_MemFree_bytes 4.775989248e+09

可以看到，node_memory_MemFree_bytes此刻的值为4.775989248e+09，将node_memory_MemFree_bytes复制到prometheus的查询命令⾏,就可以看到状态曲线了。如下图所示：

上图是图形展示node_memory_MemFree_bytes的值，也可以在console展示具体数值，如下图所示：

PromQL还内置了大量的函数，例如使用rate()函数，可以计算在单位时间内样本数据的变化情况即增长率，因此通过该函数我们可以查看指定时间内node_load1的状态值，如下图所示：

如果要查看CPU使用率，同时忽略是哪一个CPU，可以使用without表达式，将标签CPU去除后聚合数据即可，PromQL语句如下：

avg without(cpu) (rate(node_cpu_seconds_total[2m]))

Prometheus UI查询截图如下：

如果需要计算系统CPU的总体使用率，通过排除系统闲置的CPU使用率即可获得，PromQL语句如下：

1 - avg without(cpu) (rate(node_cpu_seconds_total{mode="idle"}[3m]))

Prometheus UI查询截图如下：

由此可知，通过PromQL我们可以非常方便的对数据进行查询，过滤，以及聚合，计算等操作。通过这些丰富的表达书语句，监控指标不再是一个单独存在的个体，而是一个个能够表达出正式业务含义的语言。

5.3、Alertmanager 安装和配置

alertmanager是用来接收prometheus发出的告警，然后按照配置文件的要求，将告警用对应的方式发送出去。将告警集中到alertmanager，可以对告警进行更细致的管理。

1、 alertmanager的安装和启动
⾸先需要到Prometheus官网http://prometheus.io 下载最新版本的alertmanager，这里我们下载的是alertmanager-0.16.0.linux-amd64.tar.gz。然后解压即可完成安装，操作如下：

[root@localhost ~]# tar zxvf alertmanager-0.16.0.linux-amd64.tar.gz

解压以后会得到下面这些文件：

[root@localhost app]# cd alertmanager-0.16.0.linux-amd64/
[root@localhost alertmanager-0.16.0.linux-amd64]# ls
alertmanager  alertmanager.yml  amtool  data  LICENSE  NOTICE
[root@localhost alertmanager-0.16.0.linux-amd64]#./alertmanager

其中，alertmanager是启动文件，alertmanager.yml是配置文件，直接运行alertmanager就可以启动alertmanager服务，然后通过http://IP地址:9093/#/alerts 就可以打开alertmanager的页面；如下图所示：

2、alertmanager的配置文件
alertmanager的配置文件alertmanager.yml内容如下：

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']

其中最主要的是receivers，它定义了告警的处理方式，这里是webhook_config，意思是alertmananger将告警转发到这个url。
alertmanager提供多种告警处理方式，webhook_configs只是其中一种，还是如下多种方式：

 email_config
 hipchat_config
 pagerduty_config
 pushover_config
 slack_config
 opsgenie_config
 victorops_config
 webhook_config
 wechat_config

这里以alertmanager配置邮件通知为例，给出一个用邮件通知告警的例子：

global:
  smtp_smarthost: 'mail.xxx.cn:25'  #邮箱smtp服务器
  smtp_from: 'ops@xxx.cn'  #发件用的邮箱地址
  smtp_auth_username: ' ops@xxx.cn'  #发件人账号
  smtp_auth_password:  'xxxxx'  #发件人邮箱密码
  smtp_require_tls: false  #不进行tls验证
route:
  group_by: [alertname]
  group_wait: 10s 
  group_interval: 10s
  repeat_interval: 10m
  receiver: default-receiver
receivers:
 - name: 'default-receiver'
   email_configs:
   - to: 'abc@aaa.com'  #接收告警用的邮箱

alertmanager.yml文件配置完成后，重启alertmanager服务重新加载配置后，就可以测试邮件告警功能了。

六、Prometheus告警功能演示

下面将通过一个具体的实例来演示Prometheus告警功能的使用。在上面的Prometheus配置中，已经配置了Alertmanager主机和告警规则以及告警介质，根据上面设定的告警规则，我们触发这个规则，看是否Prometheus能够监测到并进行邮件告警。

上面定义的alert触发的条件是up为0，那么我们首先通过Prometheus UI查看下正常状态下up值为多少，如下图所示：

通过查询可知，up正常情况下值为1，那么要改变up的值，只需关闭任意一个instance服务即可，也就是关闭node_exporter服务。

这里我们关闭172.16.213.159的node_exporter服务，关闭后，即刻查看up的值，如下图所示：

从图中可以看出，172.16.213.159的instance实例的UP值变为0。
继续查看Prometheus UI中的alters页面，可以发现已经触发了告警，如下图所示：

从图中可以看出，Alert页面中显示InstanceDown，状态为 PENDING。这是因为alert规则中定义需要保持1分钟，所以在这之前，alerts还没有发送至 Alertmanager。1分钟后，状态会由PENDING变为FIRING，如下图所示：

此时，状态变为FIRING，接着登录Alertmanager的ui界面，可以发现有一个触发的告警，如下图所示：

由上可知，当目标失败时，不仅可以在Prometheus的主页上实时的查看目标和alerts的状态，还可以使用Alertmanager发送警告，以便运维人员尽快解决问题。

因为上面配置了邮件告警，所以Alertmanager会调用设置的邮件配置，发送告警邮件，如下图所示：

手动启动node exporter，让UP状态恢复正常，此时查看Prometheus UI，可以看到已经实时更新了alters的状态，Alertmanager也会实时更新消息。如下图所示：

最后查看targets 中每个job的状态，均为UP。如下图所示：

本文对Prometheus的组成、架构和基本概念进行了介绍，并实例演示了node exporter, Prometheus和Alermanager的配置和运行。最后，以一个监控的target的启停为例，演示了Prometheus的一系列响应以及如何在Prometheus和Alertmanager中查看服务、警报和告警的状态。对于Prometheus中更高级的使用，如查询函数的使用，更多图形界面的集成，请参考官方文档。

文档更新时间: 2019-03-28 12:59 作者：李延召

14.下一代基于服务的监控利器Prometheus