From 3608702500a33235d24807da5981ca99ad6dd3c2 Mon Sep 17 00:00:00 2001 From: buildmaster Date: Fri, 7 Sep 2018 14:21:18 +0000 Subject: [PATCH] Sync docs from 1.3.x to gh-pages --- 1.3.x/multi/multi__customizations.html | 6 +++++- 1.3.x/single/spring-cloud-sleuth.html | 6 +++++- 1.3.x/spring-cloud-sleuth.xml | 5 +++++ 3 files changed, 15 insertions(+), 2 deletions(-) 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 @@ 9. Customizations

9. Customizations

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:

  • via Spring Integration
  • via HTTP

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".

9. Customizations

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:

  • via Spring Integration
  • via HTTP

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. 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 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