本章节次要解说Alertmanager高可用的搭建与配置的具体的常识内容。

为了晋升Prometheus的服务可靠性，咱们会部署两个或多个的Prometheus服务，两个Prometheus具备雷同的配置（Job配、告警规定、等），当其中一个Down掉了当前，能够保障Prometheus继续可用。

AlertManager自带警报分组机制，即便不同的Prometheus别离发送雷同的警报给Alertmanager，Alertmanager也会主动把这些警报合并解决。

| 去重 | 分组 | 路由 |
| :-----: | :----: |:----: |
|Daduplicates|Groups|Route|
|将雷同的警报合并成一个|依据定义的分组|通过路由分发给指定的receiver|

尽管Alertmanager 可能同时解决多个雷同的Prometheus的产生的警报，如果部署的Alertmanager是单节点，那就存在显著的的单点故障危险，当Alertmanager节点down机当前，警报性能则不可用。

解决这个问题的办法就是应用传统的HA架构模式，部署Alertmanager多节点。然而因为Alertmanager之间关联存在不能满足HA的需要，因而会导致警报告诉被Alertmanager反复发送屡次的问题。

Alertmanager为了解决这个问题，引入了Gossip机制，为多个Alertmanager之间提供信息传递机制。确保及时的在多个Alertmanager别离承受到雷同的警报信息的状况下，不会发送反复的警报信息给Receiver.

Gossip 机制

要晓得什么是Gossip机制，必须理解分明Alertmanager中的每一次警报告诉是如何产生的，上面一图很具体的论述了警报个流程：

阶段形容
Silence在这个阶段中Alertmanager会判断以后告诉是否匹配任何静默规定；如果没有则进入下一个阶段，否则会中断流程不发送告诉。
WaitAlertmanager 会依据以后集群中所处在的程序[index]，期待 index * 5s 的工夫。
Dedup当期待完结实现，进入 Dedup 阶段，这时会判断以后Alertmanager TSDB中警报是否曾经发送，如果发送则中断流程，不发送警报。
Send如果下面的未发送，则进入 Send 阶段，发送警报告诉。
Gossip警报发送胜利当前，进入最初一个阶段 Gossip ，告诉其余Alertmanager节点，以后警报曾经发送胜利。其余Alertmanager节点会保留以后曾经发送过的警报记录。

Gossip的俩个要害：

  • Alertmanager 节点之间的Silence设置雷同，这样确保了设置为静默的警报都不会对外发送
  • Alertmanager 节点之间通过Gossip机制同步警报告诉状态，并且在流程中标记Wait阶段，保障警报是顺次被集群中的Alertmanager节点读取并解决。

搭建本地 Alertmanager 集群

启动Alertmanager集群之前，须要理解一些集群相干的参数

参数阐明
--cluster.listen-address="0.0.0.0:9094"集群服务监听端口
--cluster.peer初始化关联其余节点的监听地址
--cluster.advertise-address播送地址
--cluster.gossip-interval集群音讯流传工夫，默认 200s
--cluster.probe-interval各个节点的探测工夫距离
# 间接复制之前曾经装置过的Alertmanager文件夹cp -r alertmanager/ /usr/local/alertmanager01cp -r alertmanager/ /usr/local/alertmanager02cp -r alertmanager/ /usr/local/alertmanager03# 复制实现当前，写入启动脚本，# Alertmanager01cat << EOF> /lib/systemd/system/alertmanager01.service[Unit]Description=alertmanagerDocumentation=https://prometheus.io/After=network.targetStartLimitIntervalSec=0[Service]Type=simpleUser=prometheusExecStart=/usr/local/alertmanager01/bin/alertmanager \--config.file=/usr/local/alertmanager01/conf/alertmanager.yml \--storage.path=/usr/local/alertmanager01/data \--web.listen-address=":19093" \--cluster.listen-address=192.168.1.220:19094 \--log.level=debugRestart=alwaysRestartSec=1[Install]WantedBy=multi-user.targetEOF# Alertmanager02cat << EOF> /lib/systemd/system/alertmanager02.service[Unit]Description=alertmanagerDocumentation=https://prometheus.io/After=network.targetStartLimitIntervalSec=0[Service]Type=simpleUser=prometheusExecStart=/usr/local/alertmanager02/bin/alertmanager \--config.file=/usr/local/alertmanager02/conf/alertmanager.yml \--storage.path=/usr/local/alertmanager02/data \--web.listen-address=":29093" \--cluster.listen-address=192.168.1.220:29094 \--cluster.peer=192.168.1.220:19094 \--log.level=debugRestart=alwaysRestartSec=1[Install]WantedBy=multi-user.targetEOF# Alertmanager03cat <<EOF > /lib/systemd/system/alertmanager03.service[Unit]Description=alertmanagerDocumentation=https://prometheus.io/After=network.targetStartLimitIntervalSec=0[Service]Type=simpleUser=prometheusExecStart=/usr/local/alertmanager03/bin/alertmanager \--config.file=/usr/local/alertmanager03/conf/alertmanager.yml \--storage.path=/usr/local/alertmanager03/data \--web.listen-address=":39093" \--cluster.listen-address=192.168.1.220:39094 \--cluster.peer=192.168.1.220:19094 \--log.level=debugRestart=alwaysRestartSec=1[Install]WantedBy=multi-user.targetEOF# 开启systemd脚本启动systemctl enable alertmanager01 alertmanager02 alertmanager03systemctl start alertmanager01 alertmanager02 alertmanager03

启动实现后，就能够拜访http://192.168.1.220:19093能够看到以下集群状态了，我这里是为了测试，本地启动了多个端口，如果是理论生产环境中，是不同节点以及不同的IP，这些依据本人的需要设计即可。

Prometheus中的配置：

  external_labels: # 联邦集群附加的Label标识，能够附加在警报中，这样用于标识警报来源于那个Prometheus    dc: prom-masteralerting:  alert_relabel_configs:    - source_labels: [dc]      regex: (.+)\d+      target_label: dc  alertmanagers:    - static_configs:        #- targets: ['127.0.0.1:9093']        - targets: ['192.168.1.220:19093','192.168.1.220:29093','192.168.1.220:39093']

配置实现当前，重启或者reloadPrometheus服务，拜访http://192.168.1.220:19090/config就能够看到具体的配置信息了。

到此，Alertmanager集群配置就实现了，对于集群中的警报测试很简略，间接down掉一个端口，而后触发警报，看看警报是否能够失常发送。