semantic conventions: add structured stacktrace to exception attributes

[tsloughter]

Fixes #2839

Changes

Add structured stacktrace to exception attributes. The stacktrace is broken up to 4 attributes: exception.structured_stacktrace.function_names, exception.structured_stacktrace.filenames, exception.structured_stacktrace.line_numbers, exception.structured_stacktrace.column_numbers

This may be premature to open but I thought a PR showing the suggested changes and open for comment would help discussion.

There are other fields that may be worth including as well that were in the stacktrace proto of OpenCensus https://github.com/census-instrumentation/opencensus-proto/blob/master/src/opencensus/proto/trace/v1/trace.proto#L348

[tigrannajaryan]

I remember structured vs plaintext was discussed at length when the exception semantic conventions were first introduced. I would advise to try to find the participants of that past discussion and ask their opinion. The discussion should have left some trail in the PRs, spec SIG meeting notes, Slack, etc.

[tigrannajaryan]

In the past few months I think we have seen multiple use cases where we want attributes with map values. I would argue that if such value are widely needed then we need to lift the restriction and allow map values. Vendors who don't support map values can flatten the data in their exporters.

[tsloughter]

Agreed. I've wanted to also find the discussion/notes around why this was left out. Was it simply that some vendors don't support it?

[tigrannajaryan]

Here is the issue: #376

[tsloughter]

Ah, that issue. Thanks, I saw you include this PR in the comments already.

[jmacd]

I support map-valued attributes (and specifying how to flatten them). I see how we could use semantic conventions for conveying source location in stacktraces, but this seems to me a very expensive option. Looking at other fields the OpenCensus stacktrace message contained, I find this mechanism to avoid repetitive stacktraces:

  // The hash ID is used to conserve network bandwidth for duplicate
  // stack traces within a single trace.
  //
  // Often multiple spans will have identical stack traces.
  // The first occurrence of a stack trace should contain both
  // `stack_frames` and a value in `stack_trace_hash_id`.
  //
  // Subsequent spans within the same request can refer
  // to that stack trace by setting only `stack_trace_hash_id`.
  //
  // TODO: describe how to deal with the case where stack_trace_hash_id is
  // zero because it was not set.
  uint64 stack_trace_hash_id = 2;

And this is where most of my concerns here lie -- a structured stack is a more-expensive way to encode stacktraces than the simple string, unless you have a way to avoid repetition.

[tsloughter]

Right. We could do similar to the OpenCensus method of not repeating parts of stacktraces through the use of a hash id. But it is also still an optional field that doesn't need to be filled in for those languages that the vendors can parse. Instead of asking vendors to parse languages outside a certain subset we only ask that they fallback on a single structure all the unsupported languages will use.

It is a bit of a pain to say which languages need to be sending the structured version, so some may want to make it a user defined option, except for major players like Java, .net and Go who can pretty much guarantee support.

[github-actions]

This PR was marked stale due to lack of activity. It will be closed in 7 days.

[github-actions]

Closed as inactive. Feel free to reopen if this PR is still being worked on.