​​Prometheus监控之AleartManager高可用

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.target

3.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