关于云计算:Prometheus监控神器Alertmanager篇一

本章节次要涵盖了 Alertmanager 的工作机制与配置文件的比拟具体的常识内容，由浅入深的给大家解说。

<!–more–>

警报始终是整个监控零碎中的重要组成部分，Prometheus 监控零碎中，采集与警报是拆散的。警报规定在 Prometheus 定义，警报规定触发当前，才会将信息转发到给独立的组件
Alertmanager，通过 Alertmanager r 对警报的信息处理后，最终通过接收器发送给指定用户，另外在 Alertmanager 中没有告诉组的概念，只能本人对软件从新 Coding，或者应用第三方插件来实现。
留神，这个告诉组不是 Alertmanager 中的 group 概念，上面会具体讲 Group，不要混同哦。

后面曾经介绍过一些对于 Alertmanager 知识点，本章开始针通过装置 Alertmanager 组件，对配置文件做具体阐明，同时介绍 Prometheus 的警报规定的定义，最初应用 Email、Wechat（Robot）、Dingtalk（webhook）来承受警报告诉。

Alertmanager 工作机制

在 Prometheus 生态架构里，警报是由独立的俩局部组成，能够通过上图很清晰的理解到 Prometheus 的警报工作机制。其中 Prometheus 与 Alertmanager 是拆散的俩个组件。咱们应用 Prometheus Server 端通过动态或者动静配置
去拉取 pull 部署在 k8s 或云主机上的各种类别的监控指标数据，而后基于咱们后面讲到的 PromQL 对这些曾经存储在本地存储 HDD/SSD 的 TSDB 中的指标定义阈值警报规定 Rules。Prometheus 会依据配置的参数周期性的对警报规定进行计算，
如果满足警报条件，生产一条警报信息，将其推送到 Alertmanager 组件，Alertmanager 收到警报信息之后，会对正告信息进行解决，进行 分组 Group 并将它们通过定义好的路由 Routing 规定转到 正确的接收器 receiver，
比方 Email Slack 钉钉、企业微信 Robot（webhook） 企业微信 等，最终异样事件 Warning、Error 告诉给定义好的接管人，其中如钉钉是基于第三方告诉来实现的，对于告诉人定义是在钉钉的第三方组件中配置。

在 Prometheus 中，咱们不仅仅能够对单条警报进行命名通过 PromQL定义规定，更多时候是对相干的多条警报进行分组后对立定义。这些定义会在前面阐明与其治理办法。上面开始把 Alertmanager 中的分组 Grouping、克制 Inhibition、提早 Sliences
外围个性进行介绍，便于大家系统性的学习与了解。

AlertManager 的三个概念

分组

Grouping 是 Alertmanager 把同类型的警报进行分组，合并多条警报到一个告诉中。在生产环境中，特地是云环境下的业务之间密集耦合时，若呈现多台 Instance 故障，可能会导致成千上百条警报触发。在这种状况下应用分组机制，
能够把这些被触发的警报合并为一个警报进行告诉，从而防止霎时突发性的承受大量警报告诉，使得管理员无奈对问题进行疾速定位。

举个栗子，在 Kubernetes 集群中，运行着重量级规模的实例，即使是集群中继续很小一段时间的网络提早或者提早导致网络抖动，也会引发大量相似服务利用无奈连贯 DB 的故障。如果在警报规定中定义每一个利用实例都发送警报，那么到最初的后果就是
会有大量的警报信息发送给 Alertmanager。

作为运维组或者相干业务组的开发人员，可能更关怀的是在一个告诉中就能够疾速查看到哪些服务实例被本次故障影响了。为此，咱们对服务所在集群或者服务警报名称的维度进行分组配置，把警报汇总成一条告诉时，就不会受到警报信息的频繁发送影响了。

克制

Inhibition 是 当某条警报曾经发送，进行反复发送由此警报引发的其余异样或故障的警报机制。在生产环境中，IDC 托管机柜中，若每一个机柜接入层仅仅是单台交换机，那么该机柜接入交换机故障会造成机柜中服务器非 up 状态警报。再有服务器上部署的应用服务不可拜访也会触发警报。
这时候，能够通过在 Alertmanager 配置疏忽因为交换机故障而造成的此机柜中的所有服务器及其利用不可达而产生的警报。

在咱们的灾备体系中，当原有集群故障宕机业务彻底无法访问的时候，会把用户流量切换到备份集群中，这样为故障集群及其提供的各个微服务状态发送警报机会失去了意义，此时，Alertmanager 的克制个性就能够在肯定水平上防止管理员收到过多无用的警报告诉。

静默

