Provide a Prometheus compatible metrics exporter

[jimmidyson]

Integrating functionality similar to https://github.com/prometheus/jmx_exporter would be awesome for remote scraping by Prometheus (http://prometheus.io/).

[rhuss]

good idea, will have a look.

[jimmidyson]

Can we close this now with agent-bond do you think?

[rhuss]

Yeah, think so. However, I will rethink that /wr to Jolokia and health checks, or maybe with Jolokia 2.0

[lhoss]

Any news?
or https://github.com/prometheus/jmx_exporter still the best (only?) option ?

[rhuss]

@lhoss Yes, jmx_exporter is still the best option, but please use it with a whitelist, otherwise you probably will run into troubles.

[lhoss]

Thx @rhuss for the feedback .. I agree with the whitelist tip 👍

We might soon (test) collect(ing) JMX metrics into prometheus (instead of using jolokia->telegraf/jolokia-input .. which worked very well though) , but I am def. a little sad to not continue using jolokia to export JMX (also as I had prepared a nice telegraf/jolokia config, with a large explicit list of JMX attributes to collect for the hdfs namenode, datanode and accumulo-tserver)

[rhuss]

There is still the plan to introduce Prometheus as alternative protocol to Jolokia 2, however there are no concrete time line (and we are all packed these days ;-(. I believe it has some important features and along with health checks (which also needs a custom config) would be able to provide the best of all worlds ;-)

BTW, if you like to share your JMX coordinates with which you monitor your Hadoop cluster, this would be awesome. Just need a place to collect it, it was traditionally done as Nagios checks but I guess a different format would be ok, too.

[MarcinPrzadlo]

@rhuss A year later (July 2018)... , do we have any news on Jolokia 2.0 and/or integration of Jolokia with Prometheus?

In the meantime I've found Scalify/jolokia_exporter (and not tried yet)
but not sure if I should invest time for this assuming native is around a corner (I wish)

[rhuss]

Sorry, no much news on 2.0 except that its still pending (but not forgotten). It's just quite low on my priority list theses days. However, I'm able to pick it up again soonish, still before the end of the year.

sorry ...

[Hadlock]

We are limping along using JMX exporter (packaging it alongside AMQ inside the container), but would greatly prefer a native prometheus endpoint or similar. JMX does not stay on statically assigned ports which has been causing problems in containers, which expect static port assignments. Also going to check out jolokia_exporter.

Can we please reopen this issue so it is being tracked

[rhuss]

I can reopen this, but tbh I don't think that a Jolokia agent is much more native than the Prometheus jmx_exporter as it used the same technique for attaching to a JVM.

The problem for Jolokia is that up to now Jolokia is stateless in the sense it doesn't require any server side configuration. However for allowing an efficient scraping from Prometheus one would need some sort of whitelisting to avoid excessing query over the whole JMX space (which consist 90% of configuration data exposed via JMX).

Together with the health checks which also needs local configuration it would make sense to make this paradigm switch.

But agreed, let's reopen it to not forget it.