Skip to content
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

Advancing Metrics in .NET #4083

Open
Tracked by #3762
noahfalk opened this issue Feb 2, 2023 · 3 comments
Open
Tracked by #3762

Advancing Metrics in .NET #4083

noahfalk opened this issue Feb 2, 2023 · 3 comments
Labels
enhancement New feature or request
Milestone

Comments

@noahfalk
Copy link
Member

noahfalk commented Feb 2, 2023

In .NET 6 we added the Meter API, a metrics instrumentation API designed in coordination with OpenTelemetry. The goal was to make it easy to have great metrics monitoring experience for .NET apps using common tools. Although this is now possible to do it isn't yet as easy, widespread, or powerful as we would like. These are my thoughts on next steps. Feedback is welcome if you think the goals should be adjusted, there are issues I've missed, or anything else. Thanks!

Goals

  1. It is easy to set up an ASP.NET Core web app and monitor both platform metrics and custom metrics using (OpenTelemetry or dotnet-monitor) + Grafana. A default Grafana dashboard should be available as a simple starting point.
  2. Using the Meter API in .NET libraries and apps is easy with idiomatic API patterns and documented best practice.
  3. Basic platform level metrics desired by most apps are already instrumented out-of-the-box.

Issues to Address

  1. We have general usage guidance but we need to create usage guidance specific to ASP.NET Core. ASP.NET Core has distinct differences in what code patterns are considered idiomatic. We will may find that it is hard to make the existing API appear idiomatic in ASP.NET Core in which case some judicious use of new APIs may be necessary. (Related: [API Proposal]: Introduce DI friendly IMeter<T> for modern services runtime#77514)
  2. We need to identify any critical missing metrics and add them, for example a request latency histogram.
  3. Existing instrumentation in .NET has been implemented as EventCounters. We need to define the path forward both for new instrumentation and pre-existing instrumentation. (Modify EventCounter usage to support the new metric APIs as well aspnetcore#33387 and Implement/Convert existing EventCounters to Metrics runtime#79371)
  4. We either need to identify an existing Grafana dashboard we can re-use at https://grafana.com/grafana/dashboards, or create a new one. We should also update our tutorial docs to show how to set it up.

cc @samsp-msft @davidfowl @tarekgh @reyang

@ghost
Copy link

ghost commented Feb 2, 2023

Tagging subscribers to this area: @dotnet/area-meta
See info in area-owners.md if you want to be subscribed.

Issue Details

In .NET 6 we added the Meter API, a metrics instrumentation API designed in coordination with OpenTelemetry. The goal was to make it easy to have great metrics monitoring experience for .NET apps using common tools. Although this is now possible to do it isn't yet as easy, widespread, or powerful as we would like. These are my thoughts on next steps. Feedback is welcome if you think the goals should be adjusted, there are issues I've missed, or anything else. Thanks!

Goals

  1. It is easy to set up an ASP.NET Core web app and monitor both platform metrics and custom metrics using (OpenTelemetry or dotnet-monitor) + Grafana. A default Grafana dashboard should be available as a simple starting point.
  2. Using the Meter API in .NET libraries and apps is easy with idiomatic API patterns and documented best practice.
  3. Basic platform level metrics desired by most apps are already instrumented out-of-the-box.

Issues to Address

  1. We have general usage guidance but we need to create usage guidance specific to ASP.NET Core. ASP.NET Core has distinct differences in what code patterns are considered idiomatic. We will may find that it is hard to make the existing API appear idiomatic in ASP.NET Core in which case some judicious use of new APIs may be necessary. (Related: [API Proposal]: Introduce DI friendly IMeter<T> for modern services runtime#77514)
  2. We need to identify any critical missing metrics and add them, for example a request latency histogram.
  3. Existing instrumentation in .NET has been implemented as EventCounters. We need to define the path forward both for new instrumentation and pre-existing instrumentation. (Modify EventCounter usage to support the new metric APIs as well aspnetcore#33387 and Implement/Convert existing EventCounters to Metrics runtime#79371)
  4. We either need to identify an existing Grafana dashboard we can re-use at https://grafana.com/grafana/dashboards, or create a new one. We should also update our tutorial docs to show how to set it up.

cc @samsp-msft @davidfowl @tarekgh @reyang

Author: noahfalk
Assignees: -
Labels:

area-Meta, untriaged

Milestone: -

@xakep139
Copy link

xakep139 commented Jul 4, 2023

Regarding request latency histogram (issue #2): dotnet/aspnetcore#47536
Final naming is in dotnet/aspnetcore#48536

@tommcdon
Copy link
Member

All remaining .NET 8 work is tracked on issues. The remaining item below can be done out of band from the .NET release, so moving to the dotnet/diagnostics repo:

  1. We either need to identify an existing Grafana dashboard we can re-use at https://grafana.com/grafana/dashboards, or create a new one. We should also update our tutorial docs to show how to set it up.

@tommcdon tommcdon transferred this issue from dotnet/runtime Jul 19, 2023
@tommcdon tommcdon added this to the 8.0.0 milestone Jul 19, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants