cloud-green / jmx-exporter-charm Goto Github PK

It would be nice to add the unit name to metrics, especially when they apply to several different applications. Currently only the IP:port is shown. See example below.

Would be much nicer to tag metrics with the relation peer's unit and application name, so we can constrain queries easily when exploring Prometheus. So if jmx-exporter is related to kafka, the tags might be application=kafka, unit=kafka/0.

✔
java_lang_Memory_HeapMemoryUsage_used{group="promoagents-juju",instance="10.15.118.9:4081",job="jmx-exporter"}
✔
java_lang_Memory_HeapMemoryUsage_used{group="promoagents-juju",instance="10.15.118.8:4081",job="jmx-exporter"}
✔
java_lang_Memory_HeapMemoryUsage_used{group="promoagents-juju",instance="10.15.118.7:4081",job="jmx-exporter"}
✔
java_lang_Memory_HeapMemoryUsage_used{group="promoagents-juju",instance="10.15.118.16:4081",job="jmx-exporter"}
✔
java_lang_Memory_HeapMemoryUsage_used{group="promoagents-juju",instance="10.15.118.15:4081",job="jmx-exporter"}
✔
java_lang_Memory_HeapMemoryUsage_used{group="promoagents-juju",instance="10.15.118.14:4081",job="jmx-exporter"}
✔
java_lang_Memory_HeapMemoryUsage_used{group="promoagents-juju",instance="10.15.118.13:4081",job="jmx-exporter"}
✔
java_lang_Memory_HeapMemoryUsage_used{group="promoagents-juju",instance="10.15.118.12:4081",job="jmx-exporter"}
✔
java_lang_Memory_HeapMemoryUsage_used{group="promoagents-juju",instance="10.15.118.10:4081",job="jmx-exporter"}

jmx exporter is creating jetty metrics, like this:

org_eclipse_jetty_util_thread_strategy_HTTP_1_1_4c41a177_stopTimeout
org_eclipse_jetty_util_thread_strategy_HTTP_1_1_4491eaeb_stopTimeout
...

These should be filtered out of the default jmx config because they don't seem useful and only add noise to the Prometheus UI.

Our other Java-based projects (zookeeper, kafka) are built as snaps to isolate build as well as runtime dependencies. The same should be done here. snapcraft will then take care of installing the necessary build dependencies in a repeatable way. Otherwise the build will depend on whatever version of java and mvn happens to be installed on the system -- this will make for unpredictable builds.

The submodule could probably be replaced with a snapcraft source: entry that points at the upstream repo.

There is also a mvn plugin for snapcraft that you might find helpful.