Prometheus Broker Plugin for Apache ActiveMQ

[hai-ben]

I put up an issue earlier and realize this might be the more appropriate place to put it. (I'll also send out something to the mailing list).

The idea is to have a 1st class Prometheus plugin for ActiveMQ, similar to what RabbitMQ provides.

Some handy features might be metric aggregation, user-based auth for viewing metrics, avoiding JMX MBean overhead, and avoid the security nastiness of needing to expose JMX RMI ports (even on localhost only) or run a third jar as a java agent.

What sort of interest is there for this feature?

[jbonofre]

Hi

Thanks to start this discussion. Afair, I discussed about that in the past. I also started a PR to provide OpenTelemetry plugin (#1768). We can add a Prometheus exporter in this plugin (and other pluggable exporters).

Thoughts?

[mattrpav]

Hi @hai-ben!

Thanks for kicking off this discussion. I'm a big fan of having modern, first-class monitoring and reporting integrations.

Can you link the RabbitMQ plugin? I think it would be helpful to clarify the target features and scope--

1. Replace the need for the prometheus agent for polled metrics?

2. Extend the drafted OpenTelemetry plugin to support collecting tracing data?

3. Both?

One thing to note-- I'm cautious of adding a bunch of 3rd-party dependencies to the main repo. ActiveMQ has outlived many trendy monitoring and alerting platforms. When those get flagged for security, it tends to flag the whole broker.

Side quest-- I'm wondering if having an 'extras' or 'third-party' repo for extensions would be a way to manage this. For example-- activemq-shiro and activemq-log4j-appender are third-party add-ons that really aren't part of the broker.

[hai-ben]

Jumping off point for Prometheus for RabbitMQ: https://github.com/rabbitmq/rabbitmq-server/blob/main/deps/rabbitmq_prometheus/README.md

[jbonofre]

@hai-ben @mattrpav as said, it's already possible thanks to PR #1769.

You can define the exporter (including Prometheus):

https://github.com/apache/activemq/pull/1769/changes#diff-be135551b06b732d4787534586fe51c2d33d500e79730f68950cd9eeef7f89b2R29

[jbonofre]

It also leverages the spans and evens from third parties included in ActiveMQ: as soon as a third party use OpenTelemetry, the plugin "gets" it and send to the exporter.

[hai-ben]

Thanks all for the responses.

To answer explicitly @mattrpav:

1. This would replace the need for a Prometheus agent for polled metrics.
2. I misunderstood the scope of @jbonofre's OTel work. This would be orthogonal to it.
3. This adds no deps, would be optional, and should be very light weight (<200 lines).
4. Because of the size and integration layer, it feels like it should be in the main repo (which would also allow the K8 Helm setup to ship with metrics.enabled without any deps 😉)

A little more, detail on how it would work:

• A small optional servlet runs on the Jetty server, inheriting the console's auth.
• It vends a basic predetermined set of broker metrics in the Prometheus format on the /metrics path.
• It accepts GET requests only, it reads some MBeans (again predetermined), and vends the results with intelligible and stable names.
• In contrast to Jolokia, this is a read-only, fixed-output text renderer. It never handles a custom MBean request, so it doesn't need an MBean execution or write path.

Would be happy to put up an example PR if there's interest.

[jbonofre]

I think a PR would be great to understand exactly the purpose. As we will have OTel Broker Plugin (with exporter), I'm not sure iif it's orthogonal, complementary, or alternative.