diff --git a/1.3.x/multi/multi__customizations.html b/1.3.x/multi/multi__customizations.html index 3407fb52b..fe9af9fa2 100644 --- a/1.3.x/multi/multi__customizations.html +++ b/1.3.x/multi/multi__customizations.html @@ -3,7 +3,11 @@
Thanks to the SpanInjector and SpanExtractor you can customize the way spans
are created and propagated.
There are currently two built-in ways to pass tracing information between processes:
Span ids are extracted from Zipkin-compatible (B3) headers (either Message
or HTTP headers), to start or join an existing trace. Trace information is
-injected into any outbound requests so the next hop can extract them.
The key change in comparison to the previous versions of Sleuth is that Sleuth is implementing +injected into any outbound requests so the next hop can extract them.
The default way of coding tracing context is done via the b3 header that contains the
+traceId-spanId-sampled notation (e.g. 0000000000000005-0000000000000004-1).
+For backward compatibility, if the b3 header is not present, we also check if
+X-B3 entries are present, and retrieve tracing context from there e.g.
+(X-B3-TraceId: 0000000000000005, X-B3-SpanId: 0000000000000004, X-B3-Sampled: 1).
The key change in comparison to the previous versions of Sleuth is that Sleuth is implementing
the Open Tracing’s TextMap notion. In Sleuth it’s called SpanTextMap. Basically the idea
is that any means of communication (e.g. message, http request, etc.) can be abstracted via
a SpanTextMap. This abstraction defines how one can insert data into the carrier and
diff --git a/1.3.x/single/spring-cloud-sleuth.html b/1.3.x/single/spring-cloud-sleuth.html
index 27f5ad05f..2c26daf22 100644
--- a/1.3.x/single/spring-cloud-sleuth.html
+++ b/1.3.x/single/spring-cloud-sleuth.html
@@ -422,7 +422,11 @@ of the bean.
if executed with a value of 15 will lead to setting of a tag with a String value of "15".
Thanks to the SpanInjector and SpanExtractor you can customize the way spans
are created and propagated.
There are currently two built-in ways to pass tracing information between processes:
Span ids are extracted from Zipkin-compatible (B3) headers (either Message
or HTTP headers), to start or join an existing trace. Trace information is
-injected into any outbound requests so the next hop can extract them.
The key change in comparison to the previous versions of Sleuth is that Sleuth is implementing +injected into any outbound requests so the next hop can extract them.
The default way of coding tracing context is done via the b3 header that contains the
+traceId-spanId-sampled notation (e.g. 0000000000000005-0000000000000004-1).
+For backward compatibility, if the b3 header is not present, we also check if
+X-B3 entries are present, and retrieve tracing context from there e.g.
+(X-B3-TraceId: 0000000000000005, X-B3-SpanId: 0000000000000004, X-B3-Sampled: 1).
The key change in comparison to the previous versions of Sleuth is that Sleuth is implementing
the Open Tracing’s TextMap notion. In Sleuth it’s called SpanTextMap. Basically the idea
is that any means of communication (e.g. message, http request, etc.) can be abstracted via
a SpanTextMap. This abstraction defines how one can insert data into the carrier and
diff --git a/1.3.x/spring-cloud-sleuth.xml b/1.3.x/spring-cloud-sleuth.xml
index 727514e3c..046540eca 100644
--- a/1.3.x/spring-cloud-sleuth.xml
+++ b/1.3.x/spring-cloud-sleuth.xml
@@ -1063,6 +1063,11 @@ are created and propagated.