Metrics collected by jolokia module are stored now in events with fields like jolokia.<namespace>.<custom field name>, with the field name allowed to have dots. This makes impossible to provide a mapping, and it can provoke fields explosion in complex deployments.

This module could be refactored following the strategy followed in more recent "generic" metricsets implementations as prometheus collector or aws cloudwatch, where all metrics are stored under the same object (prometheus.metrics.* and aws.metrics.*.*), so we can provide a mapping for all fields.

There are two things that can condition the decision on the structure:

• APM agent for Java is also able to collect metrics from JMX, it'd be good to follow the same naming (discussed in Collect metrics from JMX apm-agent-java#469).
• In contrast to prometheus, where all metrics are doubles, JMX can return non-numeric values, we will have to consider if we provide a different namespace for them.

If it is done as a replacement of current implementation it will have to be done in 8.0, alternatively we can consider to make it as a new metricset, or add a flag to chose what naming to use.

We would still need to offer the possibility of define explicit mappings to continue supporting light modules like tomcat (see example) or other custom usages.

Possibly related issues:

• Structured metricset for Jolokia Module #3585
• Extract fields from mbeans in Jolokia metricset #13604