anchor.diff:  
   == Customizations
   
  -=== Customizers
  -
  -With Brave 5.7 you have various options of providing customizers for your project. Brave ships with
  -
  -* `TracingCustomizer` - allows configuration plugins to collaborate on building an instance of `Tracing`.
  -* `CurrentTraceContextCustomizer` - allows configuration plugins to collaborate on building an instance of `CurrentTraceContext`.
  -* `ExtraFieldCustomizer` - allows configuration plugins to collaborate on building an instance of `ExtraFieldPropagation.Factory`.
  -
  -Sleuth will search for beans of those types and automatically apply customizations.
  +The `Tracer` object is fully managed by sleuth, so you rarely need to affect it. That said,
  +Sleuth supports a number of `Customizer` types, that allow you to configure
  +anything not already done by Sleuth with auto-configuration or properties.
  +
  +If you define one of the following as a `Bean`, Sleuth will invoke it to
  +customize behaviour:
  +
  +* RpcTracingCustomizer - for RPC tagging and sampling policy
  +* HttpTracingCustomizer - for HTTP tagging and sampling policy
  +* MessagingTracingCustomizer - for messaging tagging and sampling policy
  +* CurrentTraceContextCustomizer - to integrate decorators such as correlation.
  +* BaggagePropagationCustomizer - for propagating baggage fields in process and over headers
  +* CorrelationScopeDecoratorCustomizer - for scope decorations such as MDC (logging) field correlation
   
   === HTTP
   
  
positive.code: 
  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
  
  
negative.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 `b3` 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).
  
  == Baggage
  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.
  