在之前的文章中,告警的架构如下

由于我们公司的监控相关内容均是使用的阿里云,包括ECS、RDS、REDIS、MQ,ACK等,所以在目前部署的这一套可观测中,并没有太多监控相关的内容。而现在公司做B端本地化交付的项目越来越多,对于本地化部署的可观测平台需求逐渐显现,为了剥离阿里云,我们需要重新规划监控与告警了。
本篇主要记录我将alertmanager接入到该可观测系统中的步骤,并成功管理告警与通知。其实在之前的篇幅中可以了解到,在没有alertmanager时,我是通过模拟alertmanager的api,实现了一个类似的/api/v2/alerts接口,并且实现了对告警的过滤、去重、限流等等能力,最终将告警发送到钉钉群里。而将alertmanager接入到该平台后,架构也就演变成了如下图

配置
其实在原有的状态下,没有什么需要修改的地方,新增的alertmanager配置如下:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
|
global:
resolve_timeout: "5m"
receivers:
- name: default-receiver
webhook_configs:
- url: https://default.example.com/api/v2/alerts
send_resolved: false
- name: op
webhook_configs:
- url: https://op.example.com/api/v2/alerts
send_resolved: false
- name: od
webhook_configs:
- url: https://od.example.com/api/v2/alerts
send_resolved: false
route:
receiver: 'default-receiver'
group_wait: 30s
group_interval: 5m
repeat_interval: 4h
group_by: [alertname]
routes:
- receiver: 'op'
match:
team: 'op'
- receiver: 'od'
match:
team: 'od'
|
简单描述一下该配置文件,定义了三个receiver,default、op、od,均是webhook,定义了默认receiver:default-receiver,此外根据label匹配指定路由,分为是当告警中含有team:op的发给op的receiver,team:od的发给od的receiver,没有team的发给default。
那么alertmanager是如何找到team参数的呢,大家都知道,Prometheus的rule和loki的rule配置文件格式其实是一样的,下面给出一个loki ruler规则实例配置文件:
1
2
3
4
5
6
7
8
9
10
|
alert: example
annotations:
description: 这是一个description
summary: 这是一个summary
labels:
team: 'op'
expr: |-
sum by(label1,label2,label3)(
count_over_time({job=~"jobname"} | json |~ "argument"[2m])
) > 0
|
与Prometheus的配置只缺少一个for参数,默认为0,表示只要匹配上直接告警,不为0表示持续一段时间后告警。配置完成之后,alertmanager便可以获取到其中的label:team: ‘op’
那么之前的配置中,需要修改的地方,仅有将loki ruler中的配置,修改为alertmanager的地址即可。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
|
......
ruler:
alertmanager_url: http://alertmanager-main.monitoring:9093
enable_alertmanager_v2: true
enable_api: true
enable_sharding: true
flush_period: 1m
rule_path: /var/loki/rules
storage:
s3:
bucketnames: BUCKETNAME
s3: s3://KEY:SECRET@ENDPOINT
type: s3
......
|
到此,alertmanager就成功接入到了可观测平台,负责metrics和loki的告警,后续只需完善告警规则即可。