Provide property to disable exemplar

[anderslauri]

Please describe the feature request.
Provide property to disable exemplar.

Rationale
Accordingly to https://cloud.google.com/stackdriver/docs/managed-prometheus/exemplars#prom-exemplars-gcm - counters with exemplars are not supported and ingestion is not possible. This PR (#3996) enables exemplars - however - providing no ability to disable (without additional changes in code). As our client upgraded to Spring Boot 3.2. This upgrade, caused disruption of metrics ingestion, into Managed Prometheus on GCP.

Additional context
I do agree on responibility, to ensure Prometheus compatibility, is on Google. However, at the same time, I do not see the additional flexibility to opt-out as something inherently negative.

[marcingrzejszczak]

Do you want the exemplars to be disabled in Spring Boot or where exactly?

[anderslauri]

Do you want the exemplars to be disabled in Spring Boot or where exactly?

Within the implementation package of Prometheus metrics.

[marcingrzejszczak]

PrometheusMeterRegistry takes in a ExemplarSampler. Since it's an interface you can set it up in whatever way you want, also that conditionally disables this.

[anderslauri]

PrometheusMeterRegistry takes in a ExemplarSampler. Since it's an interface you can set it up in whatever way you want, also that conditionally disables this.

Obviously different options exists for managing this. However, the proposition for enhancement, is regarding a property flag to control usage of exemplars. If this is not deemed suitable - we can close this request.

[jonatan-ivanov]

The PR you are talking about "just" extended the exemplars support, Micrometer supports Exemplars for a while.

Please take a look at PrometheusMeterRegistry:

micrometer/implementations/micrometer-registry-prometheus/src/main/java/io/micrometer/prometheus/PrometheusMeterRegistry.java

Lines 68 to 85 in edc3289

	public PrometheusMeterRegistry(PrometheusConfig config) {
	this(config, new CollectorRegistry(), Clock.SYSTEM);
	}
	public PrometheusMeterRegistry(PrometheusConfig config, CollectorRegistry registry, Clock clock) {
	this(config, registry, clock, null);
	}
	/**
	* Create a {@code PrometheusMeterRegistry} instance.
	* @param config configuration
	* @param registry collector registry
	* @param clock clock
	* @param exemplarSampler exemplar sampler
	* @since 1.9.0
	*/
	public PrometheusMeterRegistry(PrometheusConfig config, CollectorRegistry registry, Clock clock,
	@Nullable ExemplarSampler exemplarSampler) {

If you use the first two ctors, exemplars support will be disabled. If you use the third ctor and pass a null ExemplarSampler, exemplars support will be disabled. Exemplars support will only be enabled if you use the third ctor and pass a non-null ExemplarSampler.

We already have a signal to enable/disable exemplars, I'm not sure why should we make this more complicated with adding an extra (redundant) property.

There is also an additional workaround in case you always want to inject something non-null: You can use your own implementation of ExemplarSampler (i.e.: noop) instead of DefaultExemplarSampler. You can also use DefaultExemplarSampler and your own implementation of SpanContextSupplier that always returns false in isSampled and it can return null for the spanId and traceId. You can play with them in our samples.

If you want a property in Spring Boot to not auto-configure DefaultExemplarSampler, you should open a new issue in the Boot repo.

Btw I'm not sure if this is an option but if you can make StackDriver asking for the "Prometheus format" not the "OpenMetrics format" (text/plain vs. application/openmetrics-text in the Accept header), the former does not support exemplars so that StackDriver should have no issues parsing it.