Consul vs. Nagios, Sensu
Nagios和Sensu都是为监控而构建的工具。它们用于在出现问题时快速通知操作员。
Nagios使用一组配置为对远程主机执行检查的中央服务器。这种设计使得缩放Nagios变得困难，因为大型舰队很快就达到了垂直缩放的极限，而Nagios也不容易水平缩放。 Nagios也很难与现代DevOps和配置管理工具一起使用，因为在添加或删除远程服务器时必须更新本地配置。
Sensu拥有更加现代化的设计，依靠当地代理运行检查并将结果推送给AMQP broker。许多服务器从代理处获取并处理运行状况检查的结果。此模型比Nagios更具可扩展性，因为它允许更多的水平扩展和服务器与代理之间的低耦合。但是，中央代理具有扩展限制，并且在系统中充当单点故障。
Consul提供与Nagios和Sensu相同的健康检查能力，对现代DevOps友好，并避免其他系统固有的扩展问题。 Consul在本地运行所有检查，如Sensu，避免给中央服务器带来负担。检查的状态由Consul服务器维护，这些服务器具有容错能力且没有单点故障。最后，Consul可以扩展到更多的检查，因为它依赖于边缘触发的更新。这意味着只有在检查从“passing”转换为“failing”时才会触发更新，反之亦然。
在大型舰队中，大多数检查都在通过，即使是失败的少数也是持久性的。通过仅捕获更改，Consul减少了运行状况检查所使用的网络和计算资源的数量，从而使系统更具可伸缩性。
精明的读者可能会注意到，如果Consul代理死亡，则不会发生边缘触发更新。从其他节点的角度来看，所有检查都将处于稳定状态。然而，Consul也反对这一点。客户端和服务器之间使用的gossip协议集成了分布式故障检测器。这意味着如果Consul代理失败，将检测到失败，因此可以假定该节点正在运行的所有检查都失败。该故障检测器在整个集群之间分配工作，而最重要的是，使边缘触发的体系结构能够工作。