⭐⭐⭐ Spring Boot 项目实战	⭐⭐⭐ Spring Cloud 项目实战
《Dubbo 实现原理与源码解析 —— 精品合集》	《Netty 实现原理与源码解析 —— 精品合集》
《Spring 实现原理与源码解析 —— 精品合集》	《MyBatis 实现原理与源码解析 —— 精品合集》
《Spring MVC 实现原理与源码解析 —— 精品合集》	《数据库实体设计合集》
《Spring Boot 实现原理与源码解析 —— 精品合集》	《Java 面试题 + Java 学习指南》

摘要: 原创出处 http://www.iocoder.cn/Prometheus/install/ 「芋道源码」欢迎转载，保留摘要，谢谢！

🙂🙂🙂关注**微信公众号：【芋道源码】**有福利：

RocketMQ / MyCAT / Sharding-JDBC 所有源码分析文章列表

RocketMQ / MyCAT / Sharding-JDBC 中文注释源码 GitHub 地址

您对于源码的疑问每条留言都将得到认真回复。甚至不知道如何读源码也可以请教噢。

新的源码解析文章实时收到通知。每周更新一篇左右。

认真的源码交流微信群。

1. 概念

监控平台，是我们不可或缺的组件。随着 Prometheus 的不断发展，国内越来越多的公司，采用 Prometheus + Grafana + Alertmanager 来搭建统一的监控平台。整体架构如下图：

FROM 《Prometheus 文档 —— OVERVIEW》文档

Prometheus Server ：负责从应用、Exporter、Pushgateway 中，采集 Metrics 指标数据，并存储到 TSDB 时序数据库中。
Grafana ：负责从 Prometheus Server 中，读取 Metrics 指标数据，展示监控仪表盘。
Prometheus Alertmanager ：负责接收接收 Prometheus Server 的告警请求，对接到邮箱、钉钉、短信、PagerDuty等等告警方式。

下面，让我们一起来分别搭建下 Prometheus、Grafana、Alertmanager。

2. Prometheus 概念

Prometheus 是什么呢？其文档介绍如下：

FROM 《Prometheus 文档 —— OVERVIEW》

Prometheus is an open-source systems monitoring and alerting toolkit originally built at SoundCloud.
Prometheus 是一个开源的系统监控和报警工具，最初由 SoundCloud 所开发的。

Since its inception in 2012, many companies and organizations have adopted Prometheus, and the project has a very active developer and user community.
自 2012 年启动以来，许多公司和组织都开始采用 Prometheus ，同时该项目拥有一个非常活跃的开发者和用户社区。

It is now a standalone open source project and maintained independently of any company.
现在它是一个独立的开源项目，独立于任何公司进行维护。

To emphasize this, and to clarify the project's governance structure, Prometheus joined the Cloud Native Computing Foundation in 2016 as the second hosted project, after Kubernetes.
为了强调这一点并阐明项目的治理结构，普罗米修斯在 2016 年加入了 CNCF ，成为继 Kubernetes 之后的第二个托管项目。

重点是第一句“开源的系统监控和报警工具”。剩余的，就是告诉大家，不要怕，放心用，我们是社区性的，独立于任何一个公司。

Prometheus 有哪些功能？其文档介绍如下：

FROM 《Prometheus 文档 —— OVERVIEW》

a multi-dimensional data model with time series data identified by metric name and key/value pairs
多维度数据模型，时间序列数据由度量( Metrics )名称和键/值对标识。

PromQL, a flexible query language to leverage this dimensionality
PromQL，一个灵活的查询语言来使用多维度数据模型。

no reliance on distributed storage; single server nodes are autonomous
不依赖分布式存储，单个服务器节点是独立自治的。

time series collection happens via a pull model over HTTP
时间序列( time series )的收集，通过 HTTP 调用，基于拉( pull )模型进行获取。

pushing time series is supported via an intermediary gateway
也可以通过中间件网关，支持推( push )模型来接收时间序列( time series )。

targets are discovered via service discovery or static configuration
通过服务发现或者静态配置，来发现目标服务对象

multiple modes of graphing and dashboarding support
多种模式的绘图和仪表板的支持

看完之后，一脸懵逼是不是？我们可以先简单的理解，Prometheus 是一个自带爬虫功能的数据库，通过 HTTP 请求被监控目标的监控数据。
后续，随着我们搭建和使用 Prometheus 后，会对这些功能的理解，从抽象到具象甚至吊打。

Prometheus 实际是一个生态，包含很多组件。其官网介绍如下：

FROM 《Prometheus 文档 —— OVERVIEW》

the main Prometheus server which scrapes and stores time series data
Prometheus Server ：主程序，负责抓取和存储时序数据。

client libraries for instrumenting application code
client libraries ：客户端库，负责检测应用程序代码。

a push gateway for supporting short-lived jobs
push gateway ：Push 网关，接收短生命周期的 Job 主动推送的时序数据。

special-purpose exporters for services like HAProxy, StatsD, Graphite, etc.
exporters ：为不同服务定制的 Exporter ，为了能够抓取它们的 Metris 指标数据。例如说，HAProxy, StatsD, Graphite 等等。

an alertmanager to handle alerts
alertmanager ：告警管理器，处理不同的告警。

various support tools
其它各种支撑工具。

生态这个东西，总是慢慢了解，不用担心~

