adding App Metrics - https://github.com/alhardy/AppMetrics

[alhardy]

CATEGORY/PROJECT_NAME - PROJECT_LINK

PROJECT_DESCRIPTION

[alhardy]

@quozd re-created my PR #446 to kick off another build due to failures. Looks like my branch is already up to date with master but getting a different build error now?

[pleb]

@zihotki Thoughts?

[zihotki]

I see that the library is a port of Metrics.Net to netstandard platform. It was refactored, cleaned and the project structure has been improved by a lot. The fork itself is new, but core code for metrics calculation is mostly the same. Alhardy made really good progress and improved project structure, all decisions seem to be very reasonable.
Metrics.Net has been abandoned for a couple of years and only recently got some progress (I see that the ownership has been transferred to new person, more discussions, etc.), also that they don't have any visible roadmap and vision so it would take some time to settle everything there.
If I was asked to choose between App Metrics and Metrics.Net I would go with 1st. As for including in the list, I would definitely include both of them.

[quozd]

If Metrics.Net is abandoned, we shouldn't add it to the list. AppMetrics looks ok.

[alhardy]

Metrics.NET isn't abandoned however there is not much progress being made there at all. I contributed Owin.Metrics a while back, the project was very active back then with the original owner, I see the project very useful and have used it in my day job for a couple of years now so am keen to keep it alive by freshening it up and adding new features.

Before porting I did attempt to get a .NET Standard build underway see etishor/Metrics.NET#133 and Recognos/Metrics.NET#32 and a POC here. I also created an ASP.NET Core full framework solution using Metrics.NET. However I really wanted:

• a cross platform solution but also keeping support for older versions of the .net framework
• clean up the solution to make it more maintainable, quicker to add features and follow a more modern API into the library
• keep the project going by adding new features, I have plans for plenty once I'm happy with the inital clean up e.g. Apdex support, alerting, possibly a glimpse extension, ETW events rather than perf counters for those on windows, filtering via url for those using a pull based approach to report metrics, possibly out of process agent using ETW.
• reporters to be moved to separate packages to make it easier to contribute new reporters
• a hopefully more active project with new ideas

I've given credit to the original owner in the documentation and code files where required, this is mainly the concurrency utils and reservoir sampling code that has been written (originally ported from java). I've benchmarked this with other solutions, he's done an amazing job there, there looks to be no need to touch that as yet, I still need to run some tests and compare against a timseries db. The only thing I'll be changing there at the moment is the HdrHistogram implementation with HdrHistgram.NET I'm currently in the process of finishing up a PR to that repo to target .NET Standard.

[pleb]

Thanks @zihotki for that excellent summary. I think based on @zihotki's input and @alhardy's response, we all agree for the inclusion of this library. Given that Metrics.Net is not abandoned but has limited recent progress, we'll skip adding it at this time - which addresses @quozd well-founded concerns. If somebody else submits a PR for it in the future, we can tackle this outstanding question at that point.