Package zipkin2.finagle

Class ZipkinTracer

  • All Implemented Interfaces:
    com.twitter.finagle.tracing.Tracer, com.twitter.util.Closable
    public class ZipkinTracer
extends com.twitter.finagle.zipkin.core.SamplingTracer
implements com.twitter.util.Closable
    Receives the Finagle generated traces and sends them off to Zipkin.

    Implement this by extending and registering in the service loader. For example: 

     @AutoService(com.twitter.finagle.tracing.Tracer.class)
 public final class HttpZipkinTracer extends ZipkinTracer {

  --snip--

   // Default constructor for the service loader
   public HttpZipkinTracer() {
     this(Config.builder().build(),
          DefaultStatsReceiver$.MODULE$.get().scope("zipkin.http")
     );
   }

   HttpZipkinTracer(Config config, StatsReceiver stats) {
     super(new HttpReporter(config.host()), stats, config.initialSampleRate());
   }
 }

    If you don't need to use service loader, an alternate way to manually configure the tracer is via newBuilder(Reporter)

    • Constructor Summary

      Constructors 
      Modifier Constructor Description
      protected ZipkinTracer​(zipkin2.reporter.Sender sender, ZipkinTracer.Config config, com.twitter.finagle.stats.StatsReceiver stats)  

    • Method Summary

      All Methods Static Methods Instance Methods Concrete Methods 
      Modifier and Type Method Description
      com.twitter.util.Future<scala.runtime.BoxedUnit> close()  
      com.twitter.util.Future<scala.runtime.BoxedUnit> close​(com.twitter.util.Duration after)  
      com.twitter.util.Future<scala.runtime.BoxedUnit> close​(com.twitter.util.Time deadline)
      There are two queues here.
      static ZipkinTracer.Builder newBuilder​(zipkin2.reporter.Reporter<zipkin2.Span> spanReporter)
      Normally, Finagle configures the tracer implicitly and through flags.

      • Methods inherited from class com.twitter.finagle.zipkin.core.SamplingTracer

        getSampleRate, isActivelyTracing, isNull, record, sampleTrace, setSampleRate

    • Constructor Detail

      • ZipkinTracer

        protected ZipkinTracer​(zipkin2.reporter.Sender sender,
                       ZipkinTracer.Config config,
                       com.twitter.finagle.stats.StatsReceiver stats)

    • Method Detail

      • newBuilder

        public static ZipkinTracer.Builder newBuilder​(zipkin2.reporter.Reporter<zipkin2.Span> spanReporter)
        Normally, Finagle configures the tracer implicitly and through flags. This implies constraints needed for service loading. Alternatively, you can use this type to explicitly configure any sender available in Zipkin.

        Ex. 

        
 // Setup a sender without using Finagle flags like so:
 Properties overrides = new Properties();
 overrides.put(ProducerConfig.MAX_BLOCK_MS_CONFIG, 5000);
 sender = KafkaSender.newBuilder()
   .bootstrapServers("host1:9092,host2:9092")
   .overrides(overrides)
   .encoding(Encoding.PROTO3)
   .build();

 zipkinStats = stats.scope("zipkin");
 spanReporter = AsyncReporter.builder(sender)
   .metrics(new ReporterMetricsAdapter(zipkinStats)) // routes reporter metrics to finagle stats
   .build()

 // Now, use it here, but don't forget to close the sender!
 tracer = ZipkinTracer.newBuilder(spanReporter).stats(zipkinStats).build();

        On closing resources

        The resulting tracer will attempt to close an underlying reporter if it implements Closeable. It is best to use normal tools like pre-destroy hooks to close resources in your application. If you somehow cannot control your resources, yet can invoke this, consider wrapping the input as a closeable to coordinate an ordered shutdown.

        Ex. 

        {@code
 class ReporterThatClosesSender implements Reporter, Closeable {
   final Sender sender;
   final AsyncReporter reporter;

      • close

        public com.twitter.util.Future<scala.runtime.BoxedUnit> close()
        Specified by:
        close in interface com.twitter.util.Closable

      • close

        public com.twitter.util.Future<scala.runtime.BoxedUnit> close​(com.twitter.util.Time deadline)
        There are two queues here. The recorder has in-flight data about operations not yet complete. The reporter (usually) has a queue of spans for operations completed, not yet sent to Zipkin.

        The close process tries to avoid dropping data on the floor by first flushing any in-flight operations in the recorder (ideally none), then any spans waiting for the next send interval to Zipkin.

        Specified by:
        close in interface com.twitter.util.Closable

      • close

        public com.twitter.util.Future<scala.runtime.BoxedUnit> close​(com.twitter.util.Duration after)
        Specified by:
        close in interface com.twitter.util.Closable