HTTP OTEL metrics: use `error.type` instead of `exception.type` attribute

[lmolkova]

Is there an existing issue for this?

• [X] I have searched the existing issues

Describe the bug

OTel recently defined error.type attribute as a general-purpose error status. It is used on http.server.* and other metrics (https://github.com/open-telemetry/semantic-conventions/pull/205).

ASP.NET Core now reports exception.type on .NET-specific metrics like (kestrel.*, aspnetcore.*) as well as common HTTP metrics.

e.g. here

https://github.com/dotnet/aspnetcore/blob/36e03b5be98b34804fcf23a2e9c05a5211e1108b/src/Hosting/Hosting/src/Internal/HostingMetrics.cs#L77

Reporting exception.type on common OTel metrics makes .NET incompatible with the OTel spec.

Expected Behavior

ASP.NET Core metrics in http.* namespace should use error.type attribute (populating full exception type on it, in the same was as today). .NET-specific metrics can keep using exception.type or switch to exception.type.

Steps To Reproduce

No response

Exceptions (if any)

No response

.NET Version

8.0

[noahfalk]

@JamesNK

[JamesNK]

Lets switch to error.type everywhere.

[JamesNK]

I noticed that exception.type is still used by logging and tracing in the conventions. Is it intentional that there is a difference between metrics and other telemetry?

https://github.com/search?q=repo%3Aopen-telemetry%2Fsemantic-conventions%20%22exception.type%22&type=code

[lmolkova]

I noticed that exception.type is still used by logging and tracing in the conventions. Is it intentional that there is a difference between metrics and other telemetry?

https://github.com/search?q=repo%3Aopen-telemetry%2Fsemantic-conventions%20%22exception.type%22&type=code

from offline conversation - those are semconv for exceptions on logs/events and not for traces/metrics. The error.type attribute is intended for traces/metrics and all sorts of errors (exceptions or not)

[JamesNK]

Fixed with https://github.com/dotnet/aspnetcore/pull/51084