3. Prometheus 搭建

哔哔 Prometheus 概念结束，让我们先来搭建一个 Prometheus 服务。

操作系统：macOS 10.14

其它系统，基本一致的。也可以看看《Prometheus 文档 —— INSTALLATION》文档。

3.1 下载

打开 Prometheus 下载页面，选择想要的 Prometheus 版本。这里，我们选择 2.15.0 最新版本。注意，选择对应 OS 的下载地址哈。

# 创建目录
$ mkdir -p /Users/yunai/monitoring
$ cd /Users/yunai/monitoring

# 下载
$ wget https://github.com/prometheus/prometheus/releases/download/v2.15.0/prometheus-2.15.0.darwin-amd64.tar.gz

# 解压
$ tar -zxvf prometheus-2.15.0.darwin-amd64.tar.gz
$ cd prometheus-2.15.0.darwin-amd64

# 查看目录
$ ls- ls
    24 -rw-r--r--@ 1 yunai  staff     11357 Dec 23 22:03 LICENSE
     8 -rw-r--r--@ 1 yunai  staff      3184 Dec 23 22:03 NOTICE
     0 drwxr-xr-x@ 4 yunai  staff       128 Dec 23 22:03 console_libraries
     0 drwxr-xr-x@ 9 yunai  staff       288 Dec 23 22:03 consoles
158776 -rwxr-xr-x@ 1 yunai  staff  81289464 Dec 23 20:13 prometheus # Prometheus 执行程序
     8 -rw-r--r--@ 1 yunai  staff       926 Dec 23 22:03 prometheus.yml # 配置文件
 92704 -rwxr-xr-x@ 1 yunai  staff  47461216 Dec 23 20:15 promtool
 26512 -rwxr-xr-x@ 1 yunai  staff  13572848 Dec 23 20:16 tsdb

3.2 配置文件

Prometheus 通过抓取这些目标上的 HTTP 端点的度量( Metrics )指标，来收集被监控目标的数据。因为 Prometheus 也会以同样的 HTTP 端点的方式暴露自己的度量( Metrics )指标，所以它也可以收集和监控自己的健康状况。

虽然说，Prometheus 服务抓取自己运行所产生的 Metrics 指标，是没有什么意义的。但是，它是一个非常好的入门示例。

默认情况下，prometheus.yml 配置文件，已经配置抓取自身的 Metrics 指标。我们来通过 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']

在 scrape_configs 配置项下，已经设置了一个名字为 prometheus 的 Job 。该 Job 的抓取目标，通过 targets 来设置。其中，'localhost:9090' 就是我们稍后启动 Prometheus 服务的端口 9090。
更多 Prometheus 的配置说明，可见《Prometheus 文档 —— CONFIGURATION》文档。

3.3 启动 Prometheus 服务

执行 nohup ./prometheus --config.file=prometheus.yml & 命令，启动 Prometheus 服务。

执行完成后，我们使用 cat nohup.out 命令，查看下启动日志。如果看到最后一行人如下，说明启动成功。

level=info ts=2019-12-28T16:43:24.999Z caller=main.go:617 msg="Server is ready to receive web requests."

默认情况下，会自动创建 data 数据目录，存储 Prometheus 爬取的 Metrics 指标。

3.4 简单使用

使用浏览器，访问 http://127.0.0.1:9090/ 地址，会自动跳转到 http://127.0.0.1:9090/graph/ 地址，Prometheus 自带的图表功能。如下图所示： Prometheus Graph

点击黄圈「insert metrics at cursor」下拉框，选择 go_gc_duration_seconds 这个 Metrics 指标，然后点击「Execute」按钮，执行查询该指标的数据。结果如下图： Prometheus Graph —— Execute

可以看到 5 条记录。
instance 标签：代表来自哪个抓取目标。这里，就是 Prometheus 服务自身。
job 标签：代表来自哪个 Job。这里，就是我们在「3.2 配置文件」中，设置的 Job。
quantile 标签：GO GC 相关，= = 不是很理解，不过这并不重要。

点击「Graph」Tab 选项，切换到图视图。此时，我们可以看到近一小时的折线图。如下： Prometheus Graph —— Graph

虽然说，Prometheus 自带了 📈 图表功能，不过还是比较基础的。因此，我们更多的使用 Grafana 来制作监控仪表盘。

4. Grafana 概念

Grafana

Grafana 是什么呢？其文档介绍如下：

FROM https://github.com/grafana/grafana

Grafana allows you to query, visualize, alert on and understand your metrics no matter where they are stored.
Grafana 允许我们来查询、可视化、警告和了解我们的 Metrics 指标，无论 Metrics 指标存储在哪里。

Create, explore, and share dashboards with your team and foster a data driven culture。
与我们的团队一起创建，浏览和共享仪表板，并培养数据驱动的文化。

Grafana 有哪些功能？其文档介绍如下：

FROM https://github.com/grafana/grafana

Visualize: Fast and flexible client side graphs with a multitude of options. Panel plugins for many different way to visualize metrics and logs.
可视化：具有多种选项的快速灵活的图表。面板插件支持多种方式来可视化指标( Metrics )和日志( Logs )。

Dynamic Dashboards: Create dynamic & reusable dashboards with template variables that appear as dropdowns at the top of the dashboard.
动态仪表盘：使用模板变量创建动态且可重复使用的仪表板，这些模板变量显示在仪表板顶部。

