Is there any plan to replace opentracing with opentelemetry?

[xqbumu]

since opentracing deprecated, also some relate repos are deprecated, and suggest to migrate to opentelemetry.

is there any plan to replace opentracing with opentelemetry?

we can find jaeger exportor from https://github.com/open-telemetry/opentelemetry-go/tree/main/exporters/jaeger.

I personally hope that mortar can be updated trace to opentelemetry.

thank you very much.

[talgendler]

@xqbumu sure why not, just need to understand if it's a breaking change.
If it is a breaking change then it will be worth to revisit all other interfaces and dependencies

[talgendler]

@xqbumu
Currently mortar tracing is using a previous OpenTracing standard interface opentracing.Tracer:

// Tracer is a simple, thin interface for Span creation and SpanContext propagation.
type Tracer interface {
	StartSpan(operationName string, opts ...StartSpanOption) Span

	Inject(sm SpanContext, format interface{}, carrier interface{}) error

	Extract(format interface{}, carrier interface{}) (SpanContext, error)
}

The new OpenTelemetry interface is a bit different --> breaking change.

type Tracer interface {
	// Start creates a span and a context.Context containing the newly-created span.
	//
	// If the context.Context provided in `ctx` contains a Span then the newly-created
	// Span will be a child of that span, otherwise it will be a root span. This behavior
	// can be overridden by providing `WithNewRoot()` as a SpanOption, causing the
	// newly-created Span to be a root span even if `ctx` contains a Span.
	//
	// When creating a Span it is recommended to provide all known span attributes using
	// the `WithAttributes()` SpanOption as samplers will only have access to the
	// attributes provided when a Span is created.
	//
	// Any Span that is created MUST also be ended. This is the responsibility of the user.
	// Implementations of this API may leak memory or other resources if Spans are not ended.
	Start(ctx context.Context, spanName string, opts ...SpanStartOption) (context.Context, Span)
}

There are several choices here I can think of

1. Replace OpenTracing with OpenTelemetry, in this case I would revisit all other interfaces/builders because of a breaking change.
2. Add OpenTelemetry as a new option. While this sounds easy, there will be a need to support both solutions across mortar (server and client interceptors)
3. Implement OpenTracing Interface with the new OpenTelemetry. This should be done outside of mortar with a new "brick", something to replace bjaeger.

[xqbumu]

@talgendler

Each solution has its own advantages, but this change is not particularly necessary at present. If it is me, even if there is a breaking change, in order to reduce the cost of understanding the code for other developers, I think the breaking change is worthwhile. This change can in the next major release.

Or a compatibility layer could be added and the specific tracing logic is placed in the brick, but it looks like OpenTelemetry has these things done already.

So at the moment I think it should be a better choice to introduce OpenTelemetry and then make bjaeger compatible in bricks.

At the same time, OpenTelemetry seems to provide relevant migration guidance, but because my understanding of this component is not deep enough, I actually did not migrate successfully.

And thanks for your reply.

[jarvisMicroservice]

I was able to remove opentracing and integrate jaeger + otel.

would anyone be interested to code review it and possibly include it in mortar OR there is a WIP for OpenTelemetry?

[talgendler]

@jarvisMicroservice I think this is great, if you can please submit a pull request.
Did you add a new interface or removed/changed the current ? If its a breaking change then there is a need for a new version.

[jarvisMicroservice]

I will, soon ( once I have better coverage/ refactor to good standards ) or at-least post snippets for people to use if someone needs it asap.

For my learning, I just

1. Added a new interface
2. Found a way to use existing interceptors ( of-course, small changes like tracer type + context propagation/extraction functions) but not a big deal
3. created a brick for Jaeger to work with otel

what I have done will be breaking change but tbh, it doesn't have to be....We can just mold it to be able to run either OpenTracing or OTEL or even both.

I can give you a working soln if you need this asap else will do this in few weeks (3-4) and submit pull

[talgendler]

@jarvisMicroservice currently I'm working with Open tracing and Jaeger, so I'm not in a rush. I do appreciate your effort so take your time.