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

Propagating Exceptions in Span Events #955

Open
HaloFour opened this issue Sep 15, 2020 · 1 comment
Open

Propagating Exceptions in Span Events #955

HaloFour opened this issue Sep 15, 2020 · 1 comment
Labels
area:error-reporting Related to error reporting spec:trace Related to the specification/trace directory triage:deciding:community-feedback Open to community discussion. If the community can provide sufficient reasoning, it may be accepted

Comments

@HaloFour
Copy link

I'm working with the Java implementation of the reference OpenTelemetry Tracer and using a span exporter that renders spans to logs via log4j2. Currently the Span interface exposes a helper method recordException which can record the details of an exception as an event with attributes to the span. However, as the specification supports a small subset of possible data types for attributes those details and added as String attributes with a raw stack trace and the original exception instance is lost. This prevents me from being able to use the log4j2 configuration to specify how I want the exception and stack trace to be rendered into the log. What I am interested in is some way to propagate an exception into an event on the span so that a span exporter can obtain that original exception instance to interpret/render.

I don't wish a prescribe a solution but I do believe that exceptions are a fairly common concern across most programming languages so it makes sense having a standard way to describe them in the specification.

Here are some possible solutions if this is considered:

  1. Allow for an Event to have an optional Exception/Error property
  2. Allow for an Attribute to be of type Exception
  3. Allow for custom Event implementations to be supported
    1. In the Java SDK Event is an interface and I can provide my own implementation however the reference SDK Tracer implementation wraps my Event and prevents access to any custom members I expost

This conversation might fall into the larger conversation as to what constitutes a successful Span, although being able to track exceptions as discrete events within the lifetime of a span doesn't impact how those exceptions might be interpreted into a single status/success.

@HaloFour HaloFour added the spec:trace Related to the specification/trace directory label Sep 15, 2020
@andrewhsu andrewhsu added the release:after-ga Not required before GA release, and not going to work on before GA label Sep 18, 2020
@arminru arminru added the area:error-reporting Related to error reporting label Sep 22, 2020
@jamescrosswell
Copy link

jamescrosswell commented Aug 3, 2023

We've bumped into similar issues in .NET.

Without access to the original Exception (not just the Type or StackTrace as a string), it's impossible to match the exception up with debug info to provide accurate symbolication and error diagnostics. So we can tell people there was a problem, but we can't help them fix it properly 😢.

I don't know that the exception needs to be propagated across process boundaries (and that might not be desirable for privacy reasons). However when receiving telemetry in the same process where an exception occurs, it would be great if there there was a Activity.GetExceptions() or an Event.GetException() method that could be used to get the original exception.

Alternatively, some kind of OnRecordException callback that OpenTelemetry SDKs could expose, which contained both the Activity and the original Exception.

@MSNev MSNev added this to Logs SIG Sep 20, 2023
@MSNev MSNev moved this to Related in Logs SIG Sep 20, 2023
@mtwo mtwo added triage:deciding:community-feedback Open to community discussion. If the community can provide sufficient reasoning, it may be accepted and removed release:after-ga Not required before GA release, and not going to work on before GA labels Jul 9, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area:error-reporting Related to error reporting spec:trace Related to the specification/trace directory triage:deciding:community-feedback Open to community discussion. If the community can provide sufficient reasoning, it may be accepted
Projects
Status: Related
Development

No branches or pull requests

5 participants