Allow disabling metrics collection in SwiftMetrics integration

[dankinsoid]

Currently, RedisStack automatically emits a large number of metrics using SwiftMetrics, and there is no way to turn this off.
This is problematic for production environments where external metrics backends (like InfluxDB, Prometheus, or StatsD) are used with limited quotas or billing per datapoint.

For example, after enabling RedisStack in an application that reports to InfluxDB, the metric volume became so high that it consumed the entire monthly limit overnight.

Here’s a screenshot of InfluxDB usage - the big spike at the end comes from RediStack:

This happens even when metrics are not essential for monitoring or debugging.

It would be very helpful to have a way to disable metrics entirely, similar to what Vapor allows with:

app.http.server.configuration.reportMetrics = false

[czechboy0]

Hi @dankinsoid,

I think from an ecosystem perspective, instead of every library making this configurable, it would be easier if you implement a MetricsFactory that filters your metrics, and wraps your existing MetricsFactory.

You can keep the ones you find important and drop the rest. That way, even when metrics are emitted by dependencies you don't directly use, deep in the dependency graph, you can still have full control over your exported metrics.

[czechboy0]

This might even be a reasonable ask to include in Swift Metrics out-of-the-box, if you're up for opening an issue there.

[dankinsoid]

@czechboy0
The swift-metrics API doesn’t provide a reliable way to categorize or namespace metrics. Unlike logs, where I can filter by source or fileID, metrics can only be filtered manually by inspecting their labels. That’s fragile and will immediately break if RediStack changes existing metrics or adds new ones.

I agree it would be ideal if swift-metrics supported something like this out-of-the-box, but that would require changes to the library’s public API, which seems unlikely to happen.

[czechboy0]

I think those are two separate topics:

1. Adding a filtering metrics factory to Swift Metrics, using metric names and labels
2. Extending the metrics factory abstraction itself to require passing in metadata like file ID

I believe that 1 can be done today, within an adopter's project, and then potentially upstreamed to be offered as an extra concrete metrics factory in Swift Metrics.

You're right that 2 is unlikely to happen in the short term, but do feel free to also open an issue for that in Swift Metrics.

[czechboy0]

Regarding the specific concern of metric names and labels changing in RediStack, that's extremely unlikely to happen within this major version, and could be argued to be a breaking change. I can't speak for other libraries, it depends on how exactly each maintainer interprets semantic versioning.