-
Notifications
You must be signed in to change notification settings - Fork 754
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
Record Exception.Data
when calling RecordException
#2439
Comments
The RecordException will be following the spec here : https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/trace/semantic_conventions/exceptions.md (its currently experimental, and will be subject to breaking changes). We can revisit this once the spec gets to stable. |
I think this should be reopened. Data attributes are required to be supported by RecordException according to the spec. Here is the specification for RecordException: https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/trace/api.md#record-exception (it is directly linked from the spec in https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/trace/semantic_conventions/exceptions.md) It says:
Given that it is a |
@pbiggar Thanks for raising this. I've opened a separate issue #3369. This issue is slightly different in that it is proposing a change in behavior to the existing |
Exception.Data not recorded, so keeping this open |
It would be useful if the entire exception object was available somewhere, so that it could be retrieved in a processor. Reducing an exception to its type, message, and stacktrace string makes it impossible to recreate the exception or get at values from other properties. For example Additionally, the stack trace string captured in |
LogRecord do provide access to Exception (https://github.com/open-telemetry/opentelemetry-dotnet/blob/main/src/OpenTelemetry/Logs/LogRecord.cs#L262), but Traces do not. There is an open issue about supporing this in runtime repo, will find it and link from here. |
@cijothomas I'd be interested in that issue, if you're still able to track it down. I'm wondering if I could maybe make a PR with @mattjohnsonpint's suggestion above. |
Thanks @cijothomas. Do you think there's any possibility of working around this in the OpenTelemetry API until that issue in the dotnet runtime gets resolved? That issue has been open for a couple of years now. There are a couple of potential workarounds that I could think of, but I'm not sure how these sit with the general design philosophy of the OpenTelemetry APIs:
Do any of those sound feasible? |
@jamescrosswell The (As a workaround, could you see if you can use ILogger to report exceptions, assuming you control the code which currently calls RecordException?. The LogRecord keeps Exception instance directly, allowing more flexibility at the processor/exporter level. |
Unfortunately not @cijothomas. I'm working on the Sentry OpenTelemetry Tracing integration. Sentry SDK users could be using all kinds of different solutions for logging. This issue goes beyond the OpenTelemetry .NET API though right? Even if the Exception was available on the What would have to happen for the OpenTelemetry specification to change? |
Need to open an issue in the opentelemetry-specification repo describing the issue and the suggested improvement. |
Thanks @cijothomas 👍🏻 |
I found an existing issue in the opentelemetry-specification repo. It looks like for Java, something like this was implemented already? |
Feature Request
Has there been an consideration of recording values from an exception's
Data
property as tags on the event when callingactivity?.RecordException(ex)
?Describe the solution you'd like:
I would like to add key/value data to certain exceptions beyond just a message. It would be useful to record this extra data when the exceptions are caught.
Describe alternatives you've considered.
The extra data can obviously be recorded manually, but it seems natural to include this functionality in the
RecordException
method.The text was updated successfully, but these errors were encountered: