Move tracing from opentracing to opentelemetry

[squakez]

As Opentracing is marked as deprecated in Camel Quarkus: https://camel.apache.org/camel-quarkus/next/reference/extensions/opentracing.html

[github-actions]

This issue has been automatically marked as stale due to 90 days of inactivity.
It will be closed if no further activity occurs within 15 days.
If you think that’s incorrect or the issue should never stale, please simply write any comment.
Thanks for your contributions!

[gansheer]

Is the subject of this issue only the task of changing the Tracing trait from OpenTracing to OpenTelemetry (and everything related to this change) or are there some other tasks needed ?

@squakez any detail you know on this issue that could be missed would be greatly appreciated 👍

[squakez]

No, I guess it's the only thing to do. Likely we may include more test coverage as a nice to have.

[gansheer]

The backward compatibility of this change is tricky:

• quarkus opentracing :
  • compatible with jaeger by connecting directly to the Collector using Thrift over HTTP (example: https://jaeger-collector:14268/api/traces)
  • allows sampler of types : const/probability/ratelimiting/remote
• quarkus opentelemetry :
  • defaults to gRPC span exporter for OTLP (example : http://localhost:4317)
  • allows samplers of type : on/off/ratio
  • the traces will probably be slightly different

Possible solutions tested :

• having camel-quarkus-opentracing and camel-quarkus-opentelemetry co-exist in tracing trait:
  KO => they can't co-exist at the same time in the build : "The OpenTelemetry extension tracer can not be used in conjunction with either the SmallRye OpenTracing or Jaeger extensions."
• adding the jaeger specific trace exporter provided in quarkiverse:
  KO => it also uses gRPC spec exporter. Jaeger added native support for OTLP (https://medium.com/jaegertracing/introducing-native-support-for-opentelemetry-in-jaeger-eb661be8183c) and even recommends usage of opentelemetry APIs/SDK (🌇 Sunsetting Jaeger clients 🏁 jaegertracing/jaeger#3362), so it is not worth the effort trying to avoid OTLP exporter.

I only see 2 choices left :

1. replacing in tracing trait implementation opentracing by opentelemetry => no backward compatibility
2. adding a new trait (+addon +capability) opentelemetry trait and deprecating the tracing trait

I am in favor of choice 2, adding a new trait, to give users time to do the necessary adaptation (like Jaeger configuration and potential adaptation to the traces generated) before migrating to the new trait.

I will implement the new trait, so if you see something that don't feel right please with this solution don't hesitate to tell me @squakez

[squakez]

Thanks for the detailed proposal. If the option 2 does not present any particular problem, definitely, it would be the preferred solution.