TripleO should be deploying out-of-the-box availability monitoring solution to serve the overcloud.
Currently there is no such feature implemented except for possibility to deploy sensu-server, sensu-api and uchiwa (Sensu dashboard) services in the undercloud stack. Without sensu-client services deployed on overcloud nodes this piece of code is useless. Due to potential of high resource consumption it is also reasonable to remove current undercloud code to avoid possible problems when high number of overcloud nodes is being deployed.
Instead sensu-server, sensu-api and uchiwa should be deployed on the separate node(s) whether it is on the undercloud level or on the overcloud level. And so sensu-client deployment support should be flexible enough to enable connection to external monitoring infrastructure or with Sensu stack deployed on the dedicated overcloud node.
Summary of use cases:
1. sensu-server, sensu-api and uchiwa deployed in external infrastructure; sensu-client deployed on each overcloud node 2. sensu-server, sensu-api and uchiwa deployed as a separate Heat stack in the overcloud stack; sensu-client deployed on each overcloud node
The sensu-client service will be deployed as a composable service on the overcloud stack when it is explicitly stated via environment file. Sensu checks will have to be configured as subscription checks (see  for details). Each composable service will have it’s own subscription string, which will ensure that checks defined on Sensu server node (wherever it lives) are run on the correct overcloud nodes.
There will be implemented a possibility to deploy sensu-server, sensu-api and uchiwa services on a stand alone node deployed by the undercloud. This standalone node will have a dedicated purpose for monitoring (not only for availability monitoring services, but in future also for centralized logging services or performance monitoring services)
The monitoring node will be deployed as a separate Heat stack to the overcloud stack using Puppet and composable roles for required services.
Additional service (sensu-client) will be installed on all overcloud nodes. These services will have open connection to RabbitMQ instance running on monitoring node and are used to execute commands (checks) on the overcloud nodes. Check definition will live on the monitoring node.
We might consider deploying separate RabbitMQ and Redis for monitoring purposes if we want to avoid influencing OpenStack deployment in the overcloud.
Sensu clients will be deployed by default on all overcloud nodes except the monitoring node.
New Sensu common parameters:
- RabbitMQ host Sensu has to connect to
- RabbitMQ port Sensu has to connect to
- Whether Sensu should connect to RabbitMQ using SSL
- RabbitMQ password used for Sensu to connect
- RabbitMQ username used for Sensu to connect
- RabbitMQ vhost used for monitoring purposes.
New Sensu server/API parameters
- Redis host Sensu has to connect to
- Redis password used for Sensu to connect
- Full definition (for all subscriptions) of checks performed by Sensu
New parameters for subscription strings for each composable service:
- For example for service nova-compute MonitoringSubscriptionNovaCompute, which will default to ‘overcloud-nova-compute’
Support for new node type should be implemented for tripleo-quickstart.
Sensu client deployment will be tested by current TripleO CI as soon as the patch is merged, as it will be deployed by default.
We should consider creating CI job for deploying overcloud with monitoring node to test the rest of the monitoring components.
Process of creating new node type and new options will have to be documented.