Explore Metrics: Explore your data through ad-hoc queries and dynamic drilldown. Split view and compare different time ranges, queries and data sources side by side. 浏览指标( Metrics )：通过即席( ad-hoc )查询和动态钻取来浏览数据。拆分视图，并比较不同的时间范围，查询和数据源。

Explore Logs: Experience the magic of switching from metrics to logs with preserved label filters. Quickly search through all your logs or streaming them live.
浏览日志( Logs )：体验使用保留的标签过滤器从指标( Metrics )切换到日志( Logs )的魔力。快速搜索所有日志，或实时流式传输。

Alerting: Visually define alert rules for your most important metrics. Grafana will continuously evaluate and send notifications to systems like Slack, PagerDuty, VictorOps, OpsGenie.
告警：直观地定义最重要指标的警报规则。Grafana 将持续评估并向Slack，PagerDuty，VictorOps，OpsGenie 等系统发送通知。

Mixed Data Sources: Mix different data sources in the same graph! You can specify a data source on a per-query basis. This works for even custom datasources.
混合数据源：在同一图中，混合使用不同的数据源！我们可以基于每个查询指定数据源。这甚至适用于自定义数据源。

简单来说，Grafana 告诉我们它是一个牛逼的可视化仪表盘工具。

5. Grafana 搭建

哔哔 Grafana 概念结束，让我们先来搭建一个 Grafana 服务。

操作系统：macOS 10.14

其它系统，可以看看《Grafana 文档 —— Installing Grafana》文档。

看了下 Grafana 文档，暂时未直接提供 Mac 下的软件包，暂时只推荐使用 brew 进行安装。具体可见《Grafana 文档 —— Installing on macOS》文档。所以，本小节我们就采用该方式。

如果想要在 Linux 下安装，可以考虑到 Grafana 下载页，选择下载 Standalone Linux Binaries 。
如果想要在 Windows 下安装，可以考虑到 Grafana 下载页，选择下载 Windows Installer 或 Standalone Windows Binaries 。

5.1 安装 brew

参考 brew 官网，直接在控制台输入如下命令，即可安装完成。

# 安装 brew
$ /usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"

# 更新 brew 源
brew update

如果 brew update 比较慢，可以参考如下两篇文章来解决：

5.2 安装 Grafana

在控制台输入 brew install grafana 命令即可。整个过程比较慢，请耐心等待。

5.3 配置文件

Grafana 采用 brew 安装之后，其配置文件在 /usr/local/etc/grafana/grafana.ini 下。

默认情况下，我们无需修改配置文件，进行自定义。更多 Prometheus 的配置说明，可见《Grafana 文档 —— Configuration》文档。

5.4 启动 Grafana 服务

执行如下命令，启动 Grafana 服务。

# To start Grafana using homebrew services first make sure homebrew/services is installed.
$ brew tap homebrew/services

# Then start Grafana using:
$ brew services start grafana
==> Successfully started `grafana` (label: homebrew.mxcl.grafana)

默认配置下，Grafana 服务启动在 3000 端口，内置「admin/admin」账号。

5.5 添加 Prometheus 数据源

① 使用浏览器，访问 http://127.0.0.1:3000/ 地址，使用「admin/admin」账号，进行登录。登录完成后，进入 Grafana 首页。界面如下：

② 点击「Add data source」绿色按钮，进入添加数据源界面。界面如下：

③ 点击「Prometheus」选项，进入添加 Prometheus 数据源界面。界面如下：

④ 点击「Save & Test」绿色按钮，完成添加 Prometheus 数据源。成功界面如下：添加 Prometheus 数据源成功

⑤ 点击「Back」按钮返回，可以看到我们刚添加的 Prometheus 数据源。界面如下：数据源列表

5.6 制作 Dashboard

注：dashboard 翻译为，仪表盘。

参考《Grafana 文档 —— Features》文档，我们可以制作 Grafana Dashboard。具体怎么做，胖友先自定看文档，咳咳咳，因为艿艿也不太擅长制作 Dashboard。

不过问题并不大，Grafana 提供了 Dashboard 市场，提供了大量直接可用的 Dashboard 。如下图所示：

考虑到在「3. Prometheus 搭建」中，我们使用 Prometheus 对自身的指标数据进行抓取，所以我们选择 Go Metrics Dashboard。

① 点击 Grafana 最左边的 + 号，选择「Import」菜单，进入 Prometheus 导入 Dashboard 界面。界面如下： Dashboard Import 1

② 设置好 Go Metrics Dashboard 完成后，选择好 Prometheus 数据源。界面如下： Dashboard Import 2

③ 点击「Import」绿色按钮，完成 Dashboard 导入之后，进入该 Dashboard 界面。界面如下： Go Metrics 成品

😈 至此，我们完成了一个 Grafana Dashboard 的制作，虽然是从 Dashboard 市场中导入的，嘿嘿。Dashboard 市场还有很用的，胖友可以自己后续研究研究。

6. Alertmanager 概念

Alertmanager 是什么？其文档介绍如下：

FROM https://prometheus.io/docs/alerting/alertmanager/

The Alertmanager handles alerts sent by client applications such as the Prometheus server.
Alertmanager 处理来自客户端应用程序(如 Prometheus Server)发送的告警请求。

