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

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

Closed
1 task done
lmolkova opened this issue Sep 29, 2023 · 5 comments
Closed
1 task done

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

lmolkova opened this issue Sep 29, 2023 · 5 comments
Assignees
Labels
area-networking Includes servers, yarp, json patch, bedrock, websockets, http client factory, and http abstractions

Comments

@lmolkova
Copy link

lmolkova commented Sep 29, 2023

Is there an existing issue for this?

  • 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 (open-telemetry/semantic-conventions#205).

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

e.g. here

tags.Add("exception.type", exception.GetType().FullName);

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

@dotnet-issue-labeler dotnet-issue-labeler bot added the area-networking Includes servers, yarp, json patch, bedrock, websockets, http client factory, and http abstractions label Sep 29, 2023
@noahfalk
Copy link
Member

@JamesNK

@JamesNK
Copy link
Member

JamesNK commented Sep 30, 2023

Lets switch to error.type everywhere.

@JamesNK JamesNK self-assigned this Sep 30, 2023
@JamesNK
Copy link
Member

JamesNK commented Sep 30, 2023

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
Copy link
Author

lmolkova commented Oct 3, 2023

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
Copy link
Member

JamesNK commented Jan 15, 2024

Fixed with #51084

@JamesNK JamesNK closed this as completed Jan 15, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area-networking Includes servers, yarp, json patch, bedrock, websockets, http client factory, and http abstractions
Projects
None yet
Development

No branches or pull requests

3 participants