CONSUL VS. NAGIOS, SENSU


Nagios和Sensu都被构建为监控工具,用于当问题发生时快速的通知运维人员。

Nagios使用一组被配置为在远程主机执行检查任务的中央服务器。这个设计使它难以扩展,因为大型集群会迅速达到垂直尺度的限制,而Nagios自身也不能容易的进行水平扩展。众所周知,Nagios很难与现代的DevOps和配置管理工具配合使用,因为当远程服务器添加或移除时,主机上的配置必须被更新(不能自动发现)。

Sensu有更多的现代设计,它依赖本地Agent运行检查,然后将结果推送到一个AMQP Broker。若干服务器从Broker接收并处理健康检查的结果。这个模型比Nagios具有更多的可伸缩性,因为它允许更多的水平伸缩,并且Agent和Server之间是弱耦合的。然而,中心Broker有伸缩的限制,并且是系统中的单一故障点。

Consul提供了像Nagios和Sensu一样的健康检查能力,并且对现代的DevOps友好,避免了其它系统固有的伸缩性问题。Consul在本地运行所有的检查,就像Sensu一样,避免把负载全放到中央服务器(译者注:避免把鸡蛋放到一个篮子里:-))。Consul Server维护检查的状态,它具有一定的故障容忍度,并且没有单点故障。最后,Consul可以扩大到更多的检查数量,因为它依靠边界触发更新。这意味着,仅当一个检查状态从“passing”转换为“faling”或者反过来的时候,才会触发更新。

在一个大型集群,大多数的检查都是passing状态,也可能存在少量的检查一直是failing状态。通过仅捕获状态改变,Consul减少了大量的网络通信,以及健康检查的计算资源,允许系统提供更多的可伸缩性。

敏锐的读者可能注意到,如果一个Consul Agent挂了,将不会有边界触发更新的事发生。从其它节点看,所有的健康检查将呈现为一个不变的稳定的状态。然而,Consul守护进程也会处理这个问题。Client和Server使用的流言协议集成了一个分布式的故障检测器。这意味着如果一个Consul Agent挂了,故障将被检测到,于是这个节点上运行的所有健康检查将被认为失败。同时故障检测器在整个集群分发这个工作,更重要的是,使边界触发架构运作起来。