[jira] [Commented] (CAMEL-12672) Renovate Zipkin (brave) support

["Adrian Cole (JIRA)" <ji...@apache.org>]

    [ 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)