Feature Request
Currently the OpenTelemetry SDK sets default histogram boundaries to { 0, 5, 10, 25, 50, 75,
100, 250, 500, 750, 1000, 2500, 5000, 7500, 10000}. These values make sense for time durations of network
requests measured in ms, however OTel semantic conventions encourage using seconds. This means that most histograms will be timing things that take less than 5 seconds and the default buckets are not at all useful. I am in particular concerned with histograms that were added in .NET 8 to ASP.NET Core and System.Net because I expect it will be extremely common for users to want to monitor those histograms. The current workaround is to specify a custom view with alternate buckets for every histogram. This approach functions, but adds complexity to what should be a very simple and common use case. You can see how the getting started guide for ASP.NET Core metrics has to include a custom view right now: https://learn.microsoft.com/en-us/aspnet/core/log-mon/metrics/metrics?view=aspnetcore-8.0#create-the-starter-app
There are several tasks that could help improve the situation on different timescales:
- Hardcode the names of well-known instruments and provide more appropriate defaults for those
- Change the global histogram defaults for OpenTelemetry.NET
- Change the global histogram defaults in the specification for all OpenTelemetry clients
- Advance the metrics hint APIs towards stability and work with the .NET libraries team in .NET 9 to implement those APIs so that instrumentation authors can provide their own defaults.
The .NET team is glad to work with you on that last bullet in the .NET 9 timeframe, but we are hoping one of the other options can be adopted as well to offer a solution more quickly.
cc @JamesNK
Feature Request
Currently the OpenTelemetry SDK sets default histogram boundaries to { 0, 5, 10, 25, 50, 75,
100, 250, 500, 750, 1000, 2500, 5000, 7500, 10000}. These values make sense for time durations of network
requests measured in ms, however OTel semantic conventions encourage using seconds. This means that most histograms will be timing things that take less than 5 seconds and the default buckets are not at all useful. I am in particular concerned with histograms that were added in .NET 8 to ASP.NET Core and System.Net because I expect it will be extremely common for users to want to monitor those histograms. The current workaround is to specify a custom view with alternate buckets for every histogram. This approach functions, but adds complexity to what should be a very simple and common use case. You can see how the getting started guide for ASP.NET Core metrics has to include a custom view right now: https://learn.microsoft.com/en-us/aspnet/core/log-mon/metrics/metrics?view=aspnetcore-8.0#create-the-starter-app
There are several tasks that could help improve the situation on different timescales:
The .NET team is glad to work with you on that last bullet in the .NET 9 timeframe, but we are hoping one of the other options can be adopted as well to offer a solution more quickly.
cc @JamesNK