Upgrade armon/go-metrics to hashicorp/go-metrics

[mkeeler]

This will require a major version bump in the library as it changes which global metrics handler gets used (due to the module renaming)

[aknuds1]

@mkeeler are you sure a major version bump is required, since according to semver you're free to make breaking changes so long as you're on major version 0?

[mkeeler]

@aknuds1 From an exported API perspective nothing would be broken. The main reason I would advocate for a major version bump would be to signal to consumers that they may need to take some action to make things work properly. Because hashicorp/go-metrics and armon/go-metrics look like distinct modules to Go, both could potentially be compiled into one tool. If the application is configuring metrics handlers for armon/go-metrics (which has its own global metrics instance) and memberlist emits metrics to hashicorp/go-metrics, then the memberlist metrics likely would not show up in how the application is recording them (prometheus, dogstatsd etc.)

IMO all this points to some larger changes being needed in these libraries. Instead of using a default global metrics instance the library ought to allow configuring and interface or a set of callbacks to be used when emitting metrics. That way the application consuming the library is in full control of metrics emission.

[aknuds1]

Instead of using a default global metrics instance the library ought to allow configuring and interface or a set of callbacks to be used when emitting metrics.

That sounds like the right approach to me.

[balena-zh]

+1

[adamrothman]

@rboyer @jmurret @huikang @NodyHub can we get some 👀 on this?