Support for other metrics providers (rcrowley/go-metrics is no longer maintained)

[villevaltonen]

Description

Sarama relies on rcrowley/go-metrics for producing metrics and this library has been archived. Are there any plans for adding first-hand support for other common observability frameworks like OpenTelemetry or Prometheus?

Additional context

• rcrowley/go-metrics

[github-actions]

Thank you for taking the time to raise this issue. However, it has not had any activity on it in the past 90 days and will be closed in 30 days if no updates occur.
Please check if the main branch has already resolved the issue since it was raised. If you believe the issue is still valid and you would like input from the maintainers then please comment to ask for it to be reviewed.

[vitaliyf]

Please review.

[trever-atr]

@burke @bai @wvanbergen @dnwe @eapache

sorry to bother you, but can anyone have a look at this?
our SBOM tools flag this as an issue.

go-metrics is unmaintained and archived, the author recommends the OpenTelemetry Go SDK as a replacement.

this was mentioned once before: #2832

[dnwe]

It’s a tricky one because it’s not something we can easily do in a v1 release. We’d have to jump to /v2 to make the breaking change and we’ve had requests for both minimal native Prometheus client metrics and fuller Opentelemetry metrics so there isn’t an obvious best option right now

[github-actions]

Thank you for taking the time to raise this issue. However, it has not had any activity on it in the past 90 days and will be closed in 30 days if no updates occur.
Please check if the main branch has already resolved the issue since it was raised. If you believe the issue is still valid and you would like input from the maintainers then please comment to ask for it to be reviewed.

[vitaliyf]

Not stale.

[github-actions]

Thank you for taking the time to raise this issue. However, it has not had any activity on it in the past 90 days and will be closed in 30 days if no updates occur.
Please check if the main branch has already resolved the issue since it was raised. If you believe the issue is still valid and you would like input from the maintainers then please comment to ask for it to be reviewed.

[vitaliyf]

Not stale.

[mvanhorn]

I think this can be addressed incrementally within v1, without breaking the existing public API.

The idea: introduce a MetricsProvider interface alongside the existing MetricRegistry field. The interface defines only the metric-type factory methods sarama actually uses (Counter, Histogram, Meter, Gauge). A default GoMetricsProvider wraps the current rcrowley/go-metrics behavior. A new optional Config.MetricsProvider field lets users swap in OTel, Prometheus, or any other backend.

When MetricsProvider is nil (the default), the existing MetricRegistry path is used unchanged. When set, MetricsProvider takes precedence. This keeps full backward compatibility while unblocking alternative backends.

Scope for an initial PR: interface definition, default wrapper, Config field, and tests. No bulk migration of existing callsites - that can happen incrementally in follow-up PRs.

I'll put together a PR if there's interest.