Special handling for exception tracebacks?

[zehauser]

The OpenTracing specification contains some standard fields for logging exceptions, and seems to encourage tracer implementations to extract information from these standard fields:

This scheme allows Tracer implementations to extract what information they need from the actual error object when it's available.

The opentracing Python library helpfully catches exceptions and adds the standard log fields for us.

In particular, the above code makes it clear that the intent of the stack field is to hold the actual traceback object itself.

But when I tie all this together and go look at a sample trace in the Lightstep UI... I get this:

stack: "<traceback object at 0x7fe002d01ac8>"

Which is not very useful to me! I would be better off manually doing something like this:

import traceback
[...]
catch Exception as e:
    span.set_tag('traceback', ''.join(traceback.format_tb(e.__traceback__)))

It seems to me that ideally Lightstep would be doing something here. What do you think?

[carlosalberto]

hey @zehauser

Initially the plan was to include this in OT itself (see opentracing/opentracing-python#123) but it ultimately lead to us including it here. So I will cook a PR for this later today, and hope we can have soon a release with this change ;)

[zehauser]

Hey @carlosalberto thanks for the response! That sounds great.

I have one followup request/suggestion, which is that it would be useful (if possible) to expose this functionality as a public method (or something). For example, I wonder why opentracing.Span._on_error is marked private.

Otherwise, in certain situations where there is an exception that isn't going to bubble up through the Span context manager, we are going to have to reimplement the same logic.

[zehauser]

Hmm, it's just occurred to me that if you decide to implement this functionality in the Lightstep Recorder rather than Span._on_error (i.e., special pre-processing of certain tags before sending to the satellites) than that would work also.

I'm not sure what would be a better design.