== Features

* Adds trace and span IDs to the Slf4J MDC, so you can extract all the logs from a given trace or span in a log aggregator, as shown in the following example logs:
+
----
2016-02-02 15:30:57.902  INFO [bar,6bfd228dc00d216b,6bfd228dc00d216b,false] 23030 --- [nio-8081-exec-3] ...
2016-02-02 15:30:58.372 ERROR [bar,6bfd228dc00d216b,6bfd228dc00d216b,false] 23030 --- [nio-8081-exec-3] ...
2016-02-02 15:31:01.936  INFO [bar,46ab0d418373cbc9,46ab0d418373cbc9,false] 23030 --- [nio-8081-exec-4] ...
----
+
Notice the `[appname,traceId,spanId,exportable]` entries from the MDC:

** *`spanId`*: The ID of a specific operation that took place.
** *`appname`*: The name of the application that logged the span.
** *`traceId`*: The ID of the latency graph that contains the span.
** *`exportable`*: Whether the log should be exported to Zipkin.
When would you like the span not to be exportable?
When you want to wrap some operation in a Span and have it written to the logs only.

* Provides an abstraction over common distributed tracing data models: traces, spans (forming a DAG), annotations, and key-value annotations.
Spring Cloud Sleuth is loosely based on HTrace but is compatible with Zipkin (Dapper).

* Sleuth records timing information to aid in latency analysis.
By using sleuth, you can pinpoint causes of latency in your applications.

* Sleuth is written to not log too much and to not cause your production application to crash.
To that end, Sleuth:
** Propagates structural data about your call graph in-band and the rest out-of-band.
** Includes opinionated instrumentation of layers such as HTTP.
** Includes a sampling policy to manage volume.
** Can report to a Zipkin system for query and visualization.

* Instruments common ingress and egress points from Spring applications (servlet filter, async endpoints, rest template, scheduled actions, message channels, Zuul filters, and Feign client).

* Sleuth includes default logic to join a trace across HTTP or messaging boundaries.
For example, HTTP propagation works over Zipkin-compatible request headers.

* Sleuth can propagate context (also known as baggage) between processes.
Consequently, if you set  a baggage element on a Span, it is sent downstream to other processes over either HTTP or messaging.

* Provides a way to create or continue spans and add tags and logs through annotations.

* If `spring-cloud-sleuth-zipkin` is on the classpath, the app generates and collects Zipkin-compatible traces.
By default, it sends them over HTTP to a Zipkin server on localhost (port 9411).
You can configure the location of the service by setting `spring.zipkin.baseUrl`.
** If you depend on `spring-rabbit`, your app sends traces to a RabbitMQ broker instead of HTTP.
** If you depend on `spring-kafka`, and set `spring.zipkin.sender.type: kafka`, your app sends traces to a Kafka broker instead of HTTP.

CAUTION: `spring-cloud-sleuth-stream` is deprecated and should no longer be used.

* Spring Cloud Sleuth is https://opentracing.io/[OpenTracing] compatible.

IMPORTANT: If you use Zipkin, configure the probability of spans exported by setting `spring.sleuth.sampler.probability`
(default: 0.1, which is 10 percent). Otherwise, you might think that Sleuth is not working be cause it omits some spans.

NOTE: The SLF4J MDC is always set and logback users immediately see the trace and span IDs in logs per the example
shown earlier.
Other logging systems have to configure their own formatter to get the same result.
The default is as follows:
`logging.pattern.level` set to `%5p [${spring.zipkin.service.name:${spring.application.name:-}},%X{X-B3-TraceId:-},%X{X-B3-SpanId:-},%X{X-Span-Export:-}]`
(this is a Spring Boot feature for logback users).
If you do not use SLF4J, this pattern is NOT automatically applied.
