A couple of years back I forked Metrics.NET to provide dotnet core support and modernise the library as I found it useful in my work and personal projects. Reason for forking was that the colleagues of the original author (Iulian Margarintescu), who were kind enough to invest their own time attempting to keep the project alive, did not have sufficient “free” time to further it, which is fair enough, no criticisms at all as there are of course many factors which will take one away from working on open source projects. Props to Iulian Margarintescu for his efforts in porting the Java dropwizard metrics project over to .NET.

Because I had been a contributor to Metrics.NET and used the library in many of my of projects I did make a few attempts to move it along and initially implemented an aspnet core wrapper around Metrics.NET, however after some time I decided to fork the project allowing me to move at my own pace, implement and refactor what I needed which became App Metrics.

Why do developers even bother with open source? I mean it’s normally time taken away from family and leisure outside of day jobs.

Well for myself, after being introduced to application metrics, monitoring and various TSDBs, I developed a passion for really getting to know my applications behaviour in a production environment and being alerted when something abnormal occurred, or even, was about to occur. I couldn’t find a library that supported exactly what I wanted, so invested time in App Metrics.

Yes there is ETW and things like EventCounters in corefx which look promising in the space, however samples and documentation are really lacking, there are many lengthy github issues on this topic. In saying that I should probably contribute there by working things out myself and blogging on the topic, however App Metrics, although an opinionated Metrics/Health Check implementation, works well for most of my use cases and is where my open source efforts are spent.

Open source can be a great way to keep up to date with the latest pre-release builds of the framework your building on and explore new features which can be leveraged by your project very early. In a day job, that may be a little more difficult to do, or justify to a business. However staying up-to-date through an open source project allows you to stay ahead of the curve through a practical piece of work, may assist others who review your code, allow you to go back to work to apply and share your learnings with your team as opposed to spending more time learning on the job.

App Metrics is my first attempt in owning an open source project. So far I’ve felt it’s definitely a great feeling getting support and motivative feedback on your project, even if that’s constructive criticism. It’s a great opportunity to build software which you are passionate about for your own use but then share it with others who may also find it useful, at the same time develop your understanding in an area of interest and a way to really stay up-to-date with the technology you’re working with.

Open source I’ve found is not all positive though, it can be a lot of late night commits, an annoyed wife and expectations that you yourself should maintain and implement features that others require. Efforts can also be wasted and not supported, for example the initial version of App Metrics included Health Check functionality in the core library. After coming across an early AspNet Core Health Check implementation from Microsoft I decided to separate Metrics and Health Checks, so that users could choose to use App Metrics for metrics specifically and Microsoft’s Health Check implementation when it was released.

Now seeing Microsoft advertise their equivalent Health Check implementation through documentation and popular code samples such as eShopOnContainers, I’ll probably just drop my implementation and direct users there. It would however be nice to get some type of support, especially before such a similar implementation, and there are also others out in the wild, but ah well.

Open source takes a decent amount of time and effort, well it has for me anyways. What I’ve really enjoyed in maintaining an open source project so far has been:

  • Investigating areas I’d normally not get a chance to in my day job
  • Having a project to apply new framework features and stay up-to-date as opposed reading an article or piece of documentation
  • Having others find the project useful I find rewarding
  • Feedback from users, again even if that’s constructive criticism which is a great way to learn and improve
  • Users willing to contribute, even small contributions which help such as documentation
  • Free for open source! Thanks JetBrains, OzCode, NDepend, AppVeyor, TravisCI, Coveralls

Posted by Allan Hardy

One Comment

  1. Hello Allan, I congratulate you for the initiative you had, in fact, I think most of the examples that Microsoft releases now are oriented to net core 2.0 and the truth, there are projects in production that use net core 1.0 that also deserve these types of monitoring, I do not know why they exclude previous versions.

    I used AppMetrics in one of the projects I have and I found it super intuitive, easy and functional!
    I will continue attentive to your publications.

    Thank you.



Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s