Add support for the Strimzi Metrics Reporter

[fvaleri]

This patch adds support for the Strimzi Metrics Reporter.

Setting bridge.metrics=jmxPrometheusExporter enables the JMX Prometheus Exporter (equivalent to KAFKA_BRIDGE_METRICS_ENABLED=true). Setting bridge.metrics=strimziMetricsReporter enables the new Strimzi Metrics Reporter as Kafka plugin.

When selecting the strimziMetricsReporter, you also need to add the plugin configuration as in the following example:

bridge.metrics=strimziMetricsReporter
kafka.metric.reporters=io.strimzi.kafka.metrics.KafkaPrometheusMetricsReporter
kafka.prometheus.metrics.reporter.listener.enable=false
kafka.prometheus.metrics.reporter.allowlist=.*

See strimzi/proposals#143 for more details.

[fvaleri]

@OwenCorrigan76 @mimaison fyi

[mimaison]

I've not looked at the code yet. I left comments trying to understand how this will be used.

[mimaison]

From a configuration standpoint I would expect that users would just need to set bridge.metrics=strimziMetricsReporter and maybe the allowlist and not set the other individual configurations kafka.prometheus.metrics.reporter.listener.enable, kafka.metric.reporters.

[fvaleri]

This is how it will work when using the Cluster Operator. Talking with @ppatierno, we agreed that, for the standalone Bridge, the user should be free to set all configurations through the properties file.

[ppatierno]

Yeah. When bridge is running on bare metal / VM, it's the user to provide the application.properties file for the bridge with its configuration. The bridge doesn't have to change the properties file in any way enforcing other parameters which the user didn't set.

[scholzj]

I wonder if this should go through a dedicated proposal first. The original proposal - https://github.com/strimzi/proposals/blob/main/064-prometheus-metrics-reporter.md - sadly didn't cover the bridge in sufficient depth and there will be some backward compatibility impact here or in the operators repo that needs to be carefully considered. A proposal would be the right place to discuss it and decide on the best approach.

[fvaleri]

there will be some backward compatibility impact here or in the operators repo that needs to be carefully considered

I agree. Probably the backwards incompatible changes are mostly on the operator side, where we have to introduce metricsConfig at the CRD level. @ppatierno wdyt?

[ppatierno]

I left just some minor comments but I will review it again when the proposal is accepted (to avoid reviewing now something that will be changed later by the final proposal)

[ppatierno]

Yeah. When bridge is running on bare metal / VM, it's the user to provide the application.properties file for the bridge with its configuration. The bridge doesn't have to change the properties file in any way enforcing other parameters which the user didn't set.