[Instrumentation.AspNet] Update semantic conventions for metrics

[qhris]

Updates metrics to match semantic conventions for 1.23.

This was previously discussed in #1407.

Changes

Replaces http.server.duration with the new http.request.server.duration metric and adds missing attributes.

For significant contributions please make sure you have completed the following items:

• Appropriate CHANGELOG.md updated for non-trivial changes

Remaining issues

• Unable to get Application_Error to fire in my sample application in order to verify error.type for exceptions. It works fine for status codes. Excluded for now.
• Unable to write a test for network.protocol.version which uses request.ServerVariables["SERVER_PROTOCOL"] because that property/class is heavily locked down. I have verified this to work on a sample application.
• The HttpRequestRouteHelper works fine for fetching the route template but it is marginally useful because the route easily ends up like /{controller}/{action} which doesn't say much.

[codecov]

Codecov Report

Merging #1429 (3dd0fae) into main (71655ce) will increase coverage by 0.16%.
Report is 93 commits behind head on main.
The diff coverage is 54.44%.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #1429      +/-   ##
==========================================
+ Coverage   73.91%   74.07%   +0.16%     
==========================================
  Files         267      264       -3     
  Lines        9615     9794     +179     
==========================================
+ Hits         7107     7255     +148     
- Misses       2508     2539      +31     

Flag	Coverage Δ
unittests-Exporter.Geneva	57.92% <32.14%> (?)
unittests-Exporter.OneCollector	89.72% <100.00%> (?)
unittests-Extensions	82.75% <100.00%> (?)
unittests-Instrumentation.AspNet	75.96% <ø> (?)
unittests-Instrumentation.EventCounters	75.92% <ø> (?)
unittests-Instrumentation.Owin	85.71% <ø> (?)
unittests-Instrumentation.Process	100.00% <ø> (?)
unittests-Instrumentation.Runtime	100.00% <ø> (?)
unittests-Instrumentation.StackExchangeRedis	71.00% <ø> (?)
unittests-Instrumentation.Wcf	78.47% <ø> (?)
unittests-PersistentStorage	58.80% <ø> (?)
unittests-ResourceDetectors.Azure	80.90% <ø> (?)
unittests-ResourceDetectors.ProcessRuntime	76.08% <ø> (?)
unittests-Solution	81.83% <90.62%> (?)

Flags with carried forward coverage won't be shown. Click here to find out more.

Files	Coverage Δ
....Exporter.Geneva/GenevaExporterHelperExtensions.cs	100.00% <ø> (+31.81%)	⬆️
...Telemetry.Exporter.Geneva/GenevaExporterOptions.cs	90.00% <ø> (ø)
...OpenTelemetry.Exporter.Geneva/GenevaLogExporter.cs	85.00% <ø> (+7.50%)	⬆️
...lemetry.Exporter.Geneva/GenevaLoggingExtensions.cs	100.00% <ø> (+14.28%)	⬆️
...enTelemetry.Exporter.Geneva/GenevaTraceExporter.cs	82.50% <ø> (+7.50%)	⬆️
...xporter.Geneva/Internal/ConnectionStringBuilder.cs	92.94% <100.00%> (ø)
...ry.Exporter.Geneva/Internal/ExporterEventSource.cs	14.28% <ø> (+9.52%)	⬆️
...eneva/Internal/ReentrantActivityExportProcessor.cs	100.00% <ø> (ø)
...porter.Geneva/Internal/ReentrantExportProcessor.cs	100.00% <ø> (ø)
...ry.Exporter.Geneva/Internal/TableNameSerializer.cs	98.93% <ø> (ø)
... and 104 more

... and 165 files with indirect coverage changes

[qhris]

Hey,

I'm leaving this up as a draft until I can finish up the remaining tasks and run some more tests.
I could however use some input from @Kielek and @vishweshbankwar for the direction of this PR and the remaining tasks?

[vishweshbankwar]

Hey,

I'm leaving this up as a draft until I can finish up the remaining tasks and run some more tests. I could however use some input from @Kielek and @vishweshbankwar for the direction of this PR and the remaining tasks?

@qhris