It takes care of deduplicating, grouping, and routing them to the correct receiver integration such as email, PagerDuty, or OpsGenie.
Alertmanager 负责将告警请求去重(deduplicating), 分组, 路由到对应的接收者，通过邮箱、PagerDuty、OpsGenie 等等方式。

It also takes care of silencing and inhibition of alerts.
它还负责告警请求的沉默和禁止警报。

7. Alertmanager 搭建

哔哔 Alertmanager 概念结束，让我们先来搭建一个 Alertmanager 服务。

操作系统：macOS 10.14

其它系统，基本一致的。也可以看看《Alertmanager 文档 —— Install》文档。

7.1 下载

打开 Alertmanager 下载页面，选择想要的 Alertmanager 版本。这里，我们选择 0.20.0 最新版本。注意，选择对应 OS 的下载地址哈。

# 创建目录
$ mkdir -p /Users/yunai/monitoring
$ cd /Users/yunai/monitoring

# 下载
$ wget https://github.com/prometheus/alertmanager/releases/download/v0.20.0/alertmanager-0.20.0.darwin-amd64.tar.gz

# 解压
$ tar -zxvf alertmanager-0.20.0.darwin-amd64.tar.gz
$ cd alertmanager-0.20.0.darwin-amd64

# 查看目录
$ ls- ls
   24 -rw-r--r--@ 1 yunai  staff     11357 Dec 11 22:51 LICENSE
    8 -rw-r--r--@ 1 yunai  staff       457 Dec 11 22:51 NOTICE
52096 -rwxr-xr-x@ 1 yunai  staff  26671536 Dec 11 22:16 alertmanager # Alertmanager 执行程序
    8 -rw-r--r--@ 1 yunai  staff       380 Dec 11 22:51 alertmanager.yml # 配置文件
43680 -rwxr-xr-x@ 1 yunai  staff  22360744 Dec 11 22:17 amtool

7.2 配置文件

现在，我们暂时不修改配置文件 alertmanager.yml ，进行自定义。等到「7.5.4 邮件告警」和「7.5.5 钉钉告警」小节，我们来具体来讲。

更多 Alertmanager 的配置说明，可见《Alertmanager 文档 —— Configuration》文档。

7.3 启动 Alertmanager 服务

执行 nohup ./alertmanager --config.file=alertmanager.yml & 命令，启动 Alertmanager 服务。

执行完成后，我们使用 cat nohup.out 命令，查看下启动日志。如果看到最后一行人如下，说明启动成功。

level=info ts=2019-12-29T01:54:31.410Z caller=main.go:497 msg=Listening address=:9093

默认配置下，Alertmanager 服务启动在 9093 端口。

7.4 简单使用

使用浏览器，访问 http://127.0.0.1:9093/ 地址，进入 Alertmanager 界面。如下图所示： Alertmanager 首页

更多的测试，我们在「7.5.4 邮件告警」和「7.5.5 钉钉告警」小节，进行查看。

7.5 配置 Prometheus 告警规则

Alertmanager 并不负责告警的触发，而是通过 Prometheus 配置告警规则。在 Prometheus 检测到符合告警规则时，会发送告警请求给 Alertmanager 。后续，再由 Alertmanager 通过邮箱、PagerDuty、OpsGenie 等等告警方式，发送给对应的接收者。

7.5.1 配置规则

① 下面，我们来配置一个 Prometheus 的告警规则示例。命令行操作如下：

# 查看当前目录，主要目的是告诉胖友，到 Prometheus 所在目录哈
$ pwd
/Users/yunai/monitoring/alertmanager-0.20.0.darwin-amd64

# 创建 rules 告警规则目录
$ mkdir rules

# 创建 demo.yml 示例告警规则文件 
$ vi rules/demo.yml

具体的 rules/demo.yml 规则如下：

groups:
- name: demo-group # 规则名称
  rules:
  - alert: demo-rule-01 # 告警名称
    expr: up{job="prometheus"} < 2 # 告警条件
    for: 10s # 查询时间间隔
    labels:
      severity: critical # 告警级别
    annotations: # 注释，用于完善告警详情
      summary: "{{$labels.job}}: 示例提示" # 概要
      description: "示例描述" # 描述

这里，我们配置了一条告警规则，如果名字为 "prometheus" 的 Job ，可抓取的处于 UP 状态的目标实例小于 2 ，则触发告警。
显然，我们在「3. Prometheus 搭建」中，只搭建了一个 Prometheus 服务节点，肯定会触发该规则的告警。
更多 Prometheus Alerting Rules 的配置说明，可见《Prometheus 文档 —— ALERTING RULES》文档。

② 使用 vi 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 # ========== <1> ==========

# Load rules once and periodically evaluate them according to the global 'evaluation_interval'.
rule_files:
  # - "first_rules.yml"
  # - "second_rules.yml"
  - rules/*.yml # ========== <2> ==========

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

<1> 处，我们配置 Alertmanager 服务的地址，即「7. Alertmanager 搭建」的地址。
<2> 处，我们配置加载 rules/*.yml 目录下的告警规则文件。

③ 需要让 Prometheus 重新加载配置。命令行操作如下：

# 获得 Prometheus 服务的进程编号
$ ps -ef | grep 'prometheus --config.file=prometheus.yml'
  501 80562     1   0 12:43AM ??         0:53.99 ./prometheus --config.file=prometheus.yml
  
# 通过 kill -HUP pid 的方式，让 Prometheus 重新加载配置
$ kill -HUP 80562

另外，在《如何热加载更新配置?》文章，推荐建议使用 curl -X POST http://IP/-/reload 来重新加载配置。😈 这里，艿艿主要感觉胖友可能并未开启 --web.enable-lifecycle 参数，所以就不采用这种方式。

④ 使用浏览器，访问 http://127.0.0.1:9093/ 地址，进入 Prometheus 首页。点击「Status」菜单，选择「Rules」选项，可以看到所有的 Prometheus 告警规则。如下图所示：

7.5.2 简单测试

使用浏览器，访问 http://127.0.0.1:9090/ 地址，进入 Prometheus 首页。点击「Alerts」菜单，可以看到目前的告警状态。如下图所示： Prometheus Alerts

如果胖友发现该告警规则还未处于「FIRING」状态，可以在耐心等待一会，然后进行刷新。因为，我们配置的告警规则，需要满足 10 秒(通过 for = 10s 配置)。

另外，Grafana Dashboard 市场提供了 Alertmanager Dashboard ，展示 Prometheus Alertmanager 指标。感性的胖友，可以自己导入 Grafana 试试。具体效果，如下图所示：

FROM https://grafana.com/grafana/dashboards/9578

7.5.3 告警方式

Alertmanager 提供了多种告警方式，通过配置不同的接收器。配置方式如下：

下面，我们来尝试如下两种告警方式：

其它告警方式，胖友可以参考如下文章：

企业微信告警：《Prometheus 配置企业微信报警》
短信告警：《Prometheus alertmanager 模块添加短信告警》

7.5.4 邮件告警

考虑到基于邮件，是我们最常用的告警方式，所以在本小节中，我们来搭建一个 Alertmanager 邮件告警的示例。

7.5.4.1 配置邮件告警

① 使用 vi alertmanager.yml 命令，修改 Alertmanager 配置文件的结果如下：

global:
  resolve_timeout: 5m
  # <1> 全局邮箱配置
  smtp_smarthost: 'smtp.126.com:465'
  smtp_from: 'wwbmlhh@126.com'
  smtp_auth_username: 'wwbmlhh@126.com'
  smtp_auth_password: '******'
  smtp_require_tls: false
route:
  group_by: ['alertname']
  group_wait: 10s # 分组等待的时间
  group_interval: 10s # 前后两组发送告警的间隔时间
  repeat_interval: 1h # 重复发送告警时间。默认为 1h
  receiver: 'demo_receiver' # <2> 告警接收器
receivers:
- name: 'demo_receiver' # 示例接收器
  email_configs: # <3> 邮箱接收器
    - to: '7685413@qq.com' # 接收邮箱
      send_resolved: true # 发送已解决通知
inhibit_rules:
  - source_match:
      severity: 'critical'
    target_match:
      severity: 'warning'
    equal: ['alertname', 'dev', 'instance']

该配置文件，我们是在默认配置文件的基础上，进行修改。
<1> 处，配置项 global.smtp_* ，设置全局邮箱。这样，每个 <email_configs /> 标签中，我们就无需重复配置发送的邮箱。😈 当然，如果胖友有需要，也可以在 <email_configs /> 标签中配置。
<2> 处，配置一个名字为 "demo_receiver" 的告警接收器。
<3> 处，给 "demo_receiver" 告警接收器，增加一个邮箱配置，通过 to 配置项来设置接收邮箱。

注意，这里我看到了 route、inhibit_rules 等配置项，涉及到 Alertmanager 分组（Grouping）、抑制（Inhibition）、静默（Silences）相关的知识，胖友可以自己阅读下如下文档：

② 使用 ./amtool check-config alertmanager.yml 命令，检查 alertmanager.yml 配置文件的正确性。如果控制台输出如下结果，说明正常：

Checking 'alertmanager.yml'  SUCCESS
Found:
 - global config
 - route
 - 1 inhibit rules
 - 1 receivers
 - 0 templates

③ 需要让 Alertmanager 重新加载配置。命令行操作如下：

# 获得 Alertmanager 服务的进程编号
$ ps -ef | grep alertmanager
  501 36247 26612   0  9:54AM ttys005    0:39.45 ./alertmanager --config.file=alertmanager.yml
  
# 通过 kill -HUP pid 的方式，让 Alertmanager 重新加载配置
$ kill -HUP 36247

另外，在《Alertmanager 文档 —— MANAGEMENT API》文档，推荐使用 curl -X POST http://IP/-/reload 来重新加载配置。😈 我们在「7.5.5 钉钉告警」中，来进行演示。

④ 使用浏览器，访问 http://127.0.0.1:9093/ 地址，进入 Alertmanager 首页。点击「Status」菜单，可以看到所有的 Alertmanager 配置信息。如下图所示： Alertmanager Config

7.5.4.2 简单测试

打开接收告警的邮箱，我们应该会收到告警邮件。如下图所示： Alertmanager 邮件告警

不过要注意，如果胖友没有收到告警邮件，可能它可能被拦截，当成垃圾邮件了。此时，我们可以去垃圾箱里去瞅瞅。又或者，去发送告警的邮件的发件箱去查查。

如果还是没有，可以到 nohup.out 日志文件中看看是否有错误日志，可能邮箱认证失败，嘿嘿。😈 因为，艿艿一开始输入错了密码，哈哈哈。错误日志示例如下：

level=error ts=2019-12-28T11:09:45.584Z caller=notify.go:372 component=dispatcher msg="Error on notify" err="*email.loginAuth auth: 535 Error: authentication failed" context_err="context deadline exceeded"
level=error ts=2019-12-28T11:09:45.585Z caller=dispatch.go:301 component=dispatcher msg="Notify for alerts failed" num_alerts=1 err="*email.loginAuth auth: 535 Error: authentication failed"

7.5.5 钉钉告警

很多时候，我们会喜欢使用钉钉群机器人发送告警，所以在本小节中，我们来搭建一个 Alertmanager 钉钉告警的示例。

因为 Alertmanager 并未提供钉钉的接收器实现，所以我们需要使用 Alertmanager 的自定义 Webhook 来实现钉钉告警。

不过，钉钉只提供了 GitLab、Github 等内置的机器人，所以我们需要基于钉钉的自定义机器人来实现对 Alertmanager 自定义 Webhook。

当然，这就意味着我们需要做一定的开发。不过，目前已经有 prometheus-webhook-dingtalk 开源项目，提供了基于 Alertmanager Webhook ，生成钉钉告警的功能。

7.5.5.1 创建钉钉群机器人

参考《钉钉群机器人 —— 自定义机器人》文章，我们先来创建一个钉钉群机器人。我们以钉钉 PC 客户端举例子哈。

① 登录钉钉 PC 客户端，窗口右上角点击【头像】，进入”机器人管理“，可对所有机器人进行统一管理。选择最后一个「自定义」机器人。如下图所示：

② 然后，进入“机器人详情”，点击【添加】按钮。之后，进入“添加机器人”，进行添加。如下图所示：

注意，加密的秘钥要复制好进行下保存，稍后会使用到。

③ 最后，点击「确认」按钮，完成机器人的创建。成功如下图所示：添加成功

注意，Webhook 要复制好进行下保存，稍后会使用到。

7.5.5.2 下载 prometheus-webhook-dingtalk

打开 prometheus-webhook-dingtalk 下载页面，选择想要的版本。这里，我们选择 1.4.0 最新版本。注意，选择对应 OS 的下载地址哈。

# 创建目录
$ mkdir -p /Users/yunai/monitoring
$ cd /Users/yunai/monitoring

# 下载
$ wget https://github.com/prometheus/prometheus/releases/download/v2.15.0/prometheus-2.15.0.darwin-amd64.tar.gz

# 解压
$ tar -zxvf prometheus-2.15.0.darwin-amd64.tar.gz
$ cd prometheus-2.15.0.darwin-amd64

# 查看目录
$ ls- ls
   24 -rw-r--r--@ 1 yunai  staff     11358 Dec 11 11:03 LICENSE
    8 -rw-r--r--@ 1 yunai  staff      1194 Dec 11 11:03 config.example.yml # 配置文件示例
    0 drwxr-xr-x@ 3 yunai  staff        96 Dec 11 11:03 contrib
31360 -rwxr-xr-x@ 1 yunai  staff  16052648 Dec 11 10:59 prometheus-webhook-dingtalk # 执行文件

7.5.5.3 配置 prometheus-webhook-dingtalk

① 参考 config.example.yml 示例配置文件，创建 config.yml 配置文件，并编辑其结果如下：

targets:
  webhook1:
    url: https://oapi.dingtalk.com/robot/send?access_token=8b7893e9ad5e0a4375a14417d2e671206d73d96d9c76b7bf318602c253231ea4
    secret: SECcc97654789caf7d95719e0c862506958da62a6ab91a245bb1b1c3b68e66a7c76

我们配置了一个 "webhook1" 地址，用于调用我们在「7.5.5.1 创建钉钉群机器人」创建的机器人的自定义 Webhook 地址。
😈 更丰富的配置，胖友可以后续自己看看 config.example.yml 示例配置文件。

7.5.5.4 启动 prometheus-webhook-dingtalk 服务

执行 nohup ./prometheus-webhook-dingtalk --config.file=config.yml --web.enable-ui & 命令，启动 prometheus-webhook-dingtalk 服务。

默认配置下，prometheus-webhook-dingtalk 服务启动在 8060 端口。
因为我们添加了 --web.enable-ui 参数，开启 Web UI 界面。感兴趣的胖友，可以访问 http://127.0.0.1:8060/ui/ 地址，自己瞅瞅试试。界面如下图：

7.5.5.5 配置钉钉告警

① 使用 vi alertmanager.yml 命令，修改 Alertmanager 配置文件的结果如下：

global:
  resolve_timeout: 5m
  # 全局邮箱配置
  smtp_smarthost: 'smtp.126.com:465'
  smtp_from: 'wwbmlhh@126.com'
  smtp_auth_username: 'wwbmlhh@126.com'
  smtp_auth_password: 'wwb3743'
  smtp_require_tls: false
route:
  group_by: ['alertname']
  group_wait: 10s # 分组等待的时间
  group_interval: 10s # 前后两组发送告警的间隔时间
  repeat_interval: 1h # 重复发送告警时间。默认为 1h
  receiver: 'demo_receiver' # 告警接收器
receivers:
- name: 'demo_receiver' # 示例接收器
  email_configs: # 邮箱接收器
    - to: '7685413@qq.com' # 接收邮箱
      send_resolved: true # 发送已解决通知
  webhook_configs: # webhook 接收器
    - url: http://127.0.0.1:8060/dingtalk/webhook1/send  
      send_resolved: true # 发送已解决通知
inhibit_rules:
  - source_match:
      severity: 'critical'
    target_match:
      severity: 'warning'
    equal: ['alertname', 'dev', 'instance']

该配置文件，我们是在「7.5.4.1 配置邮件告警」的基础上，进行修改。
<4> 处，给 "demo_receiver" 告警接收器，增加一个 webhook 接收器配置，通过 url 配置项来设置为「7.5.5.3 配置 prometheus-webhook-dingtalk」配置的 Webhook 地址。

② 使用 ./amtool check-config alertmanager.yml 命令，检查 alertmanager.yml 配置文件的正确性。如果控制台输出如下结果，说明正常：

Checking 'alertmanager.yml'  SUCCESS
Found:
 - global config
 - route
 - 1 inhibit rules
 - 1 receivers
 - 0 templates

③ 需要让 Alertmanager 重新加载配置。命令行操作如下：

# 使用 Alertmanager MANAGEMENT API
$ curl -X POST curl -X POST http://127.0.0.1:9093/-/reload

④ 使用浏览器，访问 http://127.0.0.1:9093/ 地址，进入 Alertmanager 首页。点击「Status」菜单，可以看到所有的 Alertmanager 配置信息。如下图所示： Alertmanager Config 2

7.5.4.5 简单测试

打开钉钉，我们应该会收到机器人的告警。如下图所示：钉钉告警

如果还是没有，可以到 prometheus-webhook-dingtalk 或 Alertmanager 目录下的nohup.out 日志文件中，看看是否有错误日志。

😈 至此，我们完成了一个 Alertmanager 的快速入门。更多的，胖友可以多多看《Alertmanager 文档》。

8. Grafana Alerting

在最新的 Grafana 版本中，它开始提供 Alerting 告警功能，检测到符合告警规则，并发送告警请求给对应的接收者。也就是说，Grafana Alerting 能够提供 Prometheus + Alertmanager 提供的告警功能。

并且，因为 Grafana 提供了很好的可视化功能，所以可以更加直观的定义告警规则，以及告警方式。

同时，Grafana 除了能够支持 Prometheus 数据源之外，也能够支持 Oracle、MySQL、PostgreSQL、Elasticsearch 等等其它数据源。这就意味着，Grafana 能够基于更多数据源的实现报警。简直美滋滋啊~

下面，让我们一起来感受一下。整个感受过程如下：

1、首先，在「8.1 邮件告警」和「8.2 钉钉告警」小节，配置告警方式
2、然后，在「8.3.1 制作 Dashboard」小节，配置 Grafana 告警规则。
3、最后，在「8.3.2 简单测试」小节，进行一波测试。

8.1 邮件告警

8.1.1 配置全局邮箱

① 首先，使用 vi /usr/local/etc/grafana/grafana.ini 命令，修改 Grafana 配置文件，增加发送监控告警的邮箱。配置示例如下：

#################################### SMTP / Emailing ##########################
[smtp]
# 开启邮箱配置
enabled = true
# 邮箱 host
host = smtp.qq.com:465
# 邮箱 username
user = 7685413@qq.com
# If the password contains # or ; you have to wrap it with triple quotes. Ex """#password;"""
# 邮箱 password
password = ******
;cert_file =
;key_file =
;skip_verify = false
# 来源地址
from_address = 7685413@qq.com
# 来源名字
from_name = Grafana
# EHLO identity in SMTP dialog (defaults to instance_name)
;ehlo_identity = dashboard.example.com

带有 # + 中文注释的，都是艿艿修改过的。胖友可以参考，修改成自己的邮箱。

最早艿艿配置的网易 126 邮箱，一直在 /usr/local/var/log/grafana/grafana.log 日志文件中，看到 Error: authentication failed 报错，认证错误。暂时找不到原因。配置和「7.5.4 邮件告警」小节都是一致的。

所以，后来艿艿换成了腾讯 QQ 邮箱，并使用授权码。注意，要开启 IMAP/SMTP 服务。如下图所示：

② 然后，使用 brew services restart grafana 命令，重启 Grafana 服务，加载 Grafana 新的配置。😈 不同系统，不同安装方式，重启命令不同哈。

$ brew services restart grafana
==> Successfully stopped `grafana` (label: homebrew.mxcl.grafana)
==> Successfully started `grafana` (label: homebrew.mxcl.grafana)

8.1.2 配置邮件告警方式

① 使用浏览器，访问 http://127.0.0.1:9090/ 地址，进入 Grafana 首页。选择左边「铃铛 ICON」菜单，点击「Notification channels」选项，进入 Grafana 通知方式列表界面。如下图所示：

② 点击「Add channel」按钮，进入创建新的通知方式界面。配置邮件告警方式，界面如下图：

③ 点击「Send Test」按钮，进行发送告警邮件的测试，非常方便。打开接收告警的邮箱，我们应该会收到告警邮件。如下图所示： Grafana 邮件告警

如果还是没有，可以到 /usr/local/var/log/grafana/grafana.log 日志文件中看看是否有错误日志，嘿嘿。😈

④ 确认发送测试邮件成功，则点击「Save」按钮，保存配置的邮件告警方式。成功后，重新回到 Grafana 通知方式列表界面。如下图所示： Notification channels 2

至此，我们已经完成了 Grafana 邮件告警方式的配置。

8.2 钉钉告警

8.2.1 创建钉钉群机器人

参考「7.5.5.1 创建钉钉群机器人」小节，创建一个钉钉群机器人。

不过有一点要注意，Grafana 目前配置的钉钉告警方式，暂时不支持钉钉群机器人的**“加密”安全方式，所以胖友请使用“IP地址（段）”**的安全设置，自己的外网 IP 可以去 http://ip138.com/ 看。

8.2.2 配置钉钉告警方式

① 还是老样子，点击「Add channel」按钮，进入创建新的通知方式界面。配置钉钉告警方式，界面如下图：

② 点击「Send Test」按钮，进行发送告警钉钉的测试，非常方便。打开接收钉钉告警的群，我们应该会收到告警提示。如下图所示： Grafana 钉钉告警

③ 确认发送测试钉钉成功，则点击「Save」按钮，保存配置的钉钉告警方式。成功后，重新回到 Grafana 通知方式列表界面。如下图所示： Notification channels 3

至此，我们已经完成了 Grafana 钉钉告警方式的配置。

8.3 告警规则

这个小节，相对会难一丢丢，其实也是很简单的。

8.3.1 制作 Dashboard

① 使用浏览器，访问 http://127.0.0.1:9090/ 地址，进入 Grafana 首页。选择左边「加号 ICON」菜单，点击「Dashboard」选项，进入创建 Dashboard 界面。如下图所示： New dashboard

② 点击「Add Query」按钮，进入制作 Panel 界面。配置一个最简的查询，来制作一个图标。设置查询如下图所示： New panel —— Queries

该查询，和我们在「7.5.1 配置规则」中，在 groups.name.rules.expr 表达式中，配置的查询是一致的。

③ 点击左边最下面「铃铛 ICON」选项，进入 Alert 告警规则配置界面。点击「Create Alert」按钮，设置告警规则如下图所示： New panel —— Alert

😈 加了很多红色标记，胖友仔细看下噢。毕竟不是视频，讲解有点困难。

该告警，和我们在「7.5.1 配置规则」中，总体是一致的。

④ 点击右上角的「文件 ICON」按钮，保存制作的 Dashboard。界面如下图： Save Dashboard

⑤ 保存成功后，我们会自动跳转到该 Dashboard 首页。此时，我们点击 Panel 的「Edit」按钮，继续编辑该 Panel 的查询和告警。如下图所示： Panel Edit Button

⑥ 点击 Panel 的「Edit」按钮之后，我们继续点击左边最下面「铃铛 ICON」选项，进入 Alert 告警规则配置界面。点击右上角的「Test Rule」按钮，快速测试告警规则是否满足。结果如下图所示：

从图中可以看出，目前满足我们配置的告警规则的触发。

至此，我们已经完成了 Grafana 告警规则的配置。下面，我们在「8.3.2 简单测试」中，看看实际的触发效果。

8.3.2 简单测试

① 使用浏览器，访问 http://127.0.0.1:9090/ 地址，进入 Grafana 首页。选择左边「铃铛 ICON」菜单，点击「Alert Rules」选项，进入 Grafana 告警规则列表界面。如下图所示：

此时，我们已经看到刚配置的 "demo-rule-01" 告警规则已经处于「ALERTING」状态，已经触发。如果胖友发现该告警规则还未处于「PENDING」状态，可以在耐心等待一会，然后进行刷新。因为，我们配置的告警规则，需要满足 10 秒(通过 for = 10s 配置)。

② 打开接收告警的邮箱，我们应该会收到告警邮件。如下图所示： Grafana 邮件告警

③ 打开接收钉钉告警的群，我们应该会收到告警提示。但是，实际上，并没有 = =！目前 Grafana v6.5.2 存在 Bug 。在 https://github.com/grafana/grafana/pull/20378 中，可以看到对该 Bug 的描述和修复。

此时，我们打开 /usr/local/var/log/grafana/grafana.log 日志文件，也会发现相应的错误日志。如下：

t=2019-12-28T00:50:38+0800 lvl=eror msg="Failed to send DingDing" logger=alerting.notifier.dingding error="context deadline exceeded" dingding=芋艿贼帅
t=2019-12-28T00:50:38+0800 lvl=eror msg="failed to send notification" logger=alerting.notifier uid=vMKxDGLZk error="context deadline exceeded"

9. Spring Boot 使用示例

在《芋道 Spring Boot 监控平台 Prometheus + Grafana 入门》中，我们来详细学习如何在 Spring Boot 中，整合并使用 Prometheus + Grafana + Alertmanager 。

666. 彩蛋

因为艿艿也是刚开始使用 Prometheus + Grafana + Alertmanager 来搭建平台，所以可能写的比较不专业。😈 如果有错误或难懂的地方，欢迎给艿艿留言哈。

想要进一步深入的胖友，可以阅读如下资料：

TODO 未来补充的

Spring Cloud 使用示例
注册发现
Exporter
- Node
- Nginx
- MySQL
- Redis
- MongoDB
- 等等