- Intended to be used with Jaeger backend, but can also be configured to send traces to Zipkin.
- Implement Java OpenTracing API.
- Supports Java 1.6 and above
Groupid com.uber.jaeger
has been deprecated and moved to a different repository.
Please switch to io.jaegertracing
. Old groupid will be maintained only for bug fixes.
Please see CONTRIBUTING.md.
Click through for more detailed docs on specific modules.
- jaeger-core: the core implementation of the OpenTracing API
- jaeger-zipkin: compatibility layer for using Jaeger tracer as Zipkin-compatible implementation
- jaeger-micrometer: a metrics provider, to report internal Jaeger metrics to third-party backends, such as Prometheus
- jaeger-tracerresolver: a tracer resolver for Jaeger tracer.
All artifacts are published to Maven Central. Snapshot artifacts are also published to Sonatype. Follow these instructions to add the snapshot repository to your build system.
Add the required dependencies to your project. Usually, this would only be the add-ons you require. Please use the latest version:
For e.g, to depend on the core jaeger library, you'd include the following
<dependency>
<groupId>io.jaegertracing</groupId>
<artifactId>jaeger-core</artifactId>
<version>$jaegerVersion</version>
</dependency>
Jaeger client uses org.apache.thrift:libthrift:0.9.2
. If your project depends on a different
version of libthrift
, it is recommended that you use the shaded jaeger-thrift
jar we publish
which packages it's own libthrift
.
To depend on the shaded jar, add the following to your maven build. Note that this is only supported for a jaeger version >= 0.15.0
<dependencyManagement>
<dependencies>
<dependency>
<groupId>io.jaegertracing</groupId>
<artifactId>jaeger-thrift</artifactId>
<classifier>thrift92</classifier>
<version>$jaegerVersion</version>
</dependency>
</dependencies>
</dependencyManagement>
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 type
are:
const
: configures a sampler that always makes the same decision for new traces depending on theparam
: always no forparam=0
, always yes otherwise.probabilistic
: configures a sampler that samples traces with probability equal toparam
(must be between0.0
and1.0
)ratelimiting
: configures a samlper that samples traces with a certain rate per second equal toparam
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);
Jaeger Tracer also understands a special HTTP Header jaeger-debug-id
,
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:
span.setTag("jaeger-debug-id", "some-correlation-id")
This allows using Jaeger UI to find the trace by this tag.