Refactor Jolokia metrics to provide dynamic mapping

[jsoriano]

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

[jsoriano]

Related discussion for the SQL case, where there are also multiple data types: #13257 (comment)

[botelastic]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[kaiyan-sheng]

@jsoriano Are we still considering making this breaking change for 8.0?

[jsoriano]

@kaiyan-sheng I wouldn't consider it so prioritary and I don't think we are going to have time for this. So I think we can close this.

If at some moment we can dedicate a little of time to this I would consider #13604 more valuable for current users, and is probably a low-hanging fruit.

And if we can or need to dedicate more efforts we can re-consider how we collect JMX metrics, and this could be done in a new module/integration (something like what was discussed in #18324). Agent opens the gates to have a native Java collector that could be used to avoid the requirement of Jolokia.

Pinging @akshay-saraswat for awareness.