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 = "alert.victorops/integrations/generic/20131114/alert/" ]
[ pagerduty_url: <string> | default = "events.pagerduty/v2/enqueue" ]
[ opsgenie_api_key: <secret> ]
[ opsgenie_api_url: <string> | default = "api.opsgenie/" ]
[ hipchat_api_url: <string> | default = "api.hipchat/" ]
[ hipchat_auth_token: <secret> ]
[ wechat_api_url: <string> | default = "qyapi.weixin.qq/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: '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
$ l
global:
smtp_smarthost: 'smtp.163:25'
smtp_from: 'xxx@163'
smtp_auth_username: 'xxx@163'
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'
html: '{ alert.html }'
headers: { Subject: "Prometheus[WARN] Test报警邮件" }
正则匹配一个或连续多个Prometheus监控平台主要是提供了数据采集和存储功能，如果要根据事件触发告警则需要依赖Alertmanager组件来完成（或者使⽤Grafana Alerting）。AlertManager⽀持告警分组，可以将同个分组下的多个告警告警到⼀封邮件中进⾏发送，减少骚扰；另外还有告警抑制功能，和Zabbix的告警依赖同理，避免发⽣某个故障出现后导致其他⼀系列故障⼀起告警形成告警风暴的问题；最后还有告警静默功能，让同时间段内的告警不重复发出。
⼆、安装与配置Alertmanager
在Prometheus官⽹下载好⼆进制安装包并解压，通过l⽂件就可以进⾏告警分组、告警路由、告警抑制、告警静默等配置。下⾯是⼀个不带告警分组与路由的最基本配置说明：
global:
02
resolve_timeout: 5m #持续5分钟没收到告警信息后认为问题已解决
03
smtp_smarthost: 'smtp.qq:465'  #告警邮件发送者SMTP地址
04
smtp_from: '13841276@qq'  #发件者邮箱
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'  #告警邮件发送对象
18
send_resolved: true  #接收告警恢复邮件
19
20
#告警抑制配置。如下配置表⽰发⽣多个告警时如果它们node标签的值相同，那么产⽣critical级别的告警就不对warning级别告警进⾏通知，告警级别的标签是在Prometheus的rules中定义
21
inhibit_rules:
22
- source_match:
23
severity: 'critical'
24
target_match:
equal:
27
- node
2、Alertmanager路由与告警分组设置
当有告警事件发⽣时都会从配置⽂件中顶级的route开始路由，每⼀个路由都可以定义接受⼈以及匹配规则。如果route中
设置continue的值为false，那么告警在匹配到第⼀个⼦节点之后就停⽌继续匹配。如果continue为true则会继续进⾏后续匹配。如果当前告警匹配不到任何的⼦节点，那该告警将会基于当前路由节点的接收器配置⽅式进⾏处理。告警匹配可以基于字符串或者基于正则表达式完成
global:
resolve_timeout: 5m
smtp_smarthost: 'smtp.qq:465'
smtp_from: '13841276@qq'
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'
- name: 'leader'
email_configs:
- to: '88888@qq'
- name: 'ops'
email_configs:
- to: 'ops@qq'
3、使⽤amtool检查配置⽂件语法
.
/amtool l
4、启动alertmanager，服务启动后默认监听在9093端⼝，可以直接访问该端⼝看到⼀些配置信息，静默配置也是在这个界⾯做操作
./alertmanager --config.l
⼆、Prometheus配置部分
1、修改l的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表达式计算的样本值。在创建规则⽂件时，建议为不同对象建⽴不同的⽂件，⽐如l、l
vim  /etc/prometheus/rules/l
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：
Alertmanager 主要⽤于接收 Prometheus 发送的告警信息，它很容易做到告警信息的去重，降噪，分组，策略路由，是⼀款前卫的告警通知系统。它⽀持丰富的告警通知渠道，可以将告警信息转发到邮箱、企业、钉钉等。这⼀节讲解利⽤AlertManager，把接受到的告警信息，转发到邮箱。
启动添加了参数 --able-lifecycle，让Prometheus⽀持通过web端点动态更新配置。
实验
实验1
告警配置
在prometheus-data⽂件夹下，创建告警配置⽂件 simulator_l：
- 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表⽰产⽣预警马上发送
修改l，引⽤simulator_l⽂件，l 内容如下：
global:
scrape_interval: 5s
evaluation_interval: 5s
scrape_timeout: 5s
rule_files:
- "simulator_l"
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-simulator 服务：
因为上⾯设置了for：1m需要down的状态持续1分钟，才变成发送预警通知
⼀分钟后，HttpSimulatorDown 变成红⾊，处于 FIRING 状态，表⽰报警已经被激活了。
实验2
告警配置
在simulator_l⽂件中增加告警配置：
- 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 localhost:9090/-/reload
验证
把 http-simulator 的错误率调到 10%
安装和配置AlertManager
通过docker 挂载⽂件的⽅式安装AlertManager，在本地创建⽂件夹 alertmanager-data ⽂件夹，在其中创建 l，内容如下：
通过docker 挂载⽂件的⽅式安装AlertManager，在本地创建⽂件夹 alertmanager-data ⽂件夹，在其中创建 l，内容如下：
global:
smtp_smarthost: 'smtp.163:25'
smtp_from: 'xxxxx@163'
smtp_auth_username: 'xxxxx@163'
smtp_auth_password: 'xxxxx'
route:
group_interval: 1m  #当第⼀个报警发送后，等待'group_interval'时间来发送新的⼀组报警信息
repeat_interval: 1m  # 如果⼀个报警信息已经发送成功了，等待'repeat_interval'时间来重新发送他们
receiver: 'mail-receiver'
email_configs:
- to: 'xxxxxx@163'
在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分钟发送⼀次。这⾥相当

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。