Is it always 3 parts: metric name (may contain underscore), field name (camelcase), metric type (camelcase)? If so, I think the regex processor could work if we added support for modifying the measurement. Could you open a github issue for this feature?
Perhaps it can be modified in the exporter configuration? Is it possible to modify name: kafka_server_$1_$2 to be name: kafka_server.$1_$2?
Finally, you could investigate switching from the exporter you are using for JMX to the jolokia2 plugin, you may be able to get better results this way.
Sure thing, I will be happy to open a Git issue, I think in the absolute this is a use case that is interesting, explicit renames are great things but something with regex capabilities would be much more powerful and fill various potential requirements for users.
To reply to your question, no this is not necessary 3 segments that define the metric name as this relies on the naming convention used by the Java classes, which could probably be anything.
However, if the extended regex supports capturing groups, then one could have different rules to match his use case, and used the captured group to form the metric.
Regarding Jolokia2 plugin I like it very much and this is what I primary use and recommend to implement my apps, however my goal is the have both Jolokia and Prometheus JMX exporter be compatibles with my implementation, specially for people running Kafka deployment in Kubernetes.
In Kubernetes world, most Kafka deployments promote the usage of Prometheus exporter running as a side car within the pod, so it makes sense to comply with both options.
Thanks for opening the issue. I would like to get have this working well with the Prometheus JMX exporter as well, so please don’t take this as any indication that I don’t want to support this method, but you might also consider running Telegraf as a sidecar for the pod. We do this internally and have had good success with this method: Monitoring Kubernetes Architecture | InfluxData
The regex processor does support capture groups, so I think adding feature will be enough. My only concern is if you will always be able to segment the input measurement into it’s parts using a regular expression, it may be hard to determine where to split the components.