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代理失敗，將檢測到失敗，因此可以假定該節點正在執行的所有檢查都失敗。該故障檢測器在整個叢集之間分配工作，而最重要的是，使邊緣觸發的體系結構能夠工作。