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?

[Tochemey]

Any progress on this issue?

[mkeeler]

For those watching, we have decided to take a different approach with migration to hashicorp/go-metrics. Changing all the libraries to use pluggable metrics provider interfaces was proving to be difficult to get the interface right for all uses and knowing that the community has been in need of this for so long we chose to take a bit more pragmatic approach. The goal is still to not surprise anyone with where metrics are emitted and to do as much as possible to prevent mismatched dependencies from causing some metrics to land in the armon/go-metrics global handler while others land in the hashicorp/go-metrics global handler.

To that end build tags now control which metrics stack this library and others in the hashicorp namespace use to emit metrics. That will allow application authors to globally opt-in to one module or the other for all hashicorp libraries.

PR #315 was created to make these changes and has been merged and released as v0.5.2.

Documentation for migrating your metrics usage can be found in the README

TLDR: pull in v0.5.2 of memberlist and instrument your build system to set the hashicorpmetrics build tag.