This section dives into the details of Spring Cloud Sleuth OTel. Here you can learn about the key features that you may want to use and customize. If you have not already done so, you might want to read the "getting-started.html" and "using.html" sections, so that you have a good grounding in the basics.
1. Context Propagation
Traces connect from service to service using header propagation. The default format is B3. Similar to data formats, you can configure alternate header formats also, provided trace and span IDs are compatible with B3. Most notably, this means the trace ID and span IDs are lower-case hex, not UUIDs. Besides trace identifiers, other properties (Baggage) can also be passed along with the request. Remote Baggage must be predefined, but is flexible otherwise.
To use the provided defaults you can set the spring.sleuth.propagation.type
property.
The value can be a list in which case you will propagate more tracing headers.
For OpenTelemetry we support AWS
, B3
, JAEGER
, OT_TRACER
and W3C
via the io.opentelemetry:opentelemetry-extension-trace-propagators
dependency that you have to manually add to your classpath.
You can read more about how to provide custom context propagation in this "how to section".
2. OpenTelemetry Tracer Integration
Spring Cloud Sleuth integrates with the OpenTelemetry (OTel in short) SDK tracer via the bridge that is available in the spring-cloud-sleuth-otel
module.
In this section you can read about specific OTel integrations.
You can choose to use either Sleuth’s API or the OpenTelemetry API directly in your code (e.g. either Sleuth’s Tracer
or OpenTelemetry’s Tracer
).
If you want to use this tracer implementation’s API directly please read their documentation to learn more about it.
2.1. OpenTelemetry Exporters Integration
2.1.1. OpenTelemetry Logging
We’re providing an Slf4j integration via a SpanProcessor
that injects to and removes entries (trace / span ids, baggage, tags etc.) from MDC. You can disable that via the spring.sleuth.otel.log.slf4j.enabled=false
property.
If it’s there on the classpath, we integrate with the LoggingSpanExporter
.
You can disable that integration via the spring.sleuth.otel.log.exporter.enabled=false
property.
2.1.2. OpenTelemetry Jaeger Integration
We’re providing an out-of-the-box integration with the OTel Jaeger exporter. via the io.opentelemetry:opentelemetry-exporter-jaeger
dependency.
For configuration options please check the spring.sleuth.otel.exporter.jaeger
properties in the appendix. To fully override the default configuration please register a bean of JaegerGrpcSpanExporter
type.
2.1.3. OpenTelemetry OTLP Integration
We’re providing an out-of-the-box integration with the OTel OTLP gRPC exporter. via the io.opentelemetry:opentelemetry-exporter-otlp
dependency.
For configuration options please check the spring.sleuth.otel.exporter.otlp
properties in the appendix. To fully override the default configuration please register a bean of OtlpGrpcSpanExporter
type.
2.2. OpenTelemetry ResourceProvider
OpenTelemetry provides a Resource
abstraction which captures identifying information about the entities for which signals (stats or traces) are reported. If you wish to provide your own, you can register beans of Supplier<Resource>
type.
You can disable the registration of the default Supplier<Resource>
beans via the spring.sleuth.otel.resource.enabled=false
property.
2.3. OpenTelemetry Opentracing
You can integrate with OpenTelemetry and OpenTracing via the
io.opentelemetry:opentelemetry-opentracing-shim
bridge.
Just add it to the classpath and the OpenTracing Tracer
will be set up automatically.
3. Sending Spans to Zipkin
Spring Cloud Sleuth provides various integrations with the OpenZipkin distributed tracing system.
Regardless of the chosen tracer implementation it’s enough to add spring-cloud-sleuth-zipkin
to the classpath to start sending spans to Zipkin.
You can choose whether to do that via HTTP or messaging.
You can read more about how to do that in "how to section".
4. Traces Actuator Endpoint
Spring Cloud Sleuth comes with a traces
Actuator endpoint that can store finished spans. The endpoint can be queried either via an HTTP Get method to simply retrieve the list of stored spans or via HTTP Post method to retrieve the list and clear it.
In order to represent the OTel spans in a Zipkin format you need to add the io.opentelemetry:opentelemetry-exporter-zipkin
to the classpath. To represent the spans in an OTLP format you need to add io.opentelemetry:opentelemetry-exporter-otlp-common
to the classpath.
5. What to Read Next
If you want to learn more about any of the classes discussed in this section, you can browse the source code directly. If you have specific questions, see the how-to section.