【高可用】alertmanager高可用,alertmanager集群

【1】alertmanager集群高可用介绍

(1.1)基本介绍

Alertmanager成为单点
  

    

  为了提升Promthues的服务可用性,通常用户会部署两个或者两个以上的Promthus Server,它们具有完全相同的配置包括Job配置,以及告警配置等。当某一个Prometheus Server发生故障后可以确保Promthues持续可用。

  同时基于Alertmanager的告警分组机制即使不同的Prometheus Sever分别发送相同的告警给Alertmanager,Alertmanager也可以自动将这些告警合并为一个通知向receiver发送。

Alertmanager特性

  但不幸的是,虽然Alertmanager能够同时处理多个相同的Prometheus Server所产生的告警。但是由于单个Alertmanager的存在,当前的部署结构存在明显的单点故障风险,当Alertmanager单点失效后,告警的后续所有业务全部失效。

  如下所示,最直接的方式,就是尝试部署多套Alertmanager。但是由于Alertmanager之间不存在并不了解彼此的存在,因此则会出现告警通知被不同的Alertmanager重复发送多次的问题。

  

    

日常部署 alertmanager 组件的时候,都是用的单点架构,架构图如下所示:

  解决这个问题的方法就是使用传统的HA架构模式,部署Alertmanager多节点。

  但是由于Alertmanager之间关联存在不能满足HA的需求,因此会导致警报通知被Alertmanager重复发送多次的问题

    

  那么显然这样是存在单点故障的,另外对运维而言,其实单点故障是很可怕的,收不到报警有时候是致命的,所以要用高可用的报警方式:

alertmanager的高可用方式有两种方法:

  第一种就是引入负载均衡,通过负载均衡的方法保证服务可用,架构如下:

    这种方式可以实现高可用 并且可以灵活扩展,云服务的话一般都有负载均衡。

  今天主要介绍官方提供的集群方法,架构如下:

  

  

Alertmanager引入了Gossip机制。Gossip机制为多个Alertmanager之间提供了信息传递的机制。

确保及时在多个Alertmanager分别接收到相同告警信息的情况下,也只有一个告警通知被发送给Receiver。

(1.2)Gossip机制

  要知道什么是Gossip机制,必须了解清楚Alertmanager中的每一次警报通知是如何产生的,下面一图很详细的阐述了警报个流程:

  

  

Gossip俩个关键:

  • Alertmanager 节点之间的Silence设置相同,这样确保了设置为静默的警报都不会对外发送

  • Alertmanager 节点之间通过Gossip机制同步警报通知状态,并且在流程中标记Wait阶段,保证警报是依次被集群中的Alertmanager节点读取并处理

 

Gossip分布式协议

  一般来说Gossip有两种实现方式分别为Push-based和Pull-based。

  Push-based:当集群中某一节点A完成一个工作后,随机的从其它节点B并向其发送相应的消息,节点B接收到消息后在重复完成相同的工作,直到传播到集群中的所有节点。

  Pull-based:节点A会随机的向节点B发起询问是否有新的状态需要同步,如果有则返回。

在简单了解了Gossip协议之后,我们来看Alertmanager是如何基于Gossip协议实现集群高可用的。如下所示,当Alertmanager接收到来自Prometheus的告警消息后,会按照以下流程对告警进行处理:

  

 

通知流水线(因此两个关键见上面《Gossip俩个关键》)
  1. 在第一个阶段Silence中,Alertmanager会判断当前通知是否匹配到任何的静默规则,如果没有则进入下一个阶段,否则则中断流水线不发送通知。

  2. 在第二个阶段Wait中,Alertmanager会根据当前Alertmanager在集群中所在的顺序(index)等待index * 5s的时间。

  3. 当前Alertmanager等待阶段结束后,Dedup阶段则会判断当前Alertmanager数据库中该通知是否已经发送,如果已经发送则中断流水线,不发送告警,否则则进入下一阶段Send对外发送告警通知。

  4. 告警发送完成后该Alertmanager进入最后一个阶段Gossip,Gossip会通知其他Alertmanager实例当前告警已经发送。其他实例接收到Gossip消息后,则会在自己的数据库中保存该通知已发送的记录。

因此两个关键点在于:

  

 

  • Silence设置同步:Alertmanager启动阶段基于Pull-based从集群其它节点同步Silence状态,当有新的Silence产生时使用Push-based方式在集群中传播Gossip信息。
  •  通知发送状态同步:告警通知发送完成后,基于Push-based同步告警发送状态。Wait阶段可以确保集群状态一致。
Alertmanager基于Gossip实现的集群机制虽然不能保证所有实例上的数据时刻保持一致,但是实现了CAP理论中的AP系统,即可用性和分区容错性。
同时对于Prometheus Server而言保持了配置了简单性,Promthues Server之间不需要任何的状态同步。

【2】alertmanager 集群配置

(2.1)alertmanager集群参数

# 当前实例集群服务监听地址,为空则禁用高可用功能
--cluster.listen-address="0.0.0.0:9094"
# 表示集群节点对其他节点发布的地址,其他节点可以用这个地址与该地址通信
--cluster.advertise-address=CLUSTER.ADVERTISE-ADDRESS
# 用来设置该 Alertmanager 节点的集群对等体,将告警数据同步其他节点
--cluster.peer=CLUSTER.PEER
# 对等超时时间,默认15秒
--cluster.peer-timeout=15s
# 集群消息传播时间,默认200ms
--cluster.gossip-interval=200ms
# 定义了多个 Alertmanager 实例之间的信息同步频率
--cluster.pushpull-interval=10ms
# 评估通知之前等待集群连接建立的最长时间
--cluster.tcp-timeout=10s
# 在标记节点不正常之前等待确认的时间
--cluster.probe-timeout=500ms
# 随机节点探测之间的间隔
--cluster.probe-interval=1s
# 用来设置集群状态稳定的超时时间的参数
--cluster.settle-timeout=10ms
# 尝试重新连接到丢失的对等设备之间的间隔时间
--cluster.reconnect-interval=10s
# 尝试重新连接到丢失的对等设备的间隔时间
--cluster.reconnect-timeout=6h0m0s
# 用于在 Alertmanager 集群模式中配置 TLS 证书
--cluster.tls-config=""
# 允许节点发送不加密的广播请求,从而允许其他节点发现它的地址。
# 这条最好不用
--cluster.allow-insecure-public-advertise-address-discovery

(2.2)配置 alertmanager

计划配置2个,一个为

  10.18.31.199:9093  集群口为默认的9094     另一个为 10.18.31.201:9093  集群口为默认的9094 

修改alertmanager.yml 为一样的内容

 

# 先运行 10.18.31.199
cd /data/prometheus/alertmanager/ && nohup ./alertmanager --log.level=debug --config.file=alertmanager.yml \
--web.external-url=http://10.18.31.199:9093 >>/data/prometheus/logs/alertmanager.log 2>&1 &

# 再运行 10.18.31.201
cd /data/dba/software/alertmanager/ && nohup ./alertmanager --log.level=debug --config.file=alertmanager.yml --cluster.peer='10.18.31.199:9094' \
--web.external-url=":9093" &

核验:启动后如下图,任意节点的9093端口上去查看都可以看得到。

  

同时我们可以看到,我们在31.199上配置的静默也同步过来了

  

(2.3)alertmanager集群与prometheus

  

弄完之后记得重载啊: curl -X POST localhost:9090/-/reload

【3】alertmanager集群高可用核验

模拟告警:

aa='[
    {
        "Labels": {
            "alertname": "alertmanager高可用测试",
            "IP": "192.168.2.101"
        },
        "Annotations": {
            "summary": "NodeCpuPressure, IP: 192.168.2.101, Value: 90%, Threshold: 85%"
        },
        "StartsAt": "2020-02-17T23:00:00.000+08:00", 
        "EndsAt": "2029-02-18T23:00:00.000+08:00"
    }
]'
# 执行 POST
curl http://127.0.0.1:9093/api/v2/alerts -XPOST -H'Content-Type: application/json' -d"$aa"

1、【两个alertmanager均在运行的情况】模拟是否会产生多重告警?

  

 结论是只有一个告警;

  我试试静默在 31.199上静默,看看 31.201 是否会同步,如下图,成功同步;

  

 

2、【两个alertmanager均在运行的情况】真实故障是否会发多个告警?

  

结果依然只是发了一个告警:

  

3、【宕机1个,正常运行1个】是否可以实现高可用,继续告警?

先关闭其中之一,比如 10.18.31.199 的 alertmanager

 如下图:依然会告警,并且成功了,至此完成。

  

 

【参考文档】

https://yunlzheng.gitbook.io/prometheus-book/part-ii-prometheus-jin-jie/readmd/alertmanager-high-availability

https://www.qinglite.cn/doc/60426476c7da4276b

https://yyang.blog.csdn.net/article/details/128980313?spm=1001.2101.3001.6650.4&utm_medium=distribute.pc_relevant.none-task-blog-2%7Edefault%7EBlogCommendFromBaidu%7ERate-4-128980313-blog-94476359.235%5Ev38%5Epc_relevant_anti_t3&depth_1-utm_source=distribute.pc_relevant.none-task-blog-2%7Edefault%7EBlogCommendFromBaidu%7ERate-4-128980313-blog-94476359.235%5Ev38%5Epc_relevant_anti_t3&utm_relevant_index=3

https://blog.csdn.net/qq_42527269/article/details/128980313

posted @ 2023-10-07 17:12  郭大侠1  阅读(600)  评论(0编辑  收藏  举报