status-im/consul
2
0
Fork 0
mirror of https://github.com/status-im/consul.git synced 2025-02-26 12:25:41 +00:00
Code Issues Projects Releases Wiki Activity

Website: clean up intro/vs/nagios-sensu.html.

Browse Source
This commit is contained in:
Ryan Breen 2015-03-08 11:19:26 -04:00
parent 210a11e44e
commit 9aad7c14fb
1 changed files with 6 additions and 6 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

12
website/source/intro/vs/nagios-sensu.html.markdown
View File

@ -22,16 +22,16 @@ or removed.
Sensu has a much more modern design, relying on local agents to run Sensu has a much more modern design, relying on local agents to run
checks and pushing results to an AMQP broker. A number of servers checks and pushing results to an AMQP broker. A number of servers
ingest and handle the result of the health checks from the broker. This model ingest and handle the result of the health checks from the broker. This model
is more scalable than Nagios, as it allows for much more horizontal scaling, is more scalable than Nagios, as it allows for much more horizontal scaling
and a weaker coupling between the servers and agents. However, the central broker and a weaker coupling between the servers and agents. However, the central broker
has scaling limits, and acts as a single point of failure in the system. has scaling limits and acts as a single point of failure in the system.
Consul provides the same health checking abilities as both Nagios and Sensu, Consul provides the same health checking abilities as both Nagios and Sensu,
is friendly to modern DevOps, and avoids the scaling issues inherent in the is friendly to modern DevOps, and avoids the scaling issues inherent in the
other systems. Consul runs all checks locally, like Sensu, avoiding placing other systems. Consul runs all checks locally, like Sensu, avoiding placing
a burden on central servers. The status of checks is maintained by the Consul a burden on central servers. The status of checks is maintained by the Consul
servers, which are fault tolerant and have no single point of failure. servers, which are fault tolerant and have no single point of failure.
Lastly, Consul can scale to vastly more checks because it relies on edge triggered Lastly, Consul can scale to vastly more checks because it relies on edge-triggered
updates. This means that an update is only triggered when a check transitions updates. This means that an update is only triggered when a check transitions
from "passing" to "failing" or vice versa. from "passing" to "failing" or vice versa.
@ -41,10 +41,10 @@ the amount of networking and compute resources used by the health checks,
allowing the system to be much more scalable. allowing the system to be much more scalable.
An astute reader may notice that if a Consul agent dies, then no edge triggered An astute reader may notice that if a Consul agent dies, then no edge triggered
updates will occur. From the perspective of other nodes all checks will appear updates will occur. From the perspective of other nodes, all checks will appear
to be in a steady state. However, Consul guards against this as well. The to be in a steady state. However, Consul guards against this as well. The
[gossip protocol](/docs/internals/gossip.html) used between clients and servers [gossip protocol](/docs/internals/gossip.html) used between clients and servers
integrates a distributed failure detector. This means that if a Consul agent fails, integrates a distributed failure detector. This means that if a Consul agent fails,
the failure will be detected, and thus all checks being run by that node can be the failure will be detected, and thus all checks being run by that node can be
assumed failed. This failure detector distributes the work among the entire cluster, assumed failed. This failure detector distributes the work among the entire cluster
and critically enables the edge triggered architecture to work. while, most importantly, enabling the edge triggered architecture to work.