feat(metrics): introduce MetricsUtils.withMetricsLogger utility

[humanzz]

closes #999

Issue #, if available: #999

Description of changes:

introduce new MetricsUtils.withMetricsLogger utility method to enable higher level of customization to the metrics logger and eliminate the need to know the metric/configuration when calling the method and leave that instead to the Consumer<MetricsLogger>

The main use case my team has

1. We're emitting a number of metrics - ~10 metrics - that all have the same config (e.g. dimensions) that's meant to be different from MetricsUtils.metricsLogger() i.e. we need a new metrics logger instance
2. The names of those metrics are generated dynamically - think loops, appending different constants - to generate those names

So, ideally, we create a new instance of a metrics logger, and then rely on to emit those 10 different metrics.

Checklist

• Meet tenets criteria
• Update tests
• Update docs
• PR title follows conventional commit semantics

Breaking change checklist

RFC issue #:

• Migration process documented
• Implement warnings (if it can live side by side)

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

[msailes]

LGTM

[msailes]

LGTM

[scottgerring]

Looks good to me @humanzz - I have one question on the changed body of the try / finally inline

[kozub]

It looks also good for me.

The only concern that I have is about naming. Right now we have two methods: withSingleMetric() and withMetric() - without the context I would have no idea what is the difference. Not sure if .withCustomMetric() or .withConfigurableMetric() sounds better. What do you thing? I don't have strong opinion what will be more natural for end user.

[humanzz]

@kozub

It looks also good for me.

The only concern that I have is about naming. Right now we have two methods: withSingleMetric() and withMetric() - without the context I would have no idea what is the difference. Not sure if .withCustomMetric() or .withConfigurableMetric() sounds better. What do you thing? I don't have strong opinion what will be more natural for end user.

The names are also throwing me off a bit tbh as well. I am between

• singular withMetric
• plural withMetrics
• withMetricsLogger to really be super explicit, which I think is more in line with MetricsUtils.metricsLogger() and is actually more telling about what it provides.

I'm more leaning towards the last one now that I think about it and will make a change.

Let me know what you think

[kozub]

Hey @humanzz

I think that .withMetricsLogger() sound more natural than previous version. Thanks for that change.
Idea of having .withMetric() and .withMetrics() is also interesting, but unfortunately it introduces some breaking changes so we won't be able to release it so quickly.

[humanzz]

@kozub @scottgerring apologies folks. Had to make an additional commit to fix a documentation typo

[msailes]

Approved