Support externally-provided trace/span IDs

[xbsura]

Problem

I need to use jaeger-client-go daeling with some existed trace Log and uload them to jager agent

As exiting Log has had traceId, spanId and so on, so I need to NewTrace and NewSpan all by myself, in Python, I can create a span with a existed spanContex, but in Go, I can not find such method

jaeger-client-go has a NewSpanContext method, but not method named: Span.SetContext() Or NewSpan()

So could you please add a method: Span.SetContext or Newspan(SpanContext, Tracer, operationName, tags, startTime, references)?

thanks

[dm03514]

@yurishkuro Would love your feedback:

dm03514@efd30c9

POC just to get design talk going.

I appreciate your time.

---

So far this pulls out the references building and parent detection into filterReferences

It exposes another span constructor (StartSpanFromContext ) on the tracer.

[yurishkuro]

@dm03514 this looks like its copying a bunch of code that already exists in this repo

I think a better approach is to introduce a new non-standard type of span reference SELF (discussed here opentracing/specification#81). If such reference is passed to the through the child and ID generation logic.

[dm03514]

@yurishkuro another POC, would love your feedback.

dm03514@bf5f342

Thank you

[yurishkuro]

looks reasonable. It's hard to review, could you create a WIP PR?

[dm03514]

👋 @yurishkuro

Just to update this is working perfectly for my use case! Thank you again. My use case is long lived (hours, days, weeks) of low traffic (100's to 1000's / day) spans. Because of how long they live I needed to shuffle them out of memory. Right now I am exporting the operation name, SpanContext ID as string, tags and start time:

...
		s, err := json.Marshal(SerializableJaegerSpan{
			OperationName: span.OperationName(),
			ID:            span.String(),
			Tags:          span.Tags(),
			StartTime:     span.StartTime(),
		})
...
		ss.SpanContext = s
		ss.Backend = Jaeger
...

Then when a span needs to be finished/updated it is loaded back and the context is rebuilt:

func (s SerializableJaegerSpan) Context() (jaeger.SpanContext, error) {
	return jaeger.ContextFromString(s.ID)
}
...

js := SerializableJaegerSpan{}
...
ctx, err := js.Context()
...
span := tracer.StartSpan(
			js.OperationName,
			jaeger.SelfRef(ctx),
			opentracing.StartTime(js.StartTime),
		)
		for k, v := range js.Tags {
			span.SetTag(k, v)
		}

Is there anything I could do to help with opentracing/specification#81 ? Is it possible to revisit it? I personally could benefit from SELF being part of the spec (for lightstep & dd-trace). I read that adriancole said the issue predates the current process, so i'm not sure what step to take next. Thanks again: Danny

[yurishkuro]

Have you tried actually finishing the span more than once? Jaeger should be able to handle that and merge multiple span records into one (not sure what it would do with timestamps). This way you wouldn't need to save the tags, and in fact you might be able to operate purely in the OpenTracing API (where things like span.Tags() are not accessible).

Regarding the process in OpenTracing, I think there needs to be an RFC proposed. But so far you only solved your use case by accessing a lot of Jaeger-specific methods, so simply adding SELF to OpenTracing wouldn't solve the issue without requiring the additional merging behavior.

[dm03514]

I will experiment with the multiple finishes.

I noticed that issue with Tags() when looking at other Go tracing libraries. I'm using jaeger as backend so it isn't super huge for me right now, but would def be awesome to have a solution that was fully opentracing compliant. I see what you're saying: there's really no generic SELF benefit for this use case since the serialize/deserialize method requires jaeger specific calls.

[yurishkuro]

Resolved by #411.