Sliences 提供了一个简略的机制，依据标签疾速对警报进行静默解决；对传进来的警报进行匹配查看，如果承受到警报合乎静默的配置，Alertmanager 则不会发送警报告诉。

!!! info “”

以上除了分组、克制是在 **Alertmanager** 配置文件中配置，静默是须要在 WEB UI 界面中设置长期屏蔽指定的警报告诉。

以上的概念须要好好了解，这样才能够轻松的在监控零碎设计的时候针对警报设计的一些场景自行调整。

装置 Alertmanager

后面曾经讲过了，咱们能够应用 ansible 中自动化对 Alertmanager 进行装置、配置、启动、更新，这里仅仅只是用 Alertmanager 的二进制装置，以 systemd 治理启动。

## 创立相干目录
mkdir -p /data/alertmanager/{bin,conf,logs,data,templates}
## 下载二进制包，并
wget https://github.com/prometheus/alertmanager/releases/download/v0.21.0/alertmanager-0.21.0.linux-amd64.tar.gz
tar xvf alertmanager-0.21.0.linux-amd64.tar.gz
mv alertmanager-0.21.0.linux-amd64/{alertmanager,amtool} /data/alertmanager/bin/
mv alertmanager-0.21.0.linux-amd64/alertmanager.yml /data/alertmanager/conf/
# 目录构造
/data/alertmanager/
├── bin
│   ├── alertmanager
│   └── amtool
├── conf
│   └── alertmanager.yml
├── data
├── logs
└── templates
## 退出 systemd 启动脚本
cat <<EOF >/lib/systemd/system/alertmanager.service
[Unit]
Description=alertmanager
Documentation=https://prometheus.io/
After=network.target
StartLimitIntervalSec=0

[Service]
Type=simple
User=prometheus
ExecStart=/data/alertmanager/bin/alertmanager --storage.path="/data/alertmanager/data/" \
--config.file=/usr/local/alertmanager/alertmanager.yml \
--web.external-url=http://192.168.1.220 # 此处能够写域名，须要做 proxy。Restart=always
RestartSec=1
# Restart=on-failure

[Install]
WantedBy=multi-user.target
EOF

## 启动
systemctl enable alertmanager
systemctl start alertmanager

Alertmanager 参数

Alertmanager 配置详解

Alertmanager 一个残缺的配置文件范例：

## Alertmanager 配置文件
global:
  resolve_timeout: 5m
  # smtp 配置
  smtp_from: "prom-alert@example.com"
  smtp_smarthost: 'email-smtp.us-west-2.amazonaws.com:465'
  smtp_auth_username: "user"
  smtp_auth_password: "pass"
  smtp_require_tls: true
# email、企业微信的模板配置寄存地位，钉钉的模板会独自讲如果配置。templates:
  - '/data/alertmanager/templates/*.tmpl'
# 路由分组
route:
  receiver: ops
  group_wait: 30s # 在组内期待所配置的工夫，如果同组内，30 秒内呈现雷同报警，在一个组内呈现。group_interval: 5m # 如果组内内容不变动，合并为一条警报信息，5m 后发送。repeat_interval: 24h # 发送报警距离，如果指定工夫内没有修复，则从新发送报警。group_by: [alertname]  # 报警分组
  routes:
      - match:
          team: operations
        group_by: [env,dc]
        receiver: 'ops'
      - match_re:
          service: nginx|apache
        receiver: 'web'
      - match_re:
          service: hbase|spark
        receiver: 'hadoop'
      - match_re:
          serice: mysql|mongodb
        receiver: 'db'
# 接收器
# 克制测试配置
      - receiver: ops
        group_wait: 10s
        match:
          status: 'High'
# ops
      - receiver: ops # 路由和标签，依据 match 来指定发送指标，如果 rule 的 lable 蕴含 alertname，应用 ops 来发送
        group_wait: 10s
        match:
          team: operations
# web
      - receiver: db # 路由和标签，依据 match 来指定发送指标，如果 rule 的 lable 蕴含 alertname，应用 db 来发送
        group_wait: 10s
        match:
          team: db
# 接收器指定发送人以及发送渠道
receivers:
# ops 分组的定义
- name: ops
  email_configs:
  - to: '9935226@qq.com,10000@qq.com'
    send_resolved: true
    headers:
      subject: "[operations] 报警邮件"
      from: "警报核心"
      to: "小煜狼皇"
  # 钉钉配置
  webhook_configs:
  - url: http://localhost:8070/dingtalk/ops/send
    # 企业微信配置
  wechat_configs:
  - corp_id: 'ww5421dksajhdasjkhj'
    api_url: 'https://qyapi.weixin.qq.com/cgi-bin/'
    send_resolved: true
    to_party: '2'
    agent_id: '1000002'
    api_secret: 'Tm1kkEE3RGqVhv5hO-khdakjsdkjsahjkdksahjkdsahkj'

