Jaeger Bindings for Java OpenTracing API
This is a client side library that implements Java OpenTracing API, with Zipkin-compatible data model.
Click through for more detailed docs on specific modules.
- jaeger-core: the core implementation of the OpenTracing API
- jaeger-context: in-process context propagation
- jaeger-dropwizard: a feature to initialize Jaeger from Dropwizard apps (including binding to stats/metrics)
- jaeger-apachehttpclient: instrumentation for apache http clients
- jaeger-jaxrs2: instrumentation for JAXRS2 filters
- jaeger-zipkin: compatibility layer for using Jaeger tracer as Zipkin-compatible implementation
For e.g, to depend on the core jaeger library, you'd include the following
<dependency> <groupId>com.uber.jaeger</groupId> <artifactId>jaeger-core</artifactId> <version>$jaegerVersion</version> </dependency>
Thrift version conflicts
Jaeger client uses
org.apache.thrift:libthrift:0.9.2. If your project depends on a different
libthrift, it is recommended that you use the shaded
jaeger-thrift jar we publish
which packages it's own
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>com.uber.jaeger</groupId> <artifactId>jaeger-thrift</artifactId> <classifier>thrift92</classifier> <version>$jaegerVersion</version> </dependency> </dependencies> </dependencyManagement>
In-process Context Propagation
TraceContext that can be used for propagating the current tracing
throughout the application without changing the application's code. However, if the application
is starting new threads or is using thread pools, the thread-local context is not going to be
carried over into the execution in the next thread. To maintain context propagation,
TracedExecutorService is provided that automatically transfers the context
onto the new threads.
ExecutorService instrumentedExecutorService = TracingUtils.tracedExecutor(wrappedExecutorService);
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, (short) 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.
git submodule init update
./gradlew googleJavaFormat clean test
This project uses google java style. It is recommended to set up a git precommit hook as follows.
cat>.git/hooks/pre-commit #!/bin/sh # # Pre-commit hooks # Format code using the google formatter echo "pre-commit code format" ./gradlew googleJavaFormat ^D
chmod a+x .git/hooks/pre-commit
You can also setup the IntelliJ plugin to reformat code from within your IDE