Resource On SpanData + Specify SpanData format

[SergeyKanzhelev]

Based on open-telemetry/opentelemetry-java#352 discussion.

This also raise the question - if SpanData is immutable, Tracer will need to create a new SpanData with the Tracer's Resource set before passing it to the exporter. Which requires a new allocation. Creating issue: #68

[SergeyKanzhelev]

@songy23 @bogdandrutu I think I addressed your feedback

[songy23]

LGTM

[jmacd]

Hi @SergeyKanzhelev I realize that this is a bit out-of-context, but I also see a bunch of specification about SpanData being included in a PR that's described much more narrowly, as being only about Resources on spans.

This, therefore, feels like an appropriate place to ask questions about the SpanData representation itself, since I'm not sure how much discussion has already passed by.

When I look at the SpanData specified here, I see things being carried over from OC that could potentially be encoded in other already-existing fields of the SpanData. So for example, a Kind value could be encoded as a span attribute using a semantic convention (e.g., "span.kind=client"). A Status value could be encoded as two attributes (e.g., "trace.status.code=PERMISSION_DENIED", "trace.status.message=Expired certificate"). Similarly, a Link value could be encoded as an Event (e.g., "message=CHILD_OF", "trace.span_id=<parent_span>", "trace.trace_id=<trace_id>").

I just wonder if it would be possible to keep the exporters smaller by reducing the number of Span fields.

[SergeyKanzhelev]

@jmacd if you have concerns with specific strongly-typed fields - please create a separate issue. For now this PR mostly describe what was agreed on and implemented in Java API. Next milestone is for receiving feedback (which I appreciate) and addressing it.

[jmacd]

@SergeyKanzhelev Sure, I'll file those issues.

Still, I think we should be careful to title the PR description accurately. Someone who is happy with the Resources definition could be excused for not following this PR, but this PR is specifying what SpanData is. Would you consider updating the PR description to "Specify SpanData format".

I was under the impression that SpanData was an output format for Exporters, not an optional input format (stated here: #68 (comment)). I would like to know more about the reasoning behind this, because it feels like a decision that is incompatible with OpenTracing. I was under the impression that OpenTelemetry would have a pure interface, which means that to construct a SpanData you must use the Span interface. To me, this suggests that SpanData need only be documented for exporters, i.e., not as part of the user-facing instrumentation API.

[SergeyKanzhelev]

@jmacd I'm merging now. We still have an issue to fully flash out SpanData API: #35