Spring Cloud Sleuth implements a distributed tracing solution for Spring Cloud, borrowing heavily from Dapper, Zipkin, and HTrace. For most users, Sleuth should be invisible, and all your interactions with external systems should be instrumented automatically. You can capture data in logs or by sending it to a remote collector service.
Features
A span is the basic unit of work. For example, sending an RPC is a new span, as is sending
a response to an RPC. Spans are identified by a unique 64-bit ID for the span and another
64-bit ID for the trace of which the span is a part. Spans also have other data, such as
descriptions, key-value annotations, the ID of the span that caused them, and process IDs
(normally IP addresses). Spans are started and stopped, and they keep track of their
timing information. Once you create a span, you must stop it at some point in the future.
A set of spans (which form a tree-like structure) is called a trace. For example, if you
run a distributed big-data store, a trace might be formed by a PUT request.
Spring Cloud Sleuth:
-
Adds trace and span IDs to the Slf4J MDC so that you can extract all the logs from a given trace or span in a log aggregator.
-
Provides an abstraction over common distributed tracing data models: traces, spans (forming a DAG), annotations, and key-value annotations. This is loosely based on HTrace but is Zipkin (Dapper) compatible.
-
Instruments common ingress and egress points from Spring applications (servlet filter, rest template, scheduled actions, message channels, zuul filters, and the feign client).
-
If
spring-cloud-sleuth-zipkinis available, the app generates and collects Zipkin-compatible traces over HTTP. By default, it sends them to a Zipkin collector service on localhost (port 9411). You can configure the location of the service usingspring.zipkin.baseUrl.