1 AlertManager传统架构
在⼤多数情况下，AlertManager组件通常以单点架构存在，如下图所示。如果单点的AlertManager发⽣故障，将导致所有消息都⽆法及时发送，也就意味着系统即使出现了故障，我们也⽆法第⼀时间获取到对应的告警信息。
2 AlertManager⾼可⽤架构
⽅案1：基于负载均衡
为了确保⾼可⽤性，我们可以考虑配置多台
1、成本增加： 部署多个AlertManager 服务并使⽤ LVS 进⾏统⼀调度，会带来额外的成本。因为Prometheus本身就⽀持直接连接多个AlertManager实例，⽆需额外的负载均衡器。
2、消息重复发送： ⽆论是通过造成同⼀条告警消息发送多次（告警重复）
⽅案2：基于Gossip协议
为了解决多个AlertManager 之间的信息传递问题，AlertManager 引⼊了Gossip 机制。这种机制类似于⼈们之间的留⾔传递，通过Gossip多个 AlertManager 之间可以及时共享相同的告警信息。这意味着，即使多个 AlertManager 分别接收到相同的告警信息，系统也能确保只有⼀个告警通知被发送给 Receiver。此外，即便其中⼀台AlertManager 发⽣故障，也不会对其他节点的消息传递产⽣影响。
3 AlertManager⾼可⽤配置实践
3.1 配置启动文件
注意：需要保证每台的alertmanager.yml 的配置是⾼度⼀致的。
1、将AlertManager拷⻉⾄其他两个节点；
2、在所有节点上，准备 alertmanager_ha.service 的启动配置⽂件（--cluster.listen-address: 当前实例集群服务监听地址 、--cluster.peer: 关联的其它实例地址）
vim /usr/lib/systemd/system/alertmanager_ha.service
[Unit]
Description=alertmanager
Documentation=https://prometheus.io/
After=network.target
[Service]
ExecStart=/app/module/alertmanager/alertmanager \
--web.listen-address=:9093 \
--cluster.listen-address=0.0.0.0:9094 \
--cluster.peer=192.168.137.128:9094 \
--cluster.peer=192.168.137.131:9094 \
--cluster.peer=192.168.137.132:9094 \
--cluster.peer-timeout=15s \
--config.file=/app/module/alertmanager/alertmanager.yml \
--storage.path=/app/module/alertmanager/data \
--data.retention=120h
ExecReload=/bin/kill -HUP
TimeoutStopSec=20s
Restart=always
[Install]
WantedBy=multi-user.target3.2 启动服务
#记得先把第一个节点的alertmanager给停掉
systemctl daemon-reload
systemctl start alertmanager_ha.service
3.3 检查AlertManager集群状态
3.4 配置Prometheus对接多个AlertManager实例
alerting:
alertmanagers:
- static_configs:
- targets:
- "192.168.137.128:9093"
- "192.168.137.131:9093"
- "192.168.137.132:9093"3.5 重新加载配置
curl -X POST http://192.168.137.131:9090/-/reload
4 AlertManager⾼可⽤结果验证
1、测试集群同步状态，当在⼀个节点上创建了⼀个静默（Silence）记录，其他节点的监控⻚⾯能够即时显示该静默的信息
2、通过使⽤curl 命令模拟Prometheus，将同⼀条告警消息分别发送到两个AlertManager 实例，验证最终是否只会收到⼀条消息。
./sendAlert.sh "192.168.137.131" "alertname=主库宕机,instance=192.168.137.130,severity=critical,job=mysql_exporter"
./sendAlert.sh "192.168.137.132" "alertname=主库宕机,instance=192.168.137.130,severity=critical,job=mysql_exporter"3、根据此前的规则设定，最终会发送到钉钉告警，并且只会有⼀条告警消息，⽽不会出现多条重复才对。
4、尝试停⽌掉某台AlertManager实例，验证消息是否还能正常发送。
将128机器上的alertmanager和node_exporter都停掉
systemctl stop alertmanager_ha.service
systemctl stop node_exporter.service
