Prometheus监控神器-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 之间的重叠，否则很难做到理解与维护，同时建议谨慎使用此功能。使用基于症状的警报时，警报之间很少需要相互依赖。

欢迎大家关注我的公众号ID:k8stech

文章转自公众号：Kubernetes技术栈