anchor.diff:  
   If you want to add the baggage entries as tags, to make it possible to search for spans via the baggage entries, you can set the value of
   `spring.sleuth.propagation.tag.whitelisted-keys` with a list of whitelisted baggage keys. To disable the feature you have to pass the `spring.sleuth.propagation.tag.enabled=false` property.
  -
  -==== Extracting a Propagated Context
  -
  -The `TraceContext.Extractor<C>` reads trace identifiers and sampling status from an incoming request or message.
  -The carrier is usually a request object or headers.
  -
  -This utility is used in standard instrumentation (such as `HttpServerHandler`) but can also be used for custom RPC or messaging code.
  -
  -`TraceContextOrSamplingFlags` is usually used only with `Tracer.nextSpan(extracted)`, unless you are
  -sharing span IDs between a client and a server.
  -
  -==== Sharing span IDs between Client and Server
  -
  -A normal instrumentation pattern is to create a span representing the server side of an RPC.
  -`Extractor.extract` might return a complete trace context when applied to an incoming client request.
  -`Tracer.joinSpan` attempts to continue this trace, using the same span ID if supported or creating a child span
  -if not. When the span ID is shared, the reported data includes a flag saying so.
  -
  -The following image shows an example of B3 propagation:
  -
  -```
  -                              ┌───────────────────┐      ┌───────────────────┐
  - Incoming Headers             │   TraceContext    │      │   TraceContext    │
  -┌───────────────────┐(extract)│ ┌───────────────┐ │(join)│ ┌───────────────┐ │
  -│ X─B3-TraceId      │─────────┼─┼> TraceId      │ │──────┼─┼> TraceId      │ │
  -│                   │         │ │               │ │      │ │               │ │
  -│ X─B3-ParentSpanId │─────────┼─┼> ParentSpanId │ │──────┼─┼> ParentSpanId │ │
  -│                   │         │ │               │ │      │ │               │ │
  -│ X─B3-SpanId       │─────────┼─┼> SpanId       │ │──────┼─┼> SpanId       │ │
  -└───────────────────┘         │ │               │ │      │ │               │ │
  -                              │ │               │ │      │ │  Shared: true │ │
  -                              │ └───────────────┘ │      │ └───────────────┘ │
  -                              └───────────────────┘      └───────────────────┘
  -```
  -
  -Some propagation systems forward only the parent span ID, detected when `Propagation.Factory.supportsJoin() == false`.
  -In this case, a new span ID is always provisioned, and the incoming context determines the parent ID.
  -
  -The following image shows an example of AWS propagation:
  -```
  -                              ┌───────────────────┐      ┌───────────────────┐
  - x-amzn-trace-id              │   TraceContext    │      │   TraceContext    │
  -┌───────────────────┐(extract)│ ┌───────────────┐ │(join)│ ┌───────────────┐ │
  -│ Root              │─────────┼─┼> TraceId      │ │──────┼─┼> TraceId      │ │
  -│                   │         │ │               │ │      │ │               │ │
  -│ Parent            │─────────┼─┼> SpanId       │ │──────┼─┼> ParentSpanId │ │
  -└───────────────────┘         │ └───────────────┘ │      │ │               │ │
  -                              └───────────────────┘      │ │  SpanId: New  │ │
  -                                                         │ └───────────────┘ │
  -                                                         └───────────────────┘
  -```
  -
  -Note: Some span reporters do not support sharing span IDs.
  -For example, if you set `Tracing.Builder.spanReporter(amazonXrayOrGoogleStackdrive)`, you should disable join by setting `Tracing.Builder.supportsJoin(false)`.
  -Doing so forces a new child span on `Tracer.joinSpan()`.
  -
  -==== Implementing Propagation
  -
  -`TraceContext.Extractor<C>` is implemented by a `Propagation.Factory` plugin.
  -Internally, this code creates the union type, `TraceContextOrSamplingFlags`, with one of the following:
  -* `TraceContext` if trace and span IDs were present.
  -* `TraceIdContext` if a trace ID was present but span IDs were not present.
  -* `SamplingFlags` if no identifiers were present.
  -
  -Some `Propagation` implementations carry extra data from the point of extraction (for example, reading incoming headers) to injection (for example, writing outgoing headers).
  -For example, it might carry a request ID.
  -When implementations have extra data, they handle it as follows:
  -* If a `TraceContext` were extracted, add the extra data as `TraceContext.extra()`.
  -* Otherwise, add it as `TraceContextOrSamplingFlags.extra()`, which `Tracer.nextSpan` handles.
  -
  -== Current Tracing Component
  -
  -Brave supports a "`current tracing component`" concept, which should only be used when you have no other way to get a reference.
  -This was made for JDBC connections, as they often initialize prior to the tracing component.
  -
  -The most recent tracing component instantiated is available through `Tracing.current()`.
  -You can also use `Tracing.currentTracer()` to get only the tracer.
  -If you use either of these methods, do not cache the result.
  -Instead, look them up each time you need them.
  -
  -== Current Span
  -
  -Brave supports a "`current span`" concept which represents the in-flight operation.
  -You can use `Tracer.currentSpan()` to add custom tags to a span and `Tracer.nextSpan()` to create a child of whatever is in-flight.
  -
  -IMPORTANT: In Sleuth, you can autowire the `Tracer` bean to retrieve the current span via
  -`tracer.currentSpan()` method. To retrieve the current context just call
  -`tracer.currentSpan().context()`. To get the current trace id as String
  -you can use the `traceIdString()` method like this: `tracer.currentSpan().context().traceIdString()`.
  -
  -=== Setting a span in scope manually
  -
  -When writing new instrumentation, it is important to place a span you created in scope as the current span.
  -Not only does doing so let users access it with `Tracer.currentSpan()`, but it also allows customizations such as SLF4J MDC to see the current trace IDs.
  -
  -`Tracer.withSpanInScope(Span)` facilitates this and is most conveniently employed by using the try-with-resources idiom.
  -Whenever external code might be invoked (such as proceeding an interceptor or otherwise), place the span in scope, as shown in the following example:
  -
  -```java
  -@Autowired Tracer tracer;
  -
  -try (SpanInScope ws = tracer.withSpanInScope(span)) {
  -  return inboundRequest.invoke();
  -} finally { // note the scope is independent of the span
  -  span.finish();
  -}
  -```
  -
  -In edge cases, you may need to clear the current span temporarily (for example, launching a task that should not be associated with the current request). To do tso, pass null to `withSpanInScope`, as shown in the following example:
  -
  -```java
  -@Autowired Tracer tracer;
  -
  -try (SpanInScope cleared = tracer.withSpanInScope(null)) {
  -  startBackgroundThread();
  -}
  -```
   
   == Instrumentation
   
  
positive.code: include::{project-root}/spring-cloud-sleuth-core/src/test/java/org/springframework/cloud/sleuth/documentation/SpringCloudSleuthDocTests.java[tags=always_sampler,indent=0]
  ----
  
  TIP: You can set the HTTP header `X-B3-Flags` to `1`, or, when doing messaging, you can set the `spanFlags` header to `1`.
  Doing so forces the current span to be exportable regardless of the sampling decision.
  
  In order to use the rate-limited sampler set the `spring.sleuth.sampler.rate` property to choose an amount of traces to accept on a per-second interval. The minimum number is 0 and the max is 2,147,483,647 (max int).
  
  == Propagation
  
  Propagation is needed to ensure activities originating from the same root are collected together in the same trace.
  The most common propagation approach is to copy a trace context from a client by sending an RPC request to a server receiving it.
  
  For example, when a downstream HTTP call is made, its trace context is encoded as request headers and sent along with it, as shown in the following image:
  
  ```
     Client Span                                                Server Span
  ┌──────────────────┐                                       ┌──────────────────┐
  │                  │                                       │                  │
  │   TraceContext   │           Http Request Headers        │   TraceContext   │
  │ ┌──────────────┐ │          ┌───────────────────┐        │ ┌──────────────┐ │
  │ │ TraceId      │ │          │ X─B3─TraceId      │        │ │ TraceId      │ │
  │ │              │ │          │                   │        │ │              │ │
  │ │ ParentSpanId │ │ Extract  │ X─B3─ParentSpanId │ Inject │ │ ParentSpanId │ │
  │ │              ├─┼─────────>│                   ├────────┼>│              │ │
  │ │ SpanId       │ │          │ X─B3─SpanId       │        │ │ SpanId       │ │
  │ │              │ │          │                   │        │ │              │ │
  │ │ Sampled      │ │          │ X─B3─Sampled      │        │ │ Sampled      │ │
  │ └──────────────┘ │          └───────────────────┘        │ └──────────────┘ │
  │                  │                                       │                  │
  └──────────────────┘                                       └──────────────────┘
  ```
  
  The names above are from https://github.com/openzipkin/b3-propagation[B3 Propagation], which is built-in to Brave and has implementations in many languages and frameworks.
  
  Most users use a framework interceptor to automate propagation.
  The next two examples show how that might work for a client and a server.
  
  The following example shows how client-side propagation might work:
  
  ```java
  @Autowired Tracing tracing;
  
  // configure a function that injects a trace context into a request
  injector = tracing.propagation().injector(Request.Builder::addHeader);
  
  // before a request is sent, add the current span's context to it
  injector.inject(span.context(), request);
  ```
  
  The following example shows how server-side propagation might work:
  
  ```java
  @Autowired Tracing tracing;
  @Autowired Tracer tracer;
  
  // configure a function that extracts the trace context from a request
  extractor = tracing.propagation().extractor(Request::getHeader);
  
  // when a server receives a request, it joins or starts a new trace
  span = tracer.nextSpan(extractor.extract(request));
  ```
  
  === Propagating extra fields
  
  Sometimes you need to propagate extra fields, such as a request ID or an alternate trace context.
  For example, if you are in a Cloud Foundry environment, you might want to pass the request ID, as shown in the following example:
  
  ```java
  // when you initialize the builder, define the extra field you want to propagate
  Tracing.newBuilder().propagationFactory(
    ExtraFieldPropagation.newFactory(B3Propagation.FACTORY, "x-vcap-request-id")
  );
  
  // later, you can tag that request ID or use it in log correlation
  requestId = ExtraFieldPropagation.get("x-vcap-request-id");
  ```
  
  You may also need to propagate a trace context that you are not using.
  For example, you may be in an Amazon Web Services environment but not be reporting data to X-Ray.
  To ensure X-Ray can co-exist correctly, pass-through its tracing header, as shown in the following example:
  
  ```java
  tracingBuilder.propagationFactory(
    ExtraFieldPropagation.newFactory(B3Propagation.FACTORY, "x-amzn-trace-id")
  );
  ```
  
  TIP: In Spring Cloud Sleuth all elements of the tracing builder `Tracing.newBuilder()`
  are defined as beans. So if you want to pass a custom `PropagationFactory`, it's enough
  for you to create a bean of that type and we will set it in the `Tracing` bean.
  
  [[prefixed-fields]]
  ==== Prefixed fields
  
  If they follow a common pattern, you can also prefix fields.
  The following example shows how to propagate `x-vcap-request-id` the field as-is but send the `country-code` and `user-id` fields on the wire as `x-baggage-country-code` and `x-baggage-user-id`, respectively:
  
  ```java
  Tracing.newBuilder().propagationFactory(
    ExtraFieldPropagation.newFactoryBuilder(B3Propagation.FACTORY)
                         .addField("x-vcap-request-id")
                         .addPrefixedFields("x-baggage-", Arrays.asList("country-code", "user-id"))
                         .build()
  );
  ```
  
  Later, you can call the following code to affect the country code of the current trace context:
  
  ```java
  ExtraFieldPropagation.set("x-country-code", "FO");
  String countryCode = ExtraFieldPropagation.get("x-country-code");
  ```
  
  Alternatively, if you have a reference to a trace context, you can use it explicitly, as shown in the following example:
  
  ```java
  ExtraFieldPropagation.set(span.context(), "x-country-code", "FO");
  String countryCode = ExtraFieldPropagation.get(span.context(), "x-country-code");
  ```
  
  IMPORTANT: A difference from previous versions of Sleuth is that, with Brave, you must pass the list of baggage keys.
  There are the following properties to achieve this.
  With the `spring.sleuth.baggage-keys`, you set keys that get prefixed with `baggage-` for HTTP calls and `baggage_` for messaging.
  You can also use the `spring.sleuth.propagation-keys` property to pass a list of prefixed keys that are propagated to remote services without any prefix.
  You can also use the `spring.sleuth.local-keys` property to pass a list keys that will be propagated locally but will not be propagated over the wire.
  
negative.code: 
  include::features.adoc[]
  
  == Introduction to Brave
  
  Brave is a distributed tracing instrumentation library. Brave typically
  intercepts production requests to gather timing data, correlate and propagate
  trace contexts. While typically trace data is sent to Zipkin server,
  third-party plugins are available to send to alternate services such as Amazon
  X-Ray.
  
  Spring Cloud Sleuth is a layer over https://github.com/openzipkin/brave[Brave].
  It configures everything you need to get started with tracing. Sleuth
  configures where trace data (spans) are reported to, how many traces to keep
  (sampling), if remote fields (baggage) and which libraries are traced.
  Sleuth also adds annotation based tracing features and some instrumentation not
  available otherwise, such as Reactor.
  
  === Brave Basics
  
  Most instrumentation work is done for you by default. Sleuth provides beans to
  allow you to change what's traced, and it even provides annotations to avoid
  using tracing libraries! All of this is explained later in this document.
  
  That said, you might want to know more about how things work underneath. Here
  are some pointers.
  
  Here are the most core types you might use:
  * `SpanCustomizer` - to change the span currently in progress
  * `Tracer` - to get a start new spans ad-hoc
  
  Here are the most relevant links from the OpenZipkin Brave project:
  * [Brave's core library](https://github.com/openzipkin/brave/tree/master/brave)
  * [Baggage (propagated fields)](https://github.com/openzipkin/brave/tree/master/brave#baggage)
  * [HTTP tracing](https://github.com/openzipkin/brave/tree/master/instrumentation/http)
  
  == Sampling
  
  By default Spring Cloud Sleuth sets all spans to non-exportable.
  That means that traces appear in logs but not in any remote store.
  