== 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. 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 or not. When would you like the span not to be
    exportable? In the case in which 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,
key-value annotations. Loosely based on HTrace, but Zipkin (Dapper) compatible.

* Sleuth records timing information to aid in latency analysis. 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.
  - propagates structural data about your call-graph in-band, and the rest out-of-band.
  - includes opinionated instrumentation of layers such as HTTP
  - includes 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, feign client).

* Sleuth includes default logic to join a trace across http or messaging boundaries. For example, http propagation
works via Zipkin-compatible request headers. This propagation logic is defined and customized via
`SpanInjector` and `SpanExtractor` implementations.

* Sleuth gives you the possibility to propagate context (also known as baggage) between processes. That means that if you set on a Span
a baggage element then it will be sent downstream either via HTTP or messaging to other processes.

* Provides a way to create / continue spans and add tags and logs via annotations.

* Provides simple metrics of accepted / dropped spans.

* If `spring-cloud-sleuth-zipkin` then the app will generate and collect Zipkin-compatible traces.
By default it sends them via HTTP to a Zipkin server on localhost (port 9411).
Configure the location of the service using `spring.zipkin.baseUrl`.

* If `spring-cloud-sleuth-stream` then the app will generate and collect traces via https://github.com/spring-cloud/spring-cloud-stream[Spring Cloud Stream].
Your app automatically becomes a producer of tracer messages that are sent over your broker of choice
(e.g. RabbitMQ, Apache Kafka, Redis).

IMPORTANT: If using Zipkin or Stream, configure the percentage of spans exported using `spring.sleuth.sampler.percentage`
(default 0.1, i.e. 10%). *Otherwise you might think that Sleuth is not working cause it's omitting some spans.*

NOTE: the SLF4J MDC is always set and logback users will immediately see the trace and span ids in logs per the example
 above. Other logging systems have to configure their own formatter to get the same result. The default is
 `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).
 *This means that if you're not using SLF4J this pattern WILL NOT be automatically applied*.