[
https://issues.apache.org/jira/browse/CAMEL-12672?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16551508#comment-16551508
]
Adrian Cole commented on CAMEL-12672:
-------------------------------------
to answer possibly a different question: why not just use OpenTracing? Well
that can be used, with brave-opentracing, though the experience will be less
efficient and impossible to take advantage of abstractions created by the
zipkin community. For example, the runtime efficiency is worse due to factors
including layers of wrapping and likely a future need to do extra context
tracking unless some bugs are solved in opentracing's api design. Next,
consistency is difficult as [data and sampling policy
tools|https://github.com/openzipkin/brave/tree/master/instrumentation/http]
tools, tools with stable apis, can't be used. OpenTracing data has poor data
quality evidenced by complaints about things like nested json attributes. Even
if you don't believe there are any problems, it would be intentionally not
moving back into supporting what is by far the most popular java tracing
library.
If you choose for whatever reason to keep the zipkin integration as-is, and
continue to not help it move forward, I would recommend removing it entirely.
This way, the openzipkin community can create their own in another repo that is
more friendly towards them. A rotting library is worse than no library,
especially a rotting tracing library.
> Renovate Zipkin (brave) support
> -------------------------------
>
> Key: CAMEL-12672
> URL: https://issues.apache.org/jira/browse/CAMEL-12672
> Project: Camel
> Issue Type: Improvement
> Components: camel-zipkin
> Reporter: Adrian Cole
> Priority: Major
>
> With some hard effort, we've managed to maintain the original form of the
> camel-zipkin integration. However, this integration's design is considerably
> out of date, especially considering the work done in camel-opentracing.
> camel-zipkin should be completely rewritten in order to improve experience
> (and stop volunteers from having support questions in zipkin channel).
>
> I've been told folks don't know what to do, yet I think it is somewhat
> simple. The work that was done in camel-opentracing.. do that in
> camel-zipkin. Beyond that is polishing.
> For example, the brave v4+ api is similar enough to opentracing to mostly
> find/replace. This is a good start and can fix some considerable modeling
> bugs in camel-zipkin around messaging. Once that is complete, we can move to
> being more idiomatic and taking advantage of brave's features.
> For example, `brave.Tracing` is injected by many things in spring. People use
> it to configure advanced propagation things not possible in the normal api.
> Similarly, `brave.http.HttpTracing` sets and verifies http-scoped
> configuration so that when downstream systems are sensitive, data is
> collected in ways not proprietary to camel. One such example is X-Ray.
> Another example is that usually the data in opentracing is a lot bigger and
> so more expensive for sites. Using tools like this helps keep costs down.
> While the above steps are "going beyond" again, a relatively straight-forward
> port of camel-opentracing would be a great way to re-enable the very large
> OpenZipkin community and leverage the work you've done.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
