Allow SpanContext to be provided when starting a Span

[nicktrav]

I have a potential use-case where a process will be responsible for accepting incoming span payloads (could be in multiple wire formats) and then shipping them to various locations (initially Stackdriver) via one or more exporters.

Given that the incoming span payloads are fully formed, I'd like to be able to preserve the existing SpanContext when creating a new Span instance. The current implementation in sdk/trace/span.go always generates one for us:

opentelemetry-go/sdk/trace/span.go

Lines 255 to 259 in b80b336

	if parent == core.EmptySpanContext() {
	span.spanContext.TraceID = cfg.IDGenerator.NewTraceID()
	noParent = true
	}
	span.spanContext.SpanID = cfg.IDGenerator.NewSpanID()

I'd like to propose allowing an explicit SpanContext to be set, using something like a StartOption (e.g. something like func WithSpanContext(c SpanContext) StartOption).

[rghetia]

@nicktrav I don't fully understand your use case. Is the goal to extended the same span across two different process? What do you mean by span payloads are fully formed?

[nicktrav]

@rghetia The use case is a process that aggregates telemetry information and exports it to a tracing backend. I say "fully formed" in the sense that all the process has to do is take the span data coming in "as is" and send it on its way. To do this, we need some way of creating Spans with an explicit context, rather than generating new trace / span IDs, as is done here:

opentelemetry-go/sdk/trace/span.go

Lines 255 to 259 in b80b336

	if parent == core.EmptySpanContext() {
	span.spanContext.TraceID = cfg.IDGenerator.NewTraceID()
	noParent = true
	}
	span.spanContext.SpanID = cfg.IDGenerator.NewSpanID()

The specific use-case is Istio's Mixer component (I'm looking into what it would take to use open-telemetry rather than open-census). There's a gRPC service that's exposed that accepts span payloads in the form of protobuf bytes sent from remote Envoy proxy processes. Mixer unpacks, aggregates and filters these span payloads before pushing it into a backend.

You can see how this is happening here:
https://github.com/istio/istio/blob/00fe1c296be31d9ff4ac2eefe3c876b92b109ce3/mixer/pkg/adapter/opencensus/trace.go#L68

[rghetia]

There's a gRPC service that's exposed that accepts span payloads in the form of protobuf bytes sent from remote Envoy proxy processes. Mixer unpacks, aggregates and filters these span payloads before pushing it into a backend.

This sounds similar to otel-collector. It allows to receive spans, processes it and then exports it to one or more backend.

[rghetia]

Closing this as it is not part of the specification.