Factor out Kafka span collector and high-level API over Brave.

[aShevc]

We may want to consider publishing Brave-related tools (https://github.com/elodina/zipkin-mesos-framework/tree/master/src/main/scala/com/github/kristofa/brave) as a separate artifact that will be re-used by other JVM-based services. Other thing to consider is also moving this to a separate repo.

[codefromthecrypt]

this might be mergable with the kafka collector which is recently in Brave https://github.com/openzipkin/brave/blob/master/brave-spancollector-kafka/src/main/java/com/github/kristofa/brave/kafka/KafkaSpanCollector.java

[aShevc]

Well, KafkaZipkinTracing we have there is more like a high-level interface for Brave. Basically it served two purposes: one is to provide Kafka is a transport. This is the part we can get rid of now when there's a KafkaSpanCollector in Brave. So this is cool. We don't need to merge something into existing collector, we'll use the default one.
But the other purpose is more of an addition to current functionalities of Brave's ClientTracer and ServerTracer. At the moment they basically only collect spans when one sets "client sent" or "server received" annotations for the corresponding Tracer. So the thing is, it is currently impossible to send spans which, for example would have only "server sent" annotations on the server side. And this may be useful if one wants to trace kind of "fire and forget" events. And this is something we need often in our applications, because we often want to trace Kafka messages being sent/received. Anyway, I think these may be someday introduced to the core of Brave library, but requires discussion, so when we have some plans to merge this into Brave, we'll start from where/whether Brave library needs this at all, as our purposes may be too specific.

[codefromthecrypt]

Thanks for the summary. Yeah I noticed also how rpc semantics are baked into brave's apis. There's a new LocalTracer which special cases non-rpc spans, but even that doesn't fit precisely the scenario you've described. I'm likely to help make a raw tracer in brave, similar to the one you have in go (and similar to OpenTracing). That said, there's no rush to move this code around.. It is nice that you've captured a way to accomplish things now. Fwiw zipkin v2 model is likely to be one-way by default, which would help with some of this openzipkin/zipkin#939 Regardless of all ^^ Thanks for sharing your work!