Brave 5 wish list

[codefromthecrypt]

This is a wish list about features that would be nice to have in Brave 5, even if it implies some re-jigging.

Here's a start.

Up till now, spans are assumed to have a strict correlation between noop and sampled state. This removes some overhead of recording when a span is not sampled. The limitation of this is that it removes the ability to accurately derive data from operations being traced, such as latency histograms. We can consider teasing apart these things, similar to how OpenCensus do. By separating out what's recorded from what's sent to Zipkin, we can enable a monitoring, debug and pruning use case not currently possible. cc @felixbarny @SirTyro

[codefromthecrypt]

PS don't get scared, I'm not ready to work on Brave 5, and Brave 4 is a long term release.

[ghost]

When zipkin server is down, retry in a customized time (interval and total), but not just drop spans.

Or better, when zipkin server is down, storing spans locally, and try to connect to the zipkin server according to an interval strategy.

[codefromthecrypt]

Or better, when zipkin server is down, storing spans locally, and try to connect to the zipkin server according to an interval strategy.

good idea! this suggestion is probably better for zipkin-reporter-java repo since such logic exists there.

[remmeier]

native OpenTracing support would be interesting to have as there seem to be a bit of momentum with e.g. the micro-profile and with that potentially the future EE4J spec. Currently brave does two things:

• providing a Zipkin protocol implementation
• providing a rich set of instrumentations for various libraries with Zipkin

Maybe the later could make use of the OpenTracing API. And ZipKin would be pluggable. It could help to largen the potential user base of Brave by working along with all OpenTracing compatible implementations and this way may also bring ZipKin closer to various people as a potential second step.

this would be a step further than what https://github.com/openzipkin-contrib/brave-opentracing currently provides. An alternative solution would be to do the reverse of https://github.com/openzipkin-contrib/brave-opentracing, meaning to forward all calls to the Brave/Zipkin API to the OpenTracing API. This might conceptually be a bit uglier, but would limit the impact on the exiting implementation as instrumentations could continue with the use of the Brave/Zipkin API.

[felixbarny]

🍿

[codefromthecrypt]

native OpenTracing support would be interesting to have as there seem to be a bit of momentum with e.g. the micro-profile and with that potentially the future EE4J spec.

Usually we dont change the core library based on speculative assumptions, nor lock its dependencies to emerging and faulty api choices

[remmeier]

• the core of brave could be independent
• instrumentations based on the core
• zipkin integration into core
• opentracing integration into core

if there an interest in supporting something like opentracing.

[codefromthecrypt]

I got feedback I was too harsh by a friend, and that's true. @remmeier sorry, it is just a loaded topic.

opentracing adds a dimension of compatibility expensive to support and apis that are less sound imho than opencensus (an alternative which already supports zipkin). Your request is valid, but I wouldn't hold my breath as doing a complete change to break the library by making it opentracing isn't likely to be picked up by anyone.

[remmeier]

no need to worry. It was not my intention to suggest to change something like this today or near future. Maybe or maybe not it can be a long term path (with opencensus, opentracing, both, or...) that could accounted for when doing small decisions in the future. Currently very happy with Brave 4. We had some difficulities customizing Brave 3, but everything looks great in Brave 4.

as a general background, we work with many projects and many different customers, having different infrastructures in place. So standards are kind of desirable from our side in thi setting to have something to hold on to. Currently we make use of brave in multiple ways. brave/zipkin as a recommended setup. But also plenty of brave with all its instrumentations, a customized slf4 reporter, log shipping/collection and analysis in something like elastic search.