You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Microsoft are introducing a new set of metrics APIs, which could potentially be used as an alternative abstraction to use our library with (the same way M.E.L.A is to SeriLog), but probably more interestingly, we'd be able to send lots of Microsoft internal metrics (from ASP.NET Core for example) to StatsD to be able to graph on, which would be super cool.
We might have an extension method on MeterListener (InstrumentListener in the design above, I think it's changed) which registers the various SetMeasurementEventCallback<T> callbacks for each supported primitive type.
I'm thinking a light library named JustEat.Diagnostics.Metrics.StatsD.
The text was updated successfully, but these errors were encountered:
Microsoft are introducing a new set of metrics APIs, which could potentially be used as an alternative abstraction to use our library with (the same way M.E.L.A is to SeriLog), but probably more interestingly, we'd be able to send lots of Microsoft internal metrics (from ASP.NET Core for example) to StatsD to be able to graph on, which would be super cool.
I'm not completely sure what is required, here is the listener part of the design we'd probably want to integrate with:
https://github.com/dotnet/designs/blob/main/accepted/2021/System.Diagnostics/Metrics-Design.md#listening-example
We might have an extension method on
MeterListener
(InstrumentListener
in the design above, I think it's changed) which registers the variousSetMeasurementEventCallback<T>
callbacks for each supported primitive type.I'm thinking a light library named
JustEat.Diagnostics.Metrics.StatsD
.The text was updated successfully, but these errors were encountered: