New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

dotnet core support #32

Open
rdghickman opened this Issue Jul 6, 2016 · 28 comments

Comments

Projects
None yet
@rdghickman

rdghickman commented Jul 6, 2016

Is there currently any plan for the Metrics.NET library to be made compatible with the dotnet core framework? If not, are you open to any PR that may attempt this?

@niemyjski

This comment has been minimized.

niemyjski commented Jul 12, 2016

+1

@rdghickman

This comment has been minimized.

rdghickman commented Jul 13, 2016

Currently I see a bunch of dependencies that are blockers (though these are mostly not for the actual core Metrics code) and a few things in the actual codebase that are not in dotnet core namespaces (Configuration, the MethodImpl.Synchronized attribute, some things in the Environment, etc.). I'm not an expert at porting this stuff but the effort is not completely trivial. There's some question here as to what the project should support going forward (ie. is Mono still relevant if targetting core?). I haven't gotten around to looking at the test code.

@niemyjski

This comment has been minimized.

niemyjski commented Jul 13, 2016

I'd just target only netstandard and be done with it (it should work everywhere). This site really helps with upgrading packages: http://packagesearch.azurewebsites.net/ More things in environment have been moved around and some will be coming back this fall. If you have any questions, please let me know.

@rdghickman

This comment has been minimized.

rdghickman commented Jul 13, 2016

I tend to agree about only supporting netstandard. I'll update this thread if I do end up with a working port of this, but I can't commit to it as of right now.

@tsibelman

This comment has been minimized.

Contributor

tsibelman commented Jul 15, 2016

I also took a look , it looks the biggest problem is HttpListener that is removed from .net core, it replaced by Kestrel web server. I think it will be much easier to port Metrics if it could be separated into core project and one or more extensions projects. This way it would be possible to move gradually to .net core, also it will provide leaner and cleaner core library. If maintainers see it as a good way forward I can work on PR with my suggested separation.

@niemyjski

This comment has been minimized.

niemyjski commented Jul 15, 2016

Why would a metrics project have a http listener?

@tsibelman

This comment has been minimized.

Contributor

tsibelman commented Jul 16, 2016

It used for pulling metrics data from application, also it used by build in web ui

@tsibelman

This comment has been minimized.

Contributor

tsibelman commented Jul 25, 2016

@PaulParau What do you think about my suggestion would you accept such pull request where I separate Metrics into core project and one or more extensions projects?

@PaulParau

This comment has been minimized.

Member

PaulParau commented Jul 25, 2016

In principle yes, splitting optional parts from the "core" sounds like a good idea. We had thought about separating components such as the Elastic Search and InfluxDB reporters into separate projects. Not only would this improve the maintainability of the entire project but, like you said, it would make it easier to eventually add dotnet core support.

Do you have an idea about what would have to be separated, i.e. what those extension projects would be? I'm asking because some thing are trivially separable (like the reporters I mentioned) while other parts bring value to the core metrics library and separating them should be carefully considered (e.g. metrics visualization, text reports - which are served by the HttpListener).

I'll also discuss this with the other maintainers and get back with a more concrete response :)

@PaulParau

This comment has been minimized.

Member

PaulParau commented Jul 30, 2016

I've discussed this further with the team: we're OK with removing optional parts (e.g. reporters I mentioned), but we'd rather not remove features like those served by the HttpListener. Without those, the core metrics library would have no built-in reporting support and would need to be used together with another package.

@tsibelman

This comment has been minimized.

Contributor

tsibelman commented Jul 30, 2016

In this case HttpListener based implementation need to be rewrite to use Kestrel web server for this purpose. I will take a look into how complex it is.

@mribichich

This comment has been minimized.

mribichich commented Aug 20, 2016

+1

1 similar comment
@alhardy

This comment has been minimized.

Contributor

alhardy commented Sep 20, 2016

+1

@alhardy

This comment has been minimized.

Contributor

alhardy commented Sep 22, 2016

I've copied across the Metrics.NET core project to my aspnet core integration project and stripped it down so it could be upgraded to dotnet core. Stripped down but it works! What's been removed?

  • Remote Metrics related stuff
  • HttpReporter (I do still get the /json endpoint using the middleware i've written in aspnet core)
  • CSV Reporter
  • All the other reporters graphite, influxdb
  • Performance counter stuff
  • Visualization stuff (Is anyone actually using this? I'm guessing most are pushing to influxdb, graphite or es)
  • A few other things commented out around
    - properties on the Environment class
    - I didn't bother with appsettings (Metrics.GlobalContextName, Metrics.CompletelyDisableMetrics)
    - IP Address resolution

There are currently two sample projects in the solution Api.Sample and Mvc.Sample to test it out, metrics are visible at /json or /metrics for each sample respectively.

alhardy/aspnet-metrics@9031ae4

Should we just create a completely new project with dotnet core support and reporters etc broken out to separate projects with this repo?

@PaulParau

This comment has been minimized.

Member

PaulParau commented Sep 26, 2016

While I agree with removing the evidently non-core stuff (reporters - separating them is actually in progress), I'm a bit concerned about the others (e.g. HttpListener, Visualization - I think it's still useful in certain scenarios).

.NET Core support is not a priority for us now (we're focusing right now on getting the next stable release out the door), but we'll look into it and clarify whether we want to go forward with it and the way we want to do it.

@rudygt

This comment has been minimized.

rudygt commented Nov 2, 2016

I worked on this some time ago, I got the basics working on core using nancyfx + kestrel for the self hosting. the ui works.

there is the branch if someone wants to give it a look

https://github.com/rudygt/Metrics.NET/tree/CoreClrPrototype

Regards

@slawomirbrys

This comment has been minimized.

slawomirbrys commented Mar 21, 2017

Is anybody working on porting this lib to .Net Core?

@niemyjski

This comment has been minimized.

niemyjski commented Mar 21, 2017

I'm not sure, I've been trying to gauge when this will be available so I can update our foundatio metrics implementation for this lib (https://github.com/exceptionless/Foundatio#metrics)

@alhardy

This comment has been minimized.

Contributor

alhardy commented Mar 21, 2017

@slawomirbrys @niemyjski I tried by providing a POC. I ended up porting Metrics.NET to App.Metrics. Things slowed down since @etishor unfortunately.

My port is a significant redesign, some functionality is removed to support a .NET Standard library as mentioned in previous comments, however new functionally also exists.

I was using Metrics.NET for years and contributed the OWIN package, unfortunately I was not able to get any guidance or direction on dotnet core and after efforts made to provide a POC it was mentioned that it was not a priority to support dotnet core.

My first attempt to continue with Metrics.NET and dotnet core was implementing https://github.com/alhardy/aspnet-metrics which has a dependency on Metrics.NET, however this limits to the full framework.

@danielmarbach

This comment has been minimized.

Contributor

danielmarbach commented Apr 6, 2017

@niemyjski

This comment has been minimized.

niemyjski commented Apr 6, 2017

@cocowalla

This comment has been minimized.

cocowalla commented Jun 5, 2017

@niemyjski I'd have to agree.

Visualisations and an HTTP endpoint are definitely nice to have for some systems, but I certainly don't see them as a core part of a metrics library. I struggle to see any reason not to have these as separate packages.

@PaulParau is there likely to be any movement on this in the near future, or is App.Metrics now the best option where .NET Standard support is required (which would be most greenfield projects, I would think)?

@niemyjski

This comment has been minimized.

niemyjski commented Jun 6, 2017

@cocowalla you could also check out foundatio :) https://github.com/exceptionless/foundatio#metrics

@cocowalla

This comment has been minimized.

cocowalla commented Jun 6, 2017

@niemyjski actually, I did have a look yesterday :) But I'm already using Serilog for logging, am using Quartz.net for jobs, have already implemented my own async queue, and have already implemented my own in-memory caching mechanism. The only bit I'm missing is metrics.

Could have saved some time if I'd been aware of foundatio beforehand!

@alkampfergit

This comment has been minimized.

alkampfergit commented Mar 28, 2018

Any news for this issue? Actually we really love Metrics.NET library, but without .NET core support we will need to move to another library.

@niemyjski

This comment has been minimized.

niemyjski commented Mar 28, 2018

@alkampfergit

This comment has been minimized.

alkampfergit commented Mar 28, 2018

I'll give it a try. :)

Many thanks.

@alhardy

This comment has been minimized.

Contributor

alhardy commented Mar 31, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment