网络分区的断定node
RabbitMQ中与网络分区的断定相关的是net_ticktime这个参数,默认为60s。在RabbitMQ集群中的每一个broker节点会每隔 net_ticktime/4 (默认15s)计一次tick(若是有任何数据被写入节点中,此节点被认为被ticked),若是在连续四次某节点都没有被ticked到,则断定此节点处于down的状态,其他节点能够将此节点剥离出当前分区。将连续四次的tick时间即为T,那么T的取值范围为 0.75ticktime < T < 1.25ticktimeshell
默认状况下,在45s,日志出现网络
=ERROR REPORT==== 16-Jul-2017::15:20:55 === Mnesia('rabbit@node1'): ** ERROR ** mnesia_event got {inconsistent_database, running_partitioned_network, 'rabbit@node2'}
当一个节点起来的时候,RabbitMQ会记录是否发生了网络分区,你能够经过WebUI进行查看;app
RabbitMQ GUI上显示 Network partition detected Mnesia reports that this RabbitMQ cluster has experienced a network partition. There is a risk of losing data. Please read RabbitMQ documentation about network partitions and the possible solutions.
或者能够经过rabbitmqctl cluster_status命令查看,若是查看到信息中的partitions那一项是空的,就像这样ide
[{nodes,[{disc,['rabbit@node1', 'rabbit@node2']}]}, {running_nodes,['rabbit@node2','rabbit@node1']}, {cluster_name,<<"rabbit@node1">>}, {partitions,[]}]
然而当网络分区时,会变成这样:this
[{nodes, [{disc, ['rabbit@node1','rabbit@node2']}]}, {running_nodes,['rabbit@node1']}, {cluster_name,<<"rabbit@node1">>}, {partitions, [{'rabbit@node1',['rabbit@node2']}]}]
当一个RabbitMQ集群发生网络分区时,这个集群会分红两个或者多个分区,它们各自为政,互相都认为对方分区的节点已经down,包括queues,bindings,exchanges这些信息的建立和销毁都处于自身分区内,与其它分区无关。若是原集群中配置了镜像队列,而这个镜像队列又牵涉到两个或者多个网络分区中的节点时,每个网络分区中都会出现一个master节点,若是分区节点个数充足,也会出现新的slave节点,对于各个网络分区,彼此的队列都是相互独立的,固然也会有一些其余未知的、怪异的事情发生。当网络恢复时,网络分区的状态仍是会保持,除非采起一些措施去解决他.net
自动处理网络分区日志
RabbitMQ提供了4种处理网络分区的方式,在rabbitmq.config中配置cluster_partition_handling参数便可,分别为: code
默认是ignore: ignore的配置是当网络分区的时候,RabbitMQ不会自动作任何处理,即须要手动处理中间件
pause_minority: 当发生网络分区时,集群中的节点在观察到某些节点down掉时,会自动检测其自身是否处于少数派(小于或者等于集群中通常的节点数)。少数派中的节点在分区发生时会自动关闭,当分区结束时又会启动。这里的关闭是指RabbitMQ application关闭,而Erlang VM并不关闭,这个相似于执行了rabbitmqctl stop_app命令。处于关闭的节点会每秒检测一次是否可连通到剩余集群中,若是能够则启动自身的应用,至关于执行rabbitmqctl start_app命令。
pause_if_all_down: 在pause_if_all_down模式下,RabbitMQ会自动关闭不能和list中节点通讯的节点。语法为{pause_if_all_down, [nodes], ignore|autoheal},其中[nodes]即为前面所说的list。若是一个节点与list中的全部节点都没法通讯时,自关闭其自身。若是list中的全部节点都down时,其他节点若是是ok的话,也会根据这个规则去关闭其自身,此时集群中全部的节点会关闭。若是某节点可以与list中的节点恢复通讯,那么会启动其自身的RabbitMQ应用,慢慢的集群能够恢复
autoheal: 在autoheal模式下,当认为发生网络分区时,RabbitMQ会自动决定一个获胜的(winning)分区,而后重启不在这个分区中的节点以恢复网络分区。一个获胜的分区是指客户端链接最多的一个分区。若是产生一个平局,既有两个或者多个分区的客户端链接数同样多,那么节点数最多的一个分区就是获胜的分区。若是此时节点数也同样多,将会以一种特殊的方式来挑选获胜分区
oscar cmp目前的配置以下:
rabbitmq.config
[ {rabbit, [{cluster_nodes, {['rabbit@sh01-oscar-cmp-prod-rmq03','rabbit@sh01-oscar-cmp-prod-rmq01','rabbit@sh01-oscar-cmp-prod-rmq02'],ram }}, {cluster_partition_handling,pause_minority}]}, {kernel,[{net_ticktime, 60}]} ].
能够看出使用的第二种方式
grafana添加报警规则
partitions Current Number of network partitions. 0 is ok. If the cluster is splitted the value is at least 2
由此能够看出,partitions为0时正常,若是集群发生了分裂值至少为2.故咱们能够设置partitions值不为0时报警
添加规则:
- alert: Rabbitmq_node_partitions expr: (rabbitmq_partitions{job="rabbitmq_monitor"}) != 0 for: 2m labels: issuetype: "严重" sourcetype: "中间件" annotations: summary: "Instance {{ $labels.instance }} rabbitmq集群节点故障: partitions" description: "{{ $labels.instance }} of job {{ $labels.job }} on {{ $labels.node }} rabbitmq集群节点故障: partitions" referenceURL: "http://wiki.virtueit.net/display/CMDT/2.+Maintenance+Manual" recovered: "recovered"