Jaeger's Tracing Instrumentation Library for Java
- Intended to be used with Jaeger backend, but can also be configured to send traces to Zipkin.
- Implements OpenTracing Java API.
- Supports Java 1.6 and above
Package rename to
The group ID
com.uber.jaeger has been deprecated and moved to a different repository.
Please switch to
io.jaegertracing, as the old group ID will be maintained only for bug fixes.
Contributing and Developing
Please see CONTRIBUTING.md.
Click through for more detailed docs on specific modules.
- jaeger-client: the module that instrumented applications should usually include
- jaeger-core: the core implementation of the OpenTracing API
- jaeger-thrift: set of components that send data to the backend
- jaeger-zipkin: compatibility layer for using the Jaeger Tracer to Zipkin-compatible backends
- jaeger-micrometer: a metrics provider, to report internal Jaeger Client metrics to third-party backends, such as Prometheus
- jaeger-tracerresolver: an OpenTracing
TracingResolverfor the Jaeger Tracer.
In the usual case, you just need to include the following dependency to your project:
<dependency> <groupId>io.jaegertracing</groupId> <artifactId>jaeger-client</artifactId> <version>$jaegerVersion</version> </dependency>
This will bring a concrete sender, such as
jaeger-thrift, as well as the
Thrift version conflicts
The Jaeger Java Client uses
org.apache.thrift:libthrift:0.11.0. By default, declaring a dependency on the
jaeger-thrift module will bring a shaded version of Thrift (and others), making it safe to use your own versions of
such dependencies. A non-shaded version of the dependency is available with the classifier
no-shadow, but the
transitive dependencies (Thrift included) will have to be added manually to your project.
Instantiating the Tracer
Please see jaeger-core/README.
When testing tracing instrumentation it is often useful to make sure that all spans are being captured, which is not the case in production configurations where heavy sampling is applied by default. The following configuration can be provided to affect which sampling is applied to the new traces:
sampler: type: const # can either be const, probabilistic, or ratelimiting param: 1 # can either be an integer, a double, or an integer
The valid values for
const: configures a sampler that always makes the same decision for new traces depending on the
param: always no for
param=0, always yes otherwise.
probabilistic: configures a sampler that samples traces with probability equal to
param(must be between
ratelimiting: configures a samlper that samples traces with a certain rate per second equal to
Debug Traces (Forced Sampling)
The OpenTracing API defines a
sampling.priority standard tag that
can be used to affect the sampling of a span and its children:
import io.opentracing.tag.Tags; Tags.SAMPLING_PRIORITY.set(span, 1);
Via HTTP Headers
Jaeger Tracer also understands a special HTTP Header
which can be set in the incoming request, e.g.
curl -H "jaeger-debug-id: some-correlation-id" http://myhost.com
When Jaeger sees this header in the request that otherwise has no tracing context, it ensures that the new trace started for this request will be sampled in the "debug" mode (meaning it should survive all downsampling that might happen in the collection pipeline), and the root span will have a tag as if this statement was executed:
This allows using Jaeger UI to find the trace by this tag.