Add Zipkin Thrift as kafka ingestion format

[geobeau]

Which problem is this PR solving?

• Ingesting Zipkin thrift span from Kafka: This is useful for a seamless migration from Zipkin. It is mentioned in Migrating from Zipkin Kafka stream #171

Short description of the changes

• Add an unmarshaller to process spans in zipkin thrift using what was used for collector zipkin API

[yurishkuro]

Thanks to contributing! This will be the last missing piece for Zipkin compat.

I left a few stylistic comments. The build appears to be failing on go fmt

Go fmt, license check, or import ordering failures, run 'make fmt'
./plugin/storage/kafka/options.go
./plugin/storage/kafka/unmarshaller.go

Last piece is to add unit test for the marshaling.

[codecov]

Codecov Report

Merging #1256 into master will not change coverage.
The diff coverage is 100%.

@@          Coverage Diff           @@
##           master   #1256   +/-   ##
======================================
  Coverage     100%    100%           
======================================
  Files         159     160    +1     
  Lines        7163    7181   +18     
======================================
+ Hits         7163    7181   +18

Impacted Files	Coverage Δ
plugin/storage/kafka/unmarshaller.go	100% <100%> (ø)	⬆️
model/converter/thrift/zipkin/deserialize.go	100% <100%> (ø)
plugin/storage/kafka/factory.go	100% <100%> (ø)	⬆️
cmd/ingester/app/flags.go	100% <100%> (ø)	⬆️
plugin/storage/kafka/options.go	100% <100%> (ø)	⬆️
cmd/collector/app/zipkin/http_handler.go	100% <100%> (ø)	⬆️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 8f809ed...9038399. Read the comment docs.

[geobeau]

@yurishkuro I am not sure it's some good code, any advices to avoid using [0]. I thought about changing the interface to return []model.Span and handle the array in the calling function.

[yurishkuro]

I think the ingester is currently built with the assumption that a single Kafka message contains just a single span. Even in this case a single Zipkin span can sometimes be transformed to two Jaeger spans, so it would be better to extend the ingester to support the notion of many spans per message, at least after unmarshaling. However, I would not recommend doing it in this PR, it should be a separate PR as it might get quite large. For now I would suggest logging a warning.

There are good reasons to expect a single span per Kafka message, it makes the streaming jobs easier to write.

[geobeau]

Thanks

[geobeau]

Formating done, now going for tests

[geobeau]

Should be good now, @yurishkuro

[yurishkuro]

Looks great! Thanks for contributing 🎉

Have you been able to test this with real Zipkin clients writing to Kafka?

[geobeau]

Yes, I tested it mostly that way. It has not run for a long continuous time thought. And I am not sure we are using a clean version of Zipkin. I should probably build a small PoC using docker images to test better

[yurishkuro]

I don't mind merging this as is, but it would be nice to add an integration test for Travis. We can probably extend https://github.com/jaegertracing/xdock-zipkin-brave to support configuration to use Kafka as the span reporting transport.