Future of this project

[djluck]

I haven't put much work into this project over the past few months due to work commitments but there's a few ideas I have for improvements:

• Improved sampling (aka toggling noisy event sources on/ off to avoid perf overhead of continuously collecting these events)
• Extracting the core "event timing" logic into a separate library to enable other metric libraries to expose these metrics
• Expanded set of metrics collected by looking at other event sources (e.g. Sql commands, ASP.NET core, GRPC, etc.)

@sywhang I'd be interested in learning a bit about the roadmap for telemetry in .NET core if you could spare the time- I'm particularly interested in any future improvements around event collection + filtering and event counters.

[sywhang]

@djluck I was perusing through this repo and saw this issue had me mentioned, but somehow I didn't get a notification for it...? Anyways sorry for responding to this super late. On a positive side, I'm just getting around starting to work on the metrics story for .NET 6 so this may be a perfect timing for any improvements we can make over in .NET side : )

There are few improvements we're planning on making for .NET 6.

• Improve performance and scalability of EventPipe: Improve Eventing Fundamentals dotnet/runtime#45518

I talked about this in a different issue, but there is currently a scalability issue with EventPipe that impacts the performance of EventListener. This is under active work.

• Improve in-proc consumption of runtime metrics: Improve in-proc consumption story of runtime metrics dotnet/runtime#45590

This is still under design phase - I'm starting to gather ideas from different people both in/out of Microsoft trying to understand how people are consuming metrics in-proc. The goal is to simplify consumption of metrics published by the runtime/framework libraries using EventCounter. Many of the .NET stack now publish these counters (i.e. System.Net.Http, ASP.NET Core, gRPC).

• On top of these, we also are planning on adding Metrics API that will integrate with OpenTelemetry metrics spec.

As far as I understand, this library doesn't use the metrics exposed via EventCounters, probably because it doesn't give you the level of depth you're interested in consuming. That's fair, and I think it really just comes down to the perf cost of enabling them.

In addition to that, many of the frameworks you mentioned (Sql commands, ASP.NET Core, gRPC) now publish EventCounters starting from .NET 5.0 so this may be something you might be interested in consuming in the future.

Let me know if you have any questions and I'd be happy to discuss further : )

[djluck]

Hey @sywhang, thanks for taking the time to provide this writeup- it's really useful 👍

[leonids2005]

HI, are there any updates about this project?

Thank you.