1. Let's handle error.type outside of this PR. It would be tricky to get that value on metrics side. Take a look at [ASP.NET Core] Add error.type attribute for tracing and metrics opentelemetry-dotnet#4986 if you can do something similar here.
2. I see the test creates HttpContext.Current. Is it possible to do HttpContext.Current.Request.ServerVariables.Add and validate that you get the network.protocol.version?
3. For http.route, this is a known issue. Please open a separate issue for this if there isn't one out there already. For now, you can copy how tracing is doing it.

[qhris]

@vishweshbankwar thanks for the input!

1. Thanks for the link, I can look into this a bit more. Are you suggesting to remove it entirely for this PR if not?
2. A tried a variety of things to get it working.
   • ServerVariables.Add() throw with System.NotSupportedException.
   • ServerVariables only has a getter so I can't assign to it.
   • I also tried setting the backing field _serverVariables through reflection but ended up running into an issue since the type HttpServerVarsCollection is internal to System.Web. I could try to instantiate that type through reflection as well but I didn't feel comfortable with that as it would get very messy. Might be the only way to go though.
   • I tried making HttpRequest a mock but that throws: System.NotSupportedException : Type to mock (HttpRequest) must be an interface, a delegate, or a non-sealed, non-static class.
   • It seems using HttpContextBase is the recommended way to make the code more testable but that would require making quite a bigger change to the codebase (i.e. rewriting HttpTelemetryModule, ActivityHelper, et al.).
3. Sounds good 👍

[vishweshbankwar]

@vishweshbankwar thanks for the input!

1. Thanks for the link, I can look into this a bit more. Are you suggesting to remove it entirely for this PR if not?

2. A tried a variety of things to get it working.

   • ServerVariables.Add() throw with System.NotSupportedException.
   • ServerVariables only has a getter so I can't assign to it.
   • I also tried setting the backing field _serverVariables through reflection but ended up running into an issue since the type HttpServerVarsCollection is internal to System.Web. I could try to instantiate that type through reflection as well but I didn't feel comfortable with that as it would get very messy. Might be the only way to go though.
   • I tried making HttpRequest a mock but that throws: System.NotSupportedException : Type to mock (HttpRequest) must be an interface, a delegate, or a non-sealed, non-static class.
   • It seems using HttpContextBase is the recommended way to make the code more testable but that would require making quite a bigger change to the codebase (i.e. rewriting HttpTelemetryModule, ActivityHelper, et al.).

3. Sounds good 👍

Yes - A separate PR for error.type.

For network.protocol.version, You could remove this one too for now in favor of making progress. I will try to take a look at it when I get chance.

[qhris]

Hey, I made some additional findings here.

The reason why I wasn't able to get Application_Error to fire was because I was testing a ASP Web API application. This type of app has a completely different error flow as desribed in this Microsoft documentation.

This means that traces do not behave as expected either, since the error status of the span will never be set here.

For now, I went ahead and removed the error.type as suggested.

Would it be a blocker to leave in the protocol version as is? It is a very useful metric and it would be a shame to leave it out.

Edit: It would appear this line makes the error span be set correctly even though the exception path is never fired.

[vishweshbankwar]

Would it be a blocker to leave in the protocol version as is

No, I think it is ok.

[Kielek]

@qhris, I think that. semantic convention also for spans/traces has to be adjusted. It can be done in separate PR, but it should be done before the release to make the transition from unstable to stable world only once.

[carlos-neto-maersk]

Can you guys please check #1431 ?

It is related to this, because due to the changes done to telemetry module to have the activity stopped on this OnActivityStoppedCallback, under load we are experiencing that weird pattern (and I think that it is because it because it is closing activities that aren't to be closed in other OnActivityStoppedCallback handlers).

I'm working on not closing the activity after the handlers, and using the current timestamp to figure it out the duration instead of using Activity.Duration, but the code isn't great.

And thank you so much for your great work.

[github-actions]

This PR was marked stale due to lack of activity. It will be closed in 7 days.

[Kielek]

@cijothomas, can we merge it with current wording?

[cijothomas]

@cijothomas, can we merge it with current wording?

Since we know the exact version of the SDK which is required to get correct histogram buckets, I'd suggest to call it out in the changelog.
https://github.com/open-telemetry/opentelemetry-dotnet/blob/main/src/OpenTelemetry/CHANGELOG.md#170-rc1

[qhris]

Fixed all the remaining issues but the tests won't pass until the SDK is updated.

[utpilla]

@qhris Thanks for your patience!