Skip to content

Brave 5.9
Compare
Choose a tag to compare
@codefromthecrypt codefromthecrypt released this 01 Nov 01:06
· 412 commits to master since this release
5.9.0
8847c64

Brave 5.9 notably begins a messaging abstraction. It also allows customizing of which B3 format is used based on Span kinds (CLIENT, SERVER, etc.). If you enjoy this work, please star our repo or join gitter to thank folks!

New Messaging abstraction

In Brave's main repository, we have three messaging instrumentation libraries: Kafka, JMS, and RabbitMQ. We've started a messaging abstraction with sampling.

Ex. Here's a sampler that traces 100 consumer requests per second, except for the "alerts" channel. Other requests will use a global rate provided by the Tracing component.

import brave.sampler.Matchers;

import static brave.messaging.MessagingRequestMatchers.channelNameEquals;

messagingTracingBuilder.consumerSampler(MessagingRuleSampler.newBuilder()
  .putRule(channelNameEquals("alerts"), Sampler.NEVER_SAMPLE)
  .putRule(Matchers.alwaysMatch(), RateLimitingSampler.create(100))
  .build());

This code is 100% portable across traced libraries. In other words, JMS tracing uses exactly the same MessagingTracing component as Spring Rabbit: Rules can be mixed in the same way as they can with our HttpTracing component. We hope this can help you prune traces to the most impactful!

Thanks very much to @anuraaga and @jeqo for design and code review.

Propagation customization

It is already the case that folks can make custom propagation components to address different header formats, such as Amazon's. One repeated concern was to control which of the B3 formats should be used when sending headers down. For example, in a transition, you may want to send both our single and multi-header formats. However, new sites may choose to only send the single format as it is cheaper.

In a pragmatic move, we've retro-fitted the default B3Propagation implementation to consider the kind of span when choosing formats to write. This inherits the default formats used prior: "x-b3-" prefixed for client/server spans and the single "b3" format for producer/consumer spans.

To override this policy, you can use a builder like below. The following makes RPC and HTTP instrumentation write "b3" single format such as messaging spans do.

tracingBuilder.propagationFactory(B3Propagation.newFactoryBuilder()
      .injectFormat(Format.SINGLE) // things that don't extend `brave.Request`
      .injectFormat(Span.Kind.CLIENT, Format.SINGLE)
      .injectFormat(Span.Kind.SERVER, Format.SINGLE)
      .build())

Regardless of this policy, both "b3" and "x-b3-" headers are read, as if we changed that, it would break existing sites! Tolerant reads are best for compatibility and interop!

Note: Our HTTP, RPC, and Messaging abstractions employ these by default by extending brave.Request. If you are not using our abstractions, please consider updating to also use brave.Request for remote instrumentation so that users can easily tune header formats!

Minor changes

  • OSGi manifests are now present in all jars
  • @jeqo fixed where Kafka and JMS callbacks couldn't read no-op trace contexts
  • @simondean allowed kafka-streams to inherit policy from kafka-clients instrumentation
  • @rmichela fixed where SQS used with JMS could raise exceptions where it shouldn't
Assets 2
Loading