Exposing MP Config properties for individually disabling metrics providers

[rhusar]

Following up on fixing CompoundMetricsProvider #1072, I am starting to think that we need to expose MP Config properties for cases when multiple metrics providers are discovered (either by mechanism built-in to SR FT or by the mechanism that WF uses) to handle scenarios when in a single deployment, users elect to use MP Telemetry for tracing, yet want to e.g. continue using Micrometer for MP FT metrics collection. While Telemetry has specific properties for disabling, it would disable for the whole deployment. MP FT has properties for only disabling metrics altogether. While the MP FT spec is alright with collecting metrics with multiple providers simultaneously (which is beneficial for gradual migration or monitoring systems compatibility), there are drawbacks such as performance implications, potentially duplicated metrics if feeding into the same metric. Thoughts?

[Ladicek]

We could do that, sure. How about properties like this?

smallrye.faulttolerance.mpmetrics=true|false
smallrye.faulttolerance.opentelemetry=true|false
smallrye.faulttolerance.micrometer=true|false

[Ladicek]

Actually those property names might be misleading. The only purpose of them is to disable a metrics provider when it was discovered; when it was not discovered, there's no way to enable it. So probably something like

smallrye.faulttolerance.mpmetrics.disabled=true|false
smallrye.faulttolerance.opentelemetry.disabled=true|false
smallrye.faulttolerance.micrometer.disabled=true|false

would be better.

[rhusar]

Actually those property names might be misleading. The only purpose of them is to disable a metrics provider when it was discovered; when it was not discovered, there's no way to enable it. So probably something like

smallrye.faulttolerance.mpmetrics.disabled=true|false
smallrye.faulttolerance.opentelemetry.disabled=true|false
smallrye.faulttolerance.micrometer.disabled=true|false

would be better.

Please remember that we have already exposed some SR FT-specific configuration properties. For that, we should use the same prefix and style (camel case... ouch) :-)

Namely:
io.smallrye.faulttolerance.mainThreadPoolSize
io.smallrye.faulttolerance.mainThreadPoolQueueSize

[Ladicek]

Yeah... no. That's a very old style. I started using smallrye.faulttolerance.something-something with smallrye.faulttolerance.mp-compatibility and I'm gonna continue with that.

I can adjust these old names too, if you like.

[rhusar]

Gotcha, no, no need to adjust the old ones.

In that case these - #1078 (comment) - make sense to me 👍🏼

[Ladicek]

The PR to 6.6 is here: #1080