Display busiest queues in check_queues NRPE plugin
When invoking the check_rabbitmq_queues script with wildcards for vhost
and/or queue parameters, script output does not reflect precisely which
queues are having a high number of oustanding messages as information is
consolidated under the wildcard.
This change fixes this behaviour by adding a new charm configuration
parameter which allows the user to specify the number of busiest queues,
n, to display should the check_rabbitmq_queues script reports any
warnings or errors. The default, n=0, keeps the current script output.
This option is applicable regardless of the vhost:queue combination but
is specifically relevant when wildcards are passed as arguments.
Implementation displays the first n items in the stats list re-organized
in decreasing message count order.
Move cron max file age calculation to rabbit_utils
The check_rabbitmq_queues nrpe check accesses the cron file created
for running collect stats job. This is done in order to determine if
the stats are too old and an alert should be raised. The nagios user
does not have access to read the cron job when running in a hardened
environment where /etc/cron.d is not readable.
This change refactors this logic to move the calculation of maximum
age for a stats file from the check_rabbitmq_queues script and into
the rabbit_utils code where it is generating the nrpe configuration.
A new (optional) parameter is added to the check_rabbitmq_queues
script to accept the maximum age in seconds a file can last be
modified.
This change also removes the trusty support in hooks/install and
hooks/upgrade-charm as the rabbit_utils.py file needs to import a
dependency which is installed by the scripts. It is cleaned up to make
sure the croniter package is always installed on install or upgrade.
Improving the parsing of the cron schedule for /etc/cron/rabbitmq-stats.
The code makes assumptions that the user in the cron entry will be the
root user, which is generally safe as that's what the charm applied.
However, the parsing is brittle in that it depends on the 'root' string
in the entry. This changes the code so that the cron timer spec is
stripped out based on the column entries in the file.
When a RabbitMQ cluster is restarted, the mnesia settings determine
how long and how often each broker will try to connect to the cluster
before giving up. It might be useful for an operator to be able to
tune these parameters. This change adds two settings,
`mnesia-table-loading-retry-timeout` and
`mnesia-table-loading-retry-limit`, which set these parameters in the
rabbitmq.config file [1].
