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

Add "otel.status_description" in WithSpan annotation implementation #6710

Open
changliu-wk opened this issue Sep 22, 2022 · 7 comments
Open
Labels
blocked on specification Needs specification work before this can be resolved enhancement New feature or request

Comments

@changliu-wk
Copy link

Is your feature request related to a problem? Please describe.
When using WithSpan annotation, if there is an exception thrown, the annotation has set the "otel.status_code", but it didn't set the "otel.status_description".

This is important, because the enduser would like to know what cause the error.

Describe the solution you'd like
Set "otel.status_description" when otel.status_code is set as ERROR.

Describe alternatives you've considered
I didn't find the specification about how to give status description. But I see .NET has this, and my commercial endpoint also ask this attributes.

Additional context
#6525
I am able to set up a server and a client, and a local collector, saw the detailed span output. Status message : is empty.

@changliu-wk changliu-wk added the enhancement New feature or request label Sep 22, 2022
@laurit
Copy link
Contributor

laurit commented Sep 23, 2022

Could you elaborate what you expect to see as the description.

@changliu-wk
Copy link
Author

When there is an exception within the annotated method, the otel.status_description should be set as the exception's message.

@laurit
Copy link
Contributor

laurit commented Sep 27, 2022

Spec mentions otel.status_description in https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/trace/api.md

Optional Description that provides a descriptive message of the Status. Description MUST only be used with the Error StatusCode value. An empty Description is equivalent with a not present one.

When the status is set to Error by Instrumentation Libraries, the Description SHOULD be documented and predictable. The status code should only be set to Error according to the rules defined within the semantic conventions. For operations not covered by the semantic conventions, Instrumentation Libraries SHOULD publish their own conventions, including possible values of Description and what they mean.

To me it seems that exception message might not be suitable for otel.status_description. If you believe that exception message should be used you'll need to seek clarification in spec.

Considering that exception message is already present in the exception event you may have a hard time convincing others that it should also be added to otel.status_description. If this is something that you really need I'd suggest you look into alternative ways to solve this. You could try building a custom SpanExporter that alters the SpanData and passes it to the real exporter. Or if you are only concerned with @WithSpan you could build your own extension that disables the builtin @WithSpan handling and does what you want.

@changliu-wk
Copy link
Author

changliu-wk commented Sep 27, 2022

When the status is set to Error by Instrumentation Libraries, the Description SHOULD be documented and predictable.

From my perspective, span status is set to Error, but no description is set up. This SHOULD is not accomplished.

@breedx-splk
Copy link
Contributor

@laurit this seems like a reasonable request. Is your main concern that the exception message isn't easily "documented and predictable" or is it more around data duplication, or both?

@laurit
Copy link
Contributor

laurit commented Feb 28, 2023

@breedx-splk As far as I know we never set the description field. If you believe we should, feel free to raise this question at the sig. If we are going to do this we should handle it in the same way everywhere so it won't be tied to just @WithSpan instrumentation. To me using exception message contradicts the language used in spec which requires for the description to be predictable and documented. I interpret it to mean that there should be a fixed list of descriptions. Also as you noted the exception message is already available elsewhere.

@trask
Copy link
Member

trask commented Aug 24, 2023

I think this is blocked on open-telemetry/opentelemetry-specification#3496

@trask trask added the blocked on specification Needs specification work before this can be resolved label Aug 24, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
blocked on specification Needs specification work before this can be resolved enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

4 participants