Zipkin Reporter 2.12

Zipkin Reporter 2.12 improves stability of the AsyncReporter during shutdown and with certain sender implementations.

ClosedSenderException was added to signal when a sender is used after having been closed. Previously, sender implementations used an implicit convention of throwing new IllegalStateException("closed"); to signal this, but this makes it more difficult for logic to differentiate against other IllegalStateException that may be thrown by a sender. All sender implementations going forward should throw ClosedSenderException instead.

Zipkin Reporter 2.9

Zipkin Reporter v2.9 adds zipkin-sender-activemq-client, supporting the ActiveMQ 5.x collector available in Zipkin Server v2.15+. This is also configurable with zipkin-reporter-spring-beans.

Thanks very much to @IAMTJW for work on this feature and @thanhct for testing it against AWS MQ.

Zipkin Reporter 2.8.3

Zipkin Reporter v2.8.3 marks the Kafka08 sender has been marked for deprecation.

Zipkin Reporter 0.4

Zipkin Reporter is a library used to export tracing data to Zipkin. After a library like Brave or Wingtips records timing information into spans, it invokes this library to schedule safe delivery out of process to Zipkin. Zipkin Reporter's aim is to make this part of the tracing system more reliable and performant, as well as enable transport benchmarks.

Zipkin Reporter 0.4 is the first feature-complete release, and we believe its api is sound enough for integration testing.

Notably, this includes the AsyncReporter, which collects spans into messages in a background thread. If they get large enough, or a timeout, they are sent to Zipkin across a transport like http, kafka or scribe.

Here's an example for Kafka:

AsyncReporter<Span> reporter = AsyncReporter.builder(KafkaSender.create("host:9092")).build();
reporter.report(span); // will asynchronously flush if a second passes, or a backlog builds up

The system is designed to be transport-relevant: spans are collected into messages that are limited by bytes. Bytes are a far better measure than count of spans, as spans can vary wildly in size. For example, if you use kafka defaults, messages won't be larger than 1MB, whereas scribe defaults to larger 16MiB message max bytes. If you want to limit by span count, you can do that, too.

When using the AsyncReporter, you have the ability to report metrics, such as spans accepted vs dropped. These metrics match the ones on zipkin collector side. This means you can create compatible monitors and alerts on the health of your tracing system.

Finally, the AsyncReporter, and its Sender interfaces are made with portability in mind. Sender has no intimate knowledge of zipkin. It only sends a list of byte arrays. This is a design hint @clehene made in HTrace's zipkin support that we've borrowed here. The result is that you can use AsyncReporter for other types, such as HTrace's span, and when Zipkin upgrades its model, you won't need a new reporting library to address that.

Our next steps are to gather feedback, by integrating with libraries including HTrace, Brave, Jaeger, Wingtips and Finagle. We are also going to start benchmarking real zipkin environments using this library and a tool like jbender.

If you can help with the integration effort, please do. If you are using the library, please let us know how it works, report issues as they arise and hop on https://gitter.im/openzipkin/zipkin

Thanks for your continued interest in Zipkin!