# web
- name: web
  email_configs:
  - to: '9935226@qq.com'
    send_resolved: true
    headers: {Subject: "[web] 报警邮件"} # 接管邮件的题目
  webhook_configs:
  - url: http://localhost:8070/dingtalk/web/send
  - url: http://localhost:8070/dingtalk/ops/send
# db
- name: db
  email_configs:
  - to: '9935226@qq.com'
    send_resolved: true
    headers: {Subject: "[db] 报警邮件"} # 接管邮件的题目
  webhook_configs:
  - url: http://localhost:8070/dingtalk/db/send
  - url: http://localhost:8070/dingtalk/ops/send
# hadoop
- name: hadoop
  email_configs:
  - to: '9935226@qq.com'
    send_resolved: true
    headers: {Subject: "[hadoop] 报警邮件"} # 接管邮件的题目
  webhook_configs:
  - url: http://localhost:8070/dingtalk/hadoop/send
  - url: http://localhost:8070/dingtalk/ops/send

# 抑制器配置
inhibit_rules: # 克制规定
  - source_match: # 源标签警报触发时克制含有指标标签的警报，在以后警报匹配 status: 'High'
      status: 'High'  # 此处的克制匹配肯定在最下面的 route 中配置不然，会提醒找不 key。target_match:
      status: 'Warning' # 指标标签值正则匹配，能够是正则表达式如: ".*MySQL.*"
    equal: ['alertname','operations', 'instance'] # 确保这个配置下的标签内容雷同才会克制，也就是说警报中必须有这三个标签值才会被克制。

global

即为全局设置，在 Alertmanager 配置文件中，只有全局设置配置了的选项，全副为公共设置，能够让其余设置继承，作为默认值，能够子参数中笼罩其设置。其中 resolve_timeout 用于设置解决超时工夫，也是生命警报状态为解决的工夫，
这个工夫会间接影响到警报复原的告诉工夫，须要自行结合实际生产场景来设置主机的复原工夫，默认是 5 分钟。在全局设置中能够设置 smtp 服务，同时也反对 slack、victorops、pagerduty 等，在这里只讲咱们罕用的 Email，钉钉，企业微信，
同时也能够本人应用 go 语言开发的 gubot 进行二次开发，对接自定义 webhook 告诉源。

template

警报模板能够自定义告诉的信息格式，以及其蕴含的对应警报指标数据，能够自定义 Email、企业微信的模板，配置指定的寄存地位，对于钉钉的模板会独自讲如何配置，这里的模板是指的发送的告诉源信息格式模板，比方 Email，企业微信。

route

警报路由模块形容了在收到 Prometheus 生成的警报后，将警报信息发送给接收器 receiver 指定的指标地址规定。Alertmanager 对传入的警报信息进行解决，依据所定义的规定与配置进行匹配。对于路由能够了解为树状构造，
设置的第一个 route 是跟节点，往下的就是蕴含的子节点，每个警报传进来当前，会从配置的跟节点路由进入路由树，依照深度优先从左向右遍历匹配，当匹配的节点后进行，进行警报解决。

!!! info “ 参数形容 ”

| 参数 | 形容 |
| :-----: | :----: |
|`receiver: <string>`| 发送警报的接收器名称 |
|`group_by: ['label_name1,...']`| 依据 prometheus 的 lables 进行报警分组，这些警报会合并为一个告诉发送给接收器，也就是警报分组。|
|`match: [<label_name>: <labelvalue>,...]`| 通过此设置来判断以后警报中是否有标签的 labelname，等同于 labelvalue。|
|`match_re: [<label_name>: <regex>,...]`| 通过正则表达式进行警报配置 |
|`group_wait: [<duration>]|default=30s`| 设置从承受警报到发送的等待时间，若在等待时间中 group 接管到新的警报信息，这些警报会合并为一条发送。|
|`group_interval: [<duration>]|default=5m`| 此设置管制的是 `group` 之间发送警报告诉的间隔时间。|
|`repeat_interval: [<duration>]|default=4h`| 此设置管制的是警报发送胜利当前，没有对警报做解决操作的话，状态 `Firing` 没有变成 `Inactive` 或者 `Pending`，会再次发送警报的的间隔时间。|
|`routes: - <route>`... | 子路由的匹配设置 |

路由匹配规定:

例子：

route:
  receiver: admin # 默认的接收器名称
  group_wait: 30s # 在组内期待所配置的工夫，如果同组内，30 秒内呈现雷同报警，在一个组内呈现。group_interval: 5m # 如果组内内容不变动，5m 后发送。repeat_interval: 24h # 发送报警距离，如果指定工夫内没有修复，则从新发送报警
  group_by: [alertname,cluster]  # 报警分组，依据 prometheus 的 lables 进行报警分组，这些警报会合并为一个告诉发送给接收器，也就是警报分组。routes:
      - match:
          team: ops
        group_by: [env,dc]
        receiver: 'ops'
      - match_re:
          service: nginx|apache
        receiver: 'web'
      - match_re:
          service: mysql|mongodb
        receiver: 'db'
      - match_re:
          service: hbase|spark
        receiver: 'hadoop'

在以上的例子中，默认的警报组全副发送给 admin，且依据路由依照 alertname cluster 进行警报分组。在子路由中的若匹配警报中的标签 team 的值为 ops，Alertmanager 会依照标签 env dc 进行警报分组而后发送给接收器 receiver ops 配置的警报告诉源。
持续匹配的操作是对 service 标签进行匹配，并且配到了 nginx redis mongodb 的值，就会向接收器 receiver web 配置的警报告诉源发送警报信息。

对这种匹配验证操作灰常讲究集体的逻辑思维能力，这不是人干的事件呀~ 因而，Prometheus 公布了一个 Routing tree editor，
用于检测 Alertmanager 的配置文件构造配置信息，而后调试。应用办法很简略，就是把 alertmanager.yml 的配置信念复制到这个站点，而后点击 Draw Routing Tree 按钮生成路由构造树，
而后在 Match Label Set 后面输出以 {<label name> = "<value>"} 格局的警报标签，而后点击 Match Label Set 按钮会显示发送状态图。

以下是通过 routing tree editor 生成的树结构图.

而后咱们能够应用 {service="nginx"} 和 {service="spark"} 表达式来做匹配的规定用于验证其发送告诉源是否为 receiver 中 db 的发送配置。

receiver

接受器是一个统称，每个 receiver 都有须要设置一个全局惟一的名称，并且对应一个或者多个告诉形式，包含 email、微信、Slack、钉钉等。

官网当初满足的配置是：

name: <string>
email_config:
    [- <config>]
hipchat_configs: #此模块配置曾经被移除了
    [<config>]
pagerduty_configs:
    [<config>]
pushover_configs:
    [<config>]
slack_configs:
    [<config>]
opsgenie_configs:
    [<config>]
webhook_configs:
    [<config>]
victorops_configs:
    [<config>]
webchat_configs:
    [<config>]

能够看到 Alertmanager 提供了很多种接收器的告诉配置，咱们能够应用 webhook 接收器来定义告诉集成，反对用户本人定义编写。

官网 receiver 配置

inhibit_rules

inhibit_rules 模块中设置警报克制性能，能够指定在特定条件下须要疏忽的警报条件。能够应用此选项设置首选，比方优先解决某些警报，如果同一组中的警报同时产生，则疏忽其余警报。
正当应用 inhibit_rules，能够缩小频发发送没有意义的警报的产生。

inhibit_rules 配置信息：

trget_match:
     [<label_name>: <labelvalue>,...]
trget_match_re:
     [<label_name>: <labelvalue>,...]
source_match:
     [<label_name>: <labelvalue>,...]
source_match_re:
     [<label_name>: <labelvalue>,...]
[equal: '[' <lable_name>, ...]']

范例：

inhibit_rules: # 克制规定
  - source_match: # 源标签警报触发时克制含有指标标签的警报，在以后警报匹配 status: 'High'
      status: 'High'  # 此处的克制匹配肯定在最下面的 route 中配置不然，会提醒找不 key。target_match:
      status: 'Warning' # 指标标签值正则匹配，能够是正则表达式如: ".*MySQL.*"
    equal: ['alertname','operations', 'instance'] # 确保这个配置下的标签内容雷同才会克制，也就是说警报中必须有这三个标签值才会被克制。

以上示例是指 如果匹配 equal 中的克制的标签值，触发了蕴含 equal 中的标签值的 status: 'High' 警报，则不发送含蕴含 equal 中的标签值的 status: 'Warning' 标签的警报。
这里尽量避免 source_match 与 target_match 之间的重叠，否则很难做到了解与保护，同时倡议审慎应用此性能。应用基于症状的警报时，警报之间很少须要相互依赖。

如果大家有什么好的想法与意见，的能够扫码关注公众号，回复群或者加我微信交换。

本文由博客群发一文多发等经营工具平台 OpenWrite 公布