Alertmanager处理客户端应用程序(如Prometheus服务器)发送的警报。 它负责对它们进行重复数据删除,分组和路由,以及正确的接收器集成,例如电子邮件,PagerDuty或OpsGenie。 它还负责警报的静音和抑制。
安装部署
获取二进制包
Alertmanager最新版本的下载地址可以从Prometheus官方网站https://prometheus.io/download/获取。
1 | export VERSION=0.18.0 |
启动
1 | cd alertmanager-$VERSION.darwin-amd64 |
获取docker镜像
1 | docker pull docker.io/prometheus/alertmanager |
启动
1 | docker run -d -p 9093:9093 -v /本地目录/alertmanager.yml:/etc/alertmanager/config.yml --name alertmanager docker.io/prom/alertmanager --config.file=/etc/alertmanager/config.yml |
配置
- 全局配置(global):用于定义一些全局的公共参数,如全局的SMTP配置,Slack配置等内容;
- 模板(templates):用于定义告警通知时的模板,如HTML模板,邮件模板等;
- 告警路由(route):根据标签匹配,确定当前告警应该如何处理;
- 接收人(receivers):接收人是一个抽象的概念,它可以是一个邮箱也可以是微信,Slack或者Webhook等,接收人一般配合告警路由使用;
- 抑制规则(inhibit_rules):合理设置抑制规则可以减少垃圾告警的产生
完整配置格式如下:
1 | global: |
在全局配置中需要注意的是resolve_timeout
,该参数定义了当Alertmanager持续多长时间未接收到告警后标记告警状态为resolved(已解决)。该参数的定义可能会影响到告警恢复通知的接收时间,可根据自己的实际场景进行定义,其默认值为5分钟。
基于标签的告警处理路由
在Alertmanager的配置中会定义一个基于标签匹配规则的告警路由树,以确定在接收到告警后Alertmanager需要如何对其进行处理:
route: <route>
route中主要定义了告警路由的匹配规则,以及Alertmanager需要将匹配到的告警发送给哪个receiver
简单的route定义示例:
1 | route: |
在上面的Alertmanager配置文件中,只定义了一个路由,那就意味着所有由Prometheus产生的告警在发送到Alertmanager之后都会通过名为web.hook的receiver接收。这里的web.hook定义为一个webhook地址。
在实际场景下,告警处理没有这么简单,所以我们可以在route中,定义更多的子route,这些route通过标签匹配告警的处理方式。
route的完整定义如下:
1 | [ receiver: <string> ] |
每一个告警都会从配置文件中顶级route进入路由树,顶级route必须匹配所有告警(即不能有任何的匹配设置:match、match_re,每一个route都可以定义自己的receiver以及匹配规则。默认情况下,告警进入顶级route后会遍历所有的子节点,直到找到最深的匹配route,并将告警发送到route定义的receiver中。如何route中设置continue为false,那么告警在匹配到第一个子节点之后就直接停止。如何当前告警匹配不到任何的子节点,那该告警将会基于当前路由节点的receiver配置方式进行处理。
match与match_re
告警的匹配有两种方式可以选择。一种方式基于字符串验证,通过设置match规则判断当前告警中是否存在标签labelname并且其值等于labelvalue。第二种方式则基于正则表达式,通过设置match_re验证当前告警标签的值是否满足正则表达式的内容。
repeat_interval
如果警报已经成功发送通知, 如果想设置发送告警通知之前要等待时间,则可以通过repeat_interval参数进行设置。
group_by
Alertmanager可以对告警通知进行分组,将多条告警合合并为一个通知。可以使用group_by来定义分组规则。基于告警中包含的标签,如果满足group_by中定义标签名称,那么这些告警将会合并为一个通知发送给接收器。
group_wait
有的时候为了能够一次性收集和发送更多的相关信息时,可以通过group_wait参数设置等待时间,如果在等待时间内当前group接收到了新的告警,这些告警将会合并为一个通知向receiver发送。
group_interval
用于定义相同的Gourp之间发送告警通知的时间间隔。
抑制机制(inhibit_rules)
Alertmanager的抑制机制可以避免当某种问题告警产生之后用户接收到大量由此问题导致的一系列的其它告警通知。
参考:抑制机制
示例
1 | route: |
默认情况下所有的告警都会发送给集群管理员default-receiver,因此在Alertmanager的配置文件的根路由中,对告警信息按照集群以及告警的名称对告警进行分组。
如果告警时来源于数据库服务如MySQL或者Cassandra,此时则需要将告警发送给相应的数据库管理员(database-pager)。这里定义了一个单独子路由,如果告警中包含service标签,并且service为MySQL或者Cassandra,则向database-pager发送告警通知,由于这里没有定义group_by等属性,这些属性的配置信息将从上级路由继承,database-pager将会接收到按cluser和alertname进行分组的告警通知。
而某些告警规则来源可能来源于开发团队的定义,这些告警中通过添加标签team来标示这些告警的创建者。在Alertmanager配置文件的告警路由下,定义单独子路由用于处理这一类的告警通知,如果匹配到告警中包含标签team,并且team的值为frontend,Alertmanager将会按照标签product和environment对告警进行分组。此时如果应用出现异常,开发团队就能清楚的知道哪一个环境(environment)中的哪一个应用程序出现了问题,可以快速对应用进行问题定位。
接入slack
- 最好使用一个单独的slack channel来接收报警信息
- 在channel中添加应用:Incomming Webhooks
- 为了能够在Monitoring中接收来自Alertmanager的消息,我们需要在Channel的设置选项中使用”Add an App”为Monitoring channel添加一个名为
Incoming WebHooks
的应用:
添加成功后Slack会显示Incoming WebHooks
配置和使用方式,支持修改消息头像、名字,添加链接,普通文本等
Alertmanager配置
在Alertmanager的全局配置中,将Incomming Webhhook地址作为slack_api_url添加到全局配置中
1 | global: |
也可以在每个receiver中单独定义自己的slack_configs:
1 | receivers: |
对于Incomming Webhook支持的自定义参数有:
1 | channel: <tmpl_string> |
更多参数说明参考:Incomming Webhook参数说明
示例
alertmanager配置文件:
1 | global: |
会收到如下图片所示告警
Reference
https://yunlzheng.gitbook.io/prometheus-book/parti-prometheus-ji-chu/alert