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

[mkeeler]

Also bumping hashicorp/memberlist to the corresponding version which also uses hashicorp/go-metrics

This will require a new major version to signify that metrics are using different global handlers.

TODO:

• Merge Upgrade armon/go-metrics to hashicorp/go-metrics memberlist#287 and pull in the new memberlist version

[puffpuf]

can someone merge it, please?

[peczenyj]

+1 here

I need to the line below several go.mod files and it is annoying

replace github.com/armon/go-metrics v0.5.1 => github.com/hashicorp/go-metrics v0.5.1

[peczenyj]

fix issue #707

[alex-savin]

+1 here

[peczenyj]

any reason to not merge it ?

[adamrothman]

@mkeeler @hashi-derek can we get some 👀 on this?

[frebib]

Bump please; without this patch, this library is completely unusable/broken for anyone using it, or pulling in something that uses it

[shane-ns1]

Wow this PR is more than a year old! Is the repository completely unmaintained? 😬

[peczenyj]

@shane-ns1 looks like ...

[peczenyj]

perhaps we should start to ping @dhiaayachi and other people that can merge on this repo

[shane-ns1]

perhaps we should start to ping @dhiaayachi and other people that can merge on this repo

Or even @armon? 😆

[jmurret]

Hi all, we will post a more detailed thread on why this is complicated, but the short gist is that this change has to be consistently updated across the dependency chains of libraries used in an application. go-metrics relies on a singleton sink in global state. If any applications have a mix of armon metrics and hashicorp due to underlying dependencies not aligning on only one of them, metrics will be split among different sinks in the global state.
This change has to be coordinated with changing and releasing this dependency across multiple libraries and applications in a thoughtful way. This PR is taking longer than expected due to the prioritization and coordination of those efforts to ensure a smooth transition. Thank you for your patience and understanding.

[shane-ns1]

It's been 18 months since this was opened, and 5 months since the last comment, but I think that this is still an issue.

Is there anything that anyone can do to help?

[mkeeler]

After authoring these PRs originally, we came to the realization that the problem wasn't quite so simple and we were going to have a difficult time rolling out the changes in a safe way across many libraries, products, services and applications. Safe here meaning where we don't accidentally lose metrics.

Recently I have spent some more time working on the problem and found an approach that I think will be better. The gist is that I am introducing a compatibility package into hashicorp/go-metrics. This exposes an identical API to that of the latest armon/go-metrics tag. The compat package can be controlled with build tags to choose which metrics package is actually used (either armon/go-metrics with a armonmetrics tag or hashicorp/go-metrics with a hashicorpmetrics tag - default is still armon/go-metrics). I am now updating all our libraries which use armon/go-metrics to use this compatibility package instead. As a consumer of this library you are free to set the build tags as you wish to control which metrics library is compiled in.

The big advantage I see with the build tagged approach is that the top level application performing the go build is in control of which metrics library is used for all the libraries. This is especially important for many repos within the hashicorp namespace that each use many of the libraries.

I am hoping to have all the libraries PR'ed and merged before the end of the month.