Uploaded image for project: 'Camel'
  1. Camel
  2. CAMEL-12672

Renovate Zipkin (brave) support



    • Improvement
    • Status: Resolved
    • Major
    • Resolution: Abandoned
    • None
    • 3.x
    • camel-zipkin
    • None
    • Unknown


      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.




            Unassigned Unassigned
            adriancole Adrian Cole
            1 Vote for this issue
            4 Start watching this issue