As mentioned earlier in this guide, Sensu’s architecture is one of its most compelling features. While this modular design makes it infinitely adaptable to monitor any infrastructure, it also depends on some external services to function:
NOTE: this guide will focus on installing Sensu’s dependencies in a standalone configuration. However, in a live/production environment, it is strongly recommended that – at minimum – the Sensu data store and transport run on a different system than the Sensu server and API (i.e. in a distributed or high availability configuration). Please review the Sensu Installation Strategies for more information.
Data Store (Redis)
Sensu uses Redis as a data-store for storing persistent data such as the client registry and check results. Two Sensu Core services, the server and API require access to the same instance of Redis to function (i.e. the Sensu client does not communicate with Redis).
Sensu services use a message bus (e.g. RabbitMQ) for communication. This message bus communication is provided by the Sensu Transport, which is a library that makes it possible to leverage alternate transport solutions in place of RabbitMQ (the default transport). Sensu services requires access to the same instance of the defined transport (e.g. a RabbitMQ cluster) to function. Sensu check requests and check results are published as “messages” to the Sensu Transport, and the corresponding Sensu services receive these messages by subscribing to the appropriate subscriptions.