Management-less mode

[deadtrickster]

cc @gerhard @michaelklishin

So the idea is to have a second mode - without management and export unagreggated metrics.

Proposal:

• configuration switch: only_core (true|false). What default?
• default path: /api/metrics, default port 15672
• collectors set: that new core collector, process collector (if works), what else?

Or should it be completely different release without management dependency? Say node deployed without management, this plugin loaded with only_core:true, will rabbit complain about it being dependent on management plugin?

[gerhard]

• configuration switch: only_core (true|false). What default?

Use the same default behaviour as we have currently: false (no breaking change)

• default path: /api/metrics, default port 15672

Will rabbitmq_management fail to enabled after this plugin is enabled due to a port collision? I think that using a dedicated port for Prometheus metrics would make more sense - e.g. 15673

• collectors set: that new core collector, process collector (if works), what else?

I can only think of Erlang VM memory allocators as missing. It would be nice to have all Mnesia metrics, not sure what we are missing here though.

Or should it be completely different release without management dependency?

I don't know, but it does sound reasonable. @dcorbacho what are your thoughts on this?

[dcorbacho]

Not using the management means that the plugin has to create its own endpoint using rabbitmq_web_dispatch, as it currently is a management plugin. Not sure it makes sense doing it on the same plugin. I created a new plugin before going on vacation that does that, what might make sense is to move all the collectors to a new application library so they can be used from both prometheus_rabbitmq_exporter and the new rabbitmq_prometheus.

[gerhard]

This can be closed now. We plan to ship rabbitmq_prometheus from RabbitMQ 3.8.0 onwards.

[deadtrickster]

will rabbitmq_prometheus work with this exporter?