【博客485】prometheus-----为什么prometheus与alertmanager之间要用full mesh，不能load balance

为什么prometheus与alertmanager之间需要full mesh，不能load balance

官方链接：

https://prometheus.io/docs/alerting/latest/alertmanager/#high-availability

官方建议prometheus与alertmanager之间需要full mesh：

It’s important not to load balance traffic between Prometheus and its Alertmanagers, but instead, point Prometheus to a list of all Alertmanagers.

原因：

1、如果使用单连接模式

example:

prometheus1        prometheus2        prometheusN
    ｜                  ｜                 ｜
    ｜                  ｜                 ｜
    ｜                  ｜                 ｜
    ｜                  ｜                 ｜
alartmanager1      alertmanager2     alertmanagerN
1
2
3
4
5
6

数据一致性：

能够保持一致，但会有不同步的可能，需要等待alertmanager利用gossip来保持最终一致性，
收敛速度较慢，发生数据不一致可能性高

网络分区容错性：较差

因为假设出现网络分区：
prometheus1与alertmanager1之间连接不上，
prometheus2与alertmanager2之间连接不上，
prometheusN与alertmanagerN之间连接不上，
prometheus1与alertmanager2，alertmanagerN之间能连接上，
prometheus2与alertmanager1，alertmanagerN之间能连接上，
prometheusN与alertmanager1，alertmanager2之间能连接上，

此时对于这种分区容错性完全不具备，部分组件之间的不通，导致监控全部瘫痪

2、如果使用load balance模式：出现数据不一致

比如：alertmanager集群莫名发送resolve消息，尽管实际并没有resolve发生

场景：

问题的根因：

假设如下场景，alertmanager-1此时有2条firing的告警alert-1和alert-2，alertmanager-2有2条firing的告警alert-1和alert-3，由于使用了LB，导致发送到alertmanager-2的alert-1告警数目远少于alertmanager-1，且alertmanager-2的alert-1由于EndAt时间过老，即将产生告警恢复。而这种情况下alertmanager-2的firing告警哈希并不是alertmanager-1发送过来的告警哈希的子集，因此并不会产生抑制效果，之后便会导致alertmanager-2产生alert-1的告警恢复。

因此官方要求上游的告警必须能够发送到所有的alertmanager实例上。

3、如果使用full mesh模式：

数据一致性：

能够保持一致，不同步的可能较少，每个alertmanager收到的数据都一致，
利用gossip来保持最终一致性，收敛速度较快，发生数据不一致可能性低

网络分区容错性：最高

因为假设出现网络分区：
prometheus1与alertmanager1之间连接不上，
prometheus2与alertmanager2之间连接不上，
prometheusN与alertmanagerN之间连接不上，
prometheus1与alertmanager2，alertmanagerN之间能连接上，
prometheus2与alertmanager1，alertmanagerN之间能连接上，
prometheusN与alertmanager1，alertmanager2之间能连接上，

此时对于这种分区容错性完全具备，部分组件之间的不通，不会导致监控全部瘫痪