Brave v3.17

Brave 3.17 includes incremental improvements to Apache Async Client and server interceptors.

• @robinst fixed a problem where the Apache HttpAsyncClient didn't properly close spans (#308)
• Brave also now adds Client Address to grpc and servlet-based instrumentation (#295)

Brave 4 (#180) will have an initial release shortly, which can coexist with Brave 3. In preparation, please note the following:

• We won't remove deprecated methods or constructors in Brave 4, but you should stop using them.
• Directly mutating com.twitter.zipkin.gen.Span has never been supported. Please don't do this.

Brave v3.16

Brave v3.16 includes configuration improvements and Apache CXF support

• @epabst noticed configuring instrumentation was laborious. Now, all instrumentation have a shortcut create method. For example, BraveServletFilter.create(brave)
• @cschneider reduced JAX-RS filter configuration to simply BraveTracingFeature.create(brave)
• With guidance by @reta, @podsiedzik created asynchronous tracing interceptors for Apache CXF 3.x web services.

We hope these improvements help. Look out for more flexibility in adding binary annotations (tags) in the next Brave release.

Brave v3.15

Brave v3.15 supports generating and propagating 128-bit trace IDs

Traditionally, Zipkin trace IDs were 64-bit. Starting with Zipkin 1.14,
128-bit trace identifiers are supported. This can be useful in sites that
have very large traffic volume, persist traces forever, or are re-using
externally generated 128-bit IDs.

If you want Brave to generate 128-bit trace identifiers when starting new
root spans, set Brave.Builder.traceId128Bit(true)

When 128-bit trace ids are propagated, they will be twice as long as
before. For example, the X-B3-TraceId header will hold a 32-character
value like 163ac35c9f6413ad48485a3953bb6124.

Before doing this, ensure your Zipkin setup is up-to-date, and downstream
instrumented services can read the longer 128-bit trace IDs.

Note: this only affects the trace ID, not span IDs. For example, span ids
within a trace are always 64-bit.

Brave v3.11

Brave 3.11 has a few well requested features you should know about:

• @ewhauser added a generic JDBC solution that uses p6spy
• @schlosna added a new state library that allows for nested local spans
• @michaelsembwever extracted a Clock interface that allows you to supply more precise timestamps

Thanks, for the hard work, folks!

Brave v3.10

Fixes Java 6 bytecode regression

@ivansenic noticed that we accidentally went to Java 7 bytecode in 3.9.0. Our apologies: Brave 3.10 fixes that.

Improvements

• @a86c6f7964 noticed threads flushing to zipkin were hard to debug and named them
• @schlosna made numerous clean-ups and saftey improvements to core
• @ewhauser added the remote client address when GRPC servers receive spans.
• @adriancole added LocalSpanThreadBinder, for async local spans

Brave v3.9.0

Moves to Zipkin 1.0.0

Before, brave-core repackaged zipkin model classes and codec into internal packages. Now, it depends on io.zipkin.java:zipkin. This reduces duplication between the projects, while making integrations simpler and packaging less complex.

New features

• #186 : Adds (LocalSpanCollector)[https://github.com/openzipkin/brave/blob/master/brave-spancollector-local/src/main/java/com/github/kristofa/brave/local/LocalSpanCollector.java], which can be used to report spans directly to a zipkin StorageComponent, like Cassandra.
• #186 : Adds (FlushingSpanCollector)[https://github.com/openzipkin/brave/blob/3.8.0/brave-core/src/main/java/com/github/kristofa/brave/FlushingSpanCollector.java], which can be used to control or opt-out of span serialization.

Brave v3.8.0

Brave artifacts are now under io.zipkin.brave group id

In #161, we moved the deployment process to the same as other projects in the OpenZipkin org. This allows more people to help with releases, which should help us release Brave more often.

Here are the key things to bear in mind:

• Brave artifacts are now under io.zipkin.brave group id.
  • So, for example io.zipkin.brave:brave-core:3.8.0, not com.github.kristofa:brave-core:3.8.0
• Releases upload to Bintray under https://jcenter.bintray.com before syncing to Maven Central
• Snapshots upload to http://oss.jfrog.org/artifactory/oss-snapshot-local

New features

• #175 : New OkHttp interceptors that create client spans
• #177 : MySQL interceptor now adds the serviceName "mysql-${database}"

Brave v3.7.0

New features

• #165 : Http request adapters now add "http.url" and "http.status_code" binary annotations.
• #171 : ClientRequestAdapter can now log the server's address
• #168 : SpanId now uses Finagle's binary representation to work in propagation contexts such as Cassandra.

Behavioral changes

• #165 : Renames "http.uri" -> "http.url" and "http.responsecode" -> "http.status_code" to be more consistent with zipkin's TraceKeys.
• #169 : Changes Sampler implementation to be exact, optionally exposing BoundarySampler for high throughput.
• #165 : Logs "http.status_code" even when in the 2xx range.

brave v3.6.0

New features

• fd3cdb9 : gRPC client and server support
• #149 : Span.toString returns value of Span in JSON format
• #151 : ClientTracer.build() becomes public
• #160 : Support configuring Kafka topic name

Breaking changes

• #156 : Use the Endpoint of the local service being traced in ClientTracer, making behaviour similar as ServerTracer.

brave v3.5.0

Bugfixes

• ee79107 : Reverts Kafka client to 0.8.x so it can work with 0.8 and 0.9 brokers. Previously the Kafka integration only worked with Kafka 0.9 brokers. This was not the intention.
• #139 : JAXRS-2 bugfix: Ensure the container request is executed first and the container response is executed last.

Improvements

• #124 : Move HttpSpanCollector to its own module.
• #131 : brave-core source and target compile settings = 1.6.
• #137 : Remove thrift dependency from brave-core and cleans model objects.
• #142 : HttpSpanCollector supports gzipping spans before sending. Configurable but disabled by default as it requires zipkin-scala 1.34+ or zipkin-java 0.6+ at server side.
• #146 : KafkaSpanCollector bundles multiple spans into the same Kafka message. This change resulted in several times higher throughput. As a result of this change you should update to zipkin collector backend 1.35+ if you use Kafka to transport spans. Older versions are not compatible with this change