Alertmanager高可用
Alertmanager高可用
日常部署alertmanager组件的时候,都是用的单点架构,架构图如下所示:
那么显然这样是存在单点故障的,另外对运维而言,其实单点故障是很可怕的,收不到报警有时候是致命的,所以要用高可用的报警方式:
alertmanager的高可用方式有两种方法,都是很好的解决方案,第一种就是引入负载均衡,通过负载均衡的方法保证服务可用,架构如下:
这种方式可以实现高可用 并且可以灵活扩展,云服务的话一般都有负载均衡。
今天主要介绍官方提供的集群方法,架构如下:
Alertmanager引入了Gossip机制。Gossip机制为多个Alertmanager之间提供了信息传递的机制。确保及时在多个Alertmanager分别接收到相同告警信息的情况下,也只有一个告警通知被发送给Receiver。
集群环境搭建
为了能够让Alertmanager节点之间进行通讯,需要在Alertmanager启动时设置相应的参数。其中主要的参数包括:
--cluster.listen-address string: 当前实例集群服务监听地址
--cluster.peer value: 初始化时关联的其它实例的集群服务地址
现在准备一台机器部署Alertmanager集群
机器:
192.168.50.58
这里我为了节约资源 在一台机器启三个实例。
生产环境不建议都装在一台机器
定义Alertmanager实例01,其中Alertmanager的服务运行在9093端口,集群服务地址运行在8001端口。
定义Alertmanager实例02,其中主服务运行在9094端口,集群服务运行在8002端口。
定义Alertmanager实例03,其中主服务运行在9095端口,集群服务运行在8002端口。为了将01,02,03组成集群
02 03 启动时需要定义—cluster.peer参数并且指向01实例的集群服务地址:8001。
实例 | 集群端口 | 服务端口 |
---|---|---|
Alertmanager-01 | 8001 | 9093 |
Alertmanager-02 | 8002 | 9094 |
Alertmanager-03 | 8003 | 9095 |
[root@alert-manager-dev-1 src]# cd alertmanager
[root@alert-manager-dev-1 alertmanager]# ls
alert1.log alert2.log alert3.log alertmanager alertmanager.yml amtool data LICENSE NOTICE
[root@alert-manager-dev-1 alertmanager]# cat alertmanager.yml
global:
resolve_timeout: 5m
route:
group_by: ['alertname']
group_wait: 10s
group_interval: 10s
repeat_interval: 1h
receiver: 'wechat'
receivers:
- name: 'wechat'
wechat_configs:
- corp_id: 'ww10e9ec08a926549b' #企业ID
#to_user: '' #userid
to_user: '' #组id
agent_id: '' #agentid
api_secret: '' #生成的secret
send_resolved: true
- name: 'web.hook'
webhook_configs:
- url: 'http://192.168.50.58:5000/webhook'
inhibit_rules:
- source_match:
severity: 'critical'
target_match:
severity: 'warning'
equal: ['alertname', 'dev', 'instance']
启动实例01:
nohup ./alertmanager --web.listen-address=":9093" --cluster.listen-address="127.0.0.1:8001" --config.file="alertmanager.yml" --log.level=debug 2>&1 > alert1.log &
启动实例02:
nohup ./alertmanager --web.listen-address=":9094" --cluster.listen-address="127.0.0.1:8002" --cluster.peer=127.0.0.1:8001 --config.file="alertmanager.yml" --storage.path=/data/0994/ --log.level=debug 2>&1 > alert2.log
启动实例03:
nohup ./alertmanager --web.listen-address=":9095" --cluster.listen-address="127.0.0.1:8003" --cluster.peer=127.0.0.1:8001 --config.file="alertmanager.yml" --storage.path=/data/9095/ --log.level=debug 2>&1 > alert3.log &
修改Prometheus.yaml
alerting:
alertmanagers:
- static_configs:
- targets:
- 192.168.50.58:9093
- 192.168.50.58:9094
- 192.168.50.58:9095
重新加载Prometheus
curl -X POST http://localhost:9090/-/reload
完成后访问任意Alertmanager节点http://localhost:9093/#/status,可以查看当前Alertmanager集群的状态。
到这里就完成了 之后可以测试告警。