AlertManger的详细配置

Prometheus监控平台主要是提供了数据采集和存储功能，如果要根据事件触发告警则需要依赖Alertmanager组件来完成（或者使用Grafana Alerting）

AlertManager支持告警分组，可以将同个分组下的多个告警告警到一封邮件中进行发送，减少骚扰；另外还有告警抑制功能，和Zabbix的告警依赖同理，避免发生某个故障出现后导致其他一系列故障一起告警形成告警风暴的问题；最后还有告警静默功能，让同时间段内的告警不重复发出。邮箱里也会收到告警邮件，同一个分组下的告警事件会整合在一个邮件中

告警状态分为了Inactive（无事件）、Pending（触发阈值，但未满足告警持续时间）、Firing（触发告警）三种，邮箱里也会收到告警邮件，同一个分组下的告警事件会整合在一个邮件中

在Alertmanager中通过路由(Route)来定义告警的处理方式。路由是一个基于标签匹配的树状匹配结构。根据接收到告警的标签匹配相应的处理方式。

Alertmanager主要负责对Prometheus产生的告警进行统一处理，因此在Alertmanager配置中一般会包含以下几个主要部分：

全局配置（global）：用于定义一些全局的公共参数，如全局的SMTP配置，Slack配置等内容；
模板（templates）：用于定义告警通知时的模板，如HTML模板，邮件模板等；
告警路由（route）：根据标签匹配，确定当前告警应该如何处理；
接收人（receivers）：接收人是一个抽象的概念，它可以是一个邮箱也可以是微信，Slack或者Webhook等，接收人一般配合告警路由使用；
抑制规则（inhibit_rules）：合理设置抑制规则可以减少垃圾告警的产生

其完整配置格式如下：

global:
  [ resolve_timeout: <duration> | default = 5m ]
  [ smtp_from: <tmpl_string> ] 
  [ smtp_smarthost: <string> ] 
  [ smtp_hello: <string> | default = "localhost" ]
  [ smtp_auth_username: <string> ]
  [ smtp_auth_password: <secret> ]
  [ smtp_auth_identity: <string> ]
  [ smtp_auth_secret: <secret> ]
  [ smtp_require_tls: <bool> | default = true ]
  [ slack_api_url: <secret> ]
  [ victorops_api_key: <secret> ]
  [ victorops_api_url: <string> | default = "https://alert.victorops.com/integrations/generic/20131114/alert/" ]
  [ pagerduty_url: <string> | default = "https://events.pagerduty.com/v2/enqueue" ]
  [ opsgenie_api_key: <secret> ]
  [ opsgenie_api_url: <string> | default = "https://api.opsgenie.com/" ]
  [ hipchat_api_url: <string> | default = "https://api.hipchat.com/" ]
  [ hipchat_auth_token: <secret> ]
  [ wechat_api_url: <string> | default = "https://qyapi.weixin.qq.com/cgi-bin/" ]
  [ wechat_api_secret: <secret> ]
  [ wechat_api_corp_id: <string> ]
  [ http_config: <http_config> ]

templates:
  [ - <filepath> ... ]

route: <route>

receivers:
  - <receiver> ...

inhibit_rules:
  [ - <inhibit_rule> ... ]

基于标签的告警处理路由
在Alertmanager的配置中会定义一个基于标签匹配规则的告警路由树，以确定在接收到告警后Alertmanager需要如何对其进行处理：

route: <route>

其中route中则主要定义了告警的路由匹配规则，以及Alertmanager需要将匹配到的告警发送给哪一个receiver，一个最简单的route定义如下所示：

route:
  group_by: ['alertname']
  receiver: 'web.hook'
receivers:
- name: 'web.hook'
  webhook_configs:
  - url: 'http://127.0.0.1:5001/'

上面的情况中按照alertname进行分组

在普罗米修斯的预警规则中，上面的HTTPSimulation就是对应的alertname

 

 

如上所示：在Alertmanager配置文件中，我们只定义了一个路由，那就意味着所有由Prometheus产生的告警在发送到Alertmanager之后都会通过名为web.hook的receiver接收。这里的web.hook定义为一个webhook地址。当然实际场景下，告警处理可不是这么简单的一件事情，对于不同级别的告警，我们可能会有完全不同的处理方式，因此在route中，我们还可以定义更多的子Route，这些Route通过标签匹配告警的处理方式，route的完整定义如下：

[ receiver: <string> ]
[ group_by: '[' <labelname>, ... ']' ]
[ continue: <boolean> | default = false ]

match:
  [ <labelname>: <labelvalue>, ... ]

match_re:
  [ <labelname>: <regex>, ... ]

[ group_wait: <duration> | default = 30s ]
[ group_interval: <duration> | default = 5m ]
[ repeat_interval: <duration> | default = 4h ]

routes:
  [ - <route> ... ]

路由匹配
每一个告警都会从配置文件中顶级的route进入路由树，需要注意的是顶级的route必须匹配所有告警(即不能有任何的匹配设置match和match_re)，每一个路由都可以定义自己的接受人以及匹配规则。默认情况下，告警进入到顶级route后会遍历所有的子节点，直到找到最深的匹配route，并将告警发送到该route定义的receiver中。但如果route中设置continue的值为false，那么告警在匹配到第一个子节点之后就直接停止。如果continue为true，报警则会继续进行后续子节点的匹配。如果当前告警匹配不到任何的子节点，那该告警将会基于当前路由节点的接收器配置方式进行处理。

其中告警的匹配有两种方式可以选择：
第一种方式基于字符串验证，通过设置match规则判断当前告警中是否存在标签labelname并且其值等于labelvalue。
第二种方式则基于正则表达式，通过设置match_re验证当前告警标签的值是否满足正则表达式的内容。

如果警报已经成功发送通知, 如果想设置发送告警通知之前要等待时间，则可以通过repeat_interval参数进行设置。

告警分组
Alertmanager可以对告警通知进行分组，将多条告警合合并为一个通知。这里我们可以使用group_by来定义分组规则。基于告警中包含的标签，如果满足group_by中定义标签名称，那么这些告警将会合并为一个通知发送给接收器。

有的时候为了能够一次性收集和发送更多的相关信息时，可以通过group_wait参数设置等待时间，如果在等待时间内当前group接收到了新的告警，这些告警将会合并为一个通知向receiver发送。

而group_interval配置，则用于定义相同的Group之间发送告警通知的时间间隔。

例如，当使用Prometheus监控多个集群以及部署在集群中的应用和数据库服务，并且定义以下的告警处理路由规则来对集群中的异常进行通知。

route:
  receiver: 'default-receiver'
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 4h
  group_by: [cluster, alertname]
  routes:
  - receiver: 'database-pager'
    group_wait: 10s
    match_re:
      service: mysql|cassandra
  - receiver: 'frontend-pager'
    group_by: [product, environment]
    match:
      team: frontend

默认情况下所有的告警都会发送给集群管理员default-receiver，因此在Alertmanager的配置文件的根路由中，对告警信息按照集群以及告警的名称对告警进行分组。

如果告警时来源于数据库服务如MySQL或者Cassandra，此时则需要将告警发送给相应的数据库管理员(database-pager)。这里定义了一个单独子路由，如果告警中包含service标签，并且service为MySQL或者Cassandra,则向database-pager发送告警通知，由于这里没有定义group_by等属性，这些属性的配置信息将从上级路由继承，database-pager将会接收到按cluster和alertname进行分组的告警通知。

而某些告警规则来源可能来源于开发团队的定义，这些告警中通过添加标签team来标示这些告警的创建者。在Alertmanager配置文件的告警路由下，定义单独子路由用于处理这一类的告警通知，如果匹配到告警中包含标签team，并且team的值为frontend，Alertmanager将会按照标签product和environment对告警进行分组。此时如果应用出现异常，开发就能清楚的知道哪一个环境(environment)中的哪一个应用程序出现了问题，可以快速对应用进行问题定位。

邮件报警示例文件：

$ cd /usr/local/alertmanager
$ vim alert-test.yml
global:
  smtp_smarthost: 'smtp.163.com:25'
  smtp_from: 'xxx@163.com'
  smtp_auth_username: 'xxx@163.com'
  smtp_auth_password: 'xxxxxx' # 邮箱的授权密码
  smtp_require_tls: false
templates:
  - '/alertmanager/template/*.tmpl'
route:
  group_by: ['alertname', 'cluster', 'service']
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 10m
  receiver: default-receiver
receivers:
- name: 'default-receiver'
  email_configs:
  - to: 'xxx@qq.com'
    html: '{ alert.html }'
    headers: { Subject: "Prometheus[WARN] Test报警邮件" }

上面的整个文章相当的经典呀：文章转载自：https://www.it610.com/article/1293773140849139712.htm

文章2：https://www.yzlfxy.com/jiaocheng/jbbc/334586.html

Prometheus监控平台主要是提供了数据采集和存储功能，如果要根据事件触发告警则需要依赖Alertmanager组件来完成（或者使用Grafana Alerting）。AlertManager支持告警分组，可以将同个分组下的多个告警告警到一封邮件中进行发送，减少骚扰；另外还有告警抑制功能，和Zabbix的告警依赖同理，避免发生某个故障出现后导致其他一系列故障一起告警形成告警风暴的问题；最后还有告警静默功能，让同时间段内的告警不重复发出。

二、安装与配置Alertmanager

在Prometheus官网下载好二进制安装包并解压，通过alertmanager.yml文件就可以进行告警分组、告警路由、告警抑制、告警静默等配置。下面是一个不带告警分组与路由的最基本配置说明：

global:
02
  resolve_timeout: 5m #持续5分钟没收到告警信息后认为问题已解决
03
  smtp_smarthost: 'smtp.qq.com:465'  #告警邮件发送者SMTP地址
04
  smtp_from: '13841276@qq.com'  #发件者邮箱
05
  smtp_auth_username: 'tanglu'  #账号
06
  smtp_auth_password: '123456'  #邮箱专用授权码，不是QQ登录密码，在QQ邮箱中设置
07
  smtp_require_tls: false  #关闭tls授权
08
 
09
route:  #定义告警路由规则，可以定义多个receiver和group实现告警分组
10
  group_by: ['test_group']  #分组配置，在Prometheus的rules中进行分组的定义，一个分组内的告警会在一个邮件中
11
  group_wait: 10s  #分组等待时间，可以理解为将10秒内的相同事件作为一个分组，如果太短分组就没有意义
12
  receiver: 'ops'  #告警接受者，具体信息将在receivers区域中配置
13
 
14
receivers:  #告警邮件接受者配置部分
15
- name: 'ops'  #和上面route部分中的receiver一致，这里是定义具体的动作
16
  email_configs:  #接收器为email，除此还有其他接收器可以使用
17
  - to: '13841276@qq.com'  #告警邮件发送对象
18
    send_resolved: true  #接收告警恢复邮件
19
 
20
#告警抑制配置。如下配置表示发生多个告警时如果它们node标签的值相同，那么产生critical级别的告警就不对warning级别告警进行通知，告警级别的标签是在Prometheus的rules中定义
21
inhibit_rules: 
22
  - source_match:
23
      severity: 'critical' 
24
    target_match:
25
      severity: 'warning'
26
    equal:
27
      - node

2、Alertmanager路由与告警分组设置

当有告警事件发生时都会从配置文件中顶级的route开始路由，每一个路由都可以定义接受人以及匹配规则。如果route中设置continue的值为false，那么告警在匹配到第一个子节点之后就停止继续匹配。如果continue为true则会继续进行后续匹配。如果当前告警匹配不到任何的子节点，那该告警将会基于当前路由节点的接收器配置方式进行处理。告警匹配可以基于字符串或者基于正则表达式完成

global:
  resolve_timeout: 5m
  smtp_smarthost: 'smtp.qq.com:465'
  smtp_from: '13841276@qq.com'
  smtp_auth_username: '13841276'
  smtp_auth_password: 'mtdvgvofyfgybzae'
  smtp_require_tls: false

route:  #默认路由
  group_by: ['instance','job']  
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 4h  #重复告警间隔
  receiver: 'email'  #默认接受者
  routes:  #子路由，不满足子路由的都走默认路由
  - match:  #普通匹配
      severity: critical 
    receiver: leader
  - match_re:  #正则匹配
      severity: ^(warning|critical)$
    receiver: ops

receivers:  #定义三个接受者，和上面三个路由对应
- name: 'email'
  email_configs:
  - to: '13841276@qq.com'
- name: 'leader'
  email_configs:
  - to: '88888@qq.com'
- name: 'ops'
  email_configs:
  - to: 'ops@qq.com'

3、使用amtool检查配置文件语法

./amtool check-config alertmanager.yml
4、启动alertmanager，服务启动后默认监听在9093端口，可以直接访问该端口看到一些配置信息，静默配置也是在这个界面做操作
./alertmanager --config.file=alertmanager.yml

二、Prometheus配置部分

1、修改prometheus.yml的alerting部分，让alertmangers能与Prometheus通信

alerting:
  alertmanagers:
    - static_configs:
      - targets:
        - 192.168.1.100:9093

rule_files:  #指定告警规则的配置路径
    - "rules/*.yml"

scrape_configs:
  - job_name: 'alertmanager' 
    static_configs: 
      - targets: ['192.168.1.100:9093']

2、在Prometheus配置中添加具体告警规则。为了使告警信息具有更好的可读性，Prometheus支持使用变量来获取指定标签中的值。比如$labels.<labelname>变量可以访问当前告警实例中指定标签的值。$value可以获取当前PromQL表达式计算的样本值。在创建规则文件时，建议为不同对象建立不同的文件，比如web.yml、mysql.yml

vim  /etc/prometheus/rules/node_alerts.yml 
groups: 
- name: node_alerts #告警分组，一个组下的告警会整合在一个邮件中
  rules: 
  - alert: CPU usage high  #定义告警事件名
    expr: node_cpu:avg_rate 5m > 4  #报警表达式 
    for: 1m  #事件持续时长，0的话代表一满足就触发
    labels: 
      severity: warning  #定义了一个标签用于以后告警分组
    annotations:  #邮件中的注释内容，可以引用变量
      summary: "Instance {{ $labels.instance }} CPU usgae high"  #summary概要信息
      description: "{{ $labels.instance }} CPU usage above 85% (current value: {{ $value }})"  #description详细信息

3、当报警触发后访问9093端口可以看到具体的信息以及告警状态，告警状态分为了Inactive（无事件）、Pending（触发阈值，但未满足告警持续时间）、Firing（触发告警）三种，邮箱里也会收到告警邮件，同一个分组下的告警事件会整合在一个邮件中

 

 

 

教程2：

https://www.yzlfxy.com/jiaocheng/jbbc/334586.html

 

Alertmanager 主要用于接收 Prometheus 发送的告警信息，它很容易做到告警信息的去重，降噪，分组，策略路由，是一款前卫的告警通知系统。它支持丰富的告警通知渠道，可以将告警信息转发到邮箱、企业微信、钉钉等。这一节讲解利用AlertManager，把接受到的告警信息，转发到邮箱。

启动添加了参数 --web.enable-lifecycle，让Prometheus支持通过web端点动态更新配置。

访问http://127.0.0.1:9090/targets ，Prometheus 自身的 metrics 和 http-simulator 的 metrics 处于up 状态 ，那么准备工作就做好了。

 

 

实验

实验1

告警配置

在prometheus-data文件夹下，创建告警配置文件 simulator_alert_rules.yml：

groups:
- name: simulator-alert-rule
 rules:
 - alert: HttpSimulatorDown
  expr: sum(up{job="http-simulator"}) == 0
  for: 1m
  labels:
   severity: critical

上面配置的 - alert: HttpSimulatorDown中中的HttpSimulatorDown的值对应的就是alertManger中的alertname，配置文件的意思是 http-simulator 服务up状态为 0 ，并且持续1分钟时，产生告警 ，级别为 “严重的”。for: 0如果写成0表示产生预警马上发送

修改prometheus.yml，引用simulator_alert_rules.yml文件，prometheus.yml 内容如下：

global:
 scrape_interval: 5s
 evaluation_interval: 5s
 scrape_timeout: 5s
rule_files:
 - "simulator_alert_rules.yml"
scrape_configs:
 - job_name: 'prometheus'
  static_configs:
  - targets: ['localhost:9090']
 - job_name: 'http-simulator'
  metrics_path: /metrics
  static_configs:
  - targets: ['192.168.43.121:8080']

更新Prometheus配置：

访问http://127.0.0.1:9090/config，可以看到已经为更新了配置：

 

 

访问http://127.0.0.1:9090/rules，Rules 下出现了新添加的告警规则：

 

 

验证

访问http://127.0.0.1:9090/alerts ，Alerts 下 HttpSimulatorDown 为绿色，处于INACTIVE 状态，表示什么都没有发生。

 

 关闭 http-simulator 服务：

访问http://127.0.0.1:9090/alerts，HttpSimulatorDown 变成黄色，处于 PENDING 状态，表示报警即将被激活。

 

 因为上面设置了for：1m需要down的状态持续1分钟，才变成发送预警通知

一分钟后，HttpSimulatorDown 变成红色，处于 FIRING 状态，表示报警已经被激活了。

 

 

实验2

告警配置

在simulator_alert_rules.yml文件中增加告警配置：

- alert: ErrorRateHigh
  expr: sum(rate(http_requests_total{job="http-simulator", status="500"}[5m])) / sum(rate(http_requests_total{job="http-simulator"}[5m])) > 0.02
  for: 1m
  labels:
   severity: major
  annotations:
   summary: "High Error Rate detected"
   description: "Error Rate is above 2% (current value is: {{ $value }}"

配置文件的意思是 http-simulator 请求的错误率对2% ，并且持续1分钟时，产生告警 ，级别为 “非常严重的”

更新Prometheus配置：

curl -X POST http://localhost:9090/-/reload



验证

访问http://127.0.0.1:9090/alerts，ErrorRateHigh 为绿色的 INACTIVE 状态。

 

 

把 http-simulator 的错误率调到 10%

 

稍等一会后，访问http://127.0.0.1:9090/alerts， 可以看到错误率已经大2%，ErrorRateHigh 为红色的 FIRING 状态，报警已经被激活了。

 

 

 

安装和配置AlertManager

通过docker 挂载文件的方式安装AlertManager，在本地创建文件夹 alertmanager-data 文件夹，在其中创建 alertmanager.yml，内容如下：

通过docker 挂载文件的方式安装AlertManager，在本地创建文件夹 alertmanager-data 文件夹，在其中创建 alertmanager.yml，内容如下：

global:
 smtp_smarthost: 'smtp.163.com:25'
 smtp_from: 'xxxxx@163.com'
 smtp_auth_username: 'xxxxx@163.com'
 smtp_auth_password: 'xxxxx'

route:
 group_interval: 1m  #当第一个报警发送后，等待'group_interval'时间来发送新的一组报警信息
 repeat_interval: 1m  # 如果一个报警信息已经发送成功了，等待'repeat_interval'时间来重新发送他们
 receiver: 'mail-receiver'
receivers:
- name: 'mail-receiver'
 email_configs:
  - to: 'xxxxxx@163.com'

在16点01分01秒的的时候收到了指标A的报警，这个时候alertManger就将报警发送出去了

因为设置了group_interval: 1m，设置了1m，在16点01分01秒到6点01分59秒内，收到了指标1到指标1000，一共1000条告警信息，一共1000个指标的监控，这1000条告警信息都属于同一分组，这个时候会将这1000条告警信息以一个邮件发送给消费者，不会给消费者发送1000条邮件

在16点01分01秒的的时候收到了指标A的报警

repeat_interval: 1m  # 如果一个报警信息已经发送成功了，等待'repeat_interval'时间来重新发送他们

如果在在16点01分01秒到6点01分59秒内，又收到了多条指标A的告警信息，这个时候都在1m中之内，这个时候都不会将告警信发送给客户，这1秒中之内的告警信息都被被丢弃，如果在16点02分01秒又收到了指标A的信息，这个时候会继续发送指标A的预警消息

 

第三个参数的作用：

 resolve_timeout: 5m #持续5分钟没收到告警信息后认为问题已解决的作用

group_interval：3m

这里发送的间隔设置为3分钟，相同的发送间隔为3分钟。alertManger这里在如果在在16点00分发送了预警消息，
接下来如果普罗米修斯的预警一直产生，
alertManger这里在如果在在16点03分再次发送了预警消息，如果普罗米修斯的预警海没有解决，
alertManger这里在如果在在16点06分再次发送了预警消息，这里有个特殊情况，
普罗新修斯和alertManger的网络发送了问题，普罗米修斯发送告警消息无法发送给alertManger，
alertManger这里在如果在在16点00分发送了预警消息,在接下来的5分钟之内一直都没有收到普罗米修斯的告警信息，alertManger因为设置了 resolve_timeout: 5m
这里已经超过了5分钟没有收到普罗米修斯的告警消息，alertManger做了处理认为普罗米修斯的预警已经解决了，alertManger会发送一个预警消息resloved的状态的通知，这里要注意
alertManger不是在16点05分发送了预警消息resolved的通知给客户，相当于alertManger在16：05分产生了一个reloved的消息，但是这个消息要在在16点06分才发送，因为这里group_interval设置了alertManger发送的间隔是3分钟发送一次。这里相当的经典呀



 

posted on 2021-06-24 20:34  luzhouxiaoshuai  阅读(8924)  评论(0)  编辑  收藏  举报

导航