diff --git a/2.1.x/multi/multi__customizations.html b/2.1.x/multi/multi__customizations.html index c950bf82c..98a07c77a 100644 --- a/2.1.x/multi/multi__customizations.html +++ b/2.1.x/multi/multi__customizations.html @@ -1,31 +1,27 @@ - 12. Customizations
12. Customizations
Prev   Next

12. Customizations

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

12.2 HTTP

If a customization of client / server parsing of the HTTP related spans is required, -just register a bean of type brave.http.HttpClientParser or + 12. Customizations

12. Customizations
Prev   Next

12. Customizations

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

12.2 HTTP

If a customization of client / server parsing of the HTTP related spans is +required, just register a bean of type brave.http.HttpClientParser or brave.http.HttpServerParser. If client /server sampling is required, just -register a bean of type brave.http.HttpSampler and name the bean - sleuthClientSampler for client sampler and sleuthServerSampler for server sampler. - For your convenience the @ClientSampler and @ServerSampler - annotations can be used to inject the proper beans or to - reference the bean names via their static String NAME fields.

Check out Brave’s code to see an example of how to make a path-based sampler +register a bean of type brave.sampler.SamplerFunction<HttpRequest> and name +the bean sleuthHttpClientSampler for client sampler and +sleuthHttpServerSampler for server sampler.

For your convenience the @HttpClientSampler and @HttpServerSampler +annotations can be used to inject the proper beans or to reference the bean +names via their static String NAME fields.

Check out Brave’s code to see an example of how to make a path-based sampler https://github.com/openzipkin/brave/tree/master/instrumentation/http#sampling-policy

If you want to completely rewrite the HttpTracing bean you can use the SkipPatternProvider interface to retrieve the URL Pattern for spans that should be not sampled. Below you can see -an example of usage of SkipPatternProvider inside a server side, HttpSampler.

@Configuration
+an example of usage of SkipPatternProvider inside a server side, Sampler<HttpRequest>.
@Configuration
 class Config {
-  @Bean(name = ServerSampler.NAME)
-  HttpSampler myHttpSampler(SkipPatternProvider provider) {
+  @Bean(name = HttpServerSampler.NAME)
+  SamplerFunction<HttpRequest> myHttpSampler(SkipPatternProvider provider) {
   	Pattern pattern = provider.skipPattern();
-  	return new HttpSampler() {
-
-  		@Override
-  		public <Req> Boolean trySample(HttpAdapter<Req, ?> adapter, Req request) {
-  			String url = adapter.path(request);
-  			boolean shouldSkip = pattern.matcher(url).matches();
-  			if (shouldSkip) {
-  				return false;
-  			}
-  			return null;
+  	return request -> {
+  		String url = request.path();
+  		boolean shouldSkip = pattern.matcher(url).matches();
+  		if (shouldSkip) {
+  			return false;
   		}
+  		return null;
   	};
   }
 }

12.3 TracingFilter

You can also modify the behavior of the TracingFilter, which is the component that is responsible for processing the input HTTP request and adding tags basing on the HTTP response. @@ -55,10 +51,28 @@ You can customize the tags or modify the response headers by registering your ow chain.doFilter(request, response); } -}

12.4 Custom service name

By default, Sleuth assumes that, when you send a span to Zipkin, you want the span’s service name to be equal to the value of the spring.application.name property. +}

12.4 RPC

Sleuth automatically configures the RpcTracing bean which serves as a +foundation for RPC instrumentation such as gRPC or Dubbo.

If a customization of client / server sampling of the RPC traces is required, +just register a bean of type brave.sampler.SamplerFunction<RpcRequest> and +name the bean sleuthRpcClientSampler for client sampler and +sleuthRpcServerSampler for server sampler.

For your convenience the @RpcClientSampler and @RpcServerSampler +annotations can be used to inject the proper beans or to reference the bean +names via their static String NAME fields.

Ex. Here’s a sampler that traces 100 "GetUserToken" server requests per second. +This doesn’t start new traces for requests to the health check service. Other +requests will use the global sampling configuration.

@Configuration
+class Config {
+  @Bean(name = RpcServerSampler.NAME)
+  SamplerFunction<RpcRequest> myRpcSampler() {
+  	Matcher<RpcRequest> userAuth = and(serviceEquals("users.UserService"),
+  			methodEquals("GetUserToken"));
+  	return RpcRuleSampler.newBuilder()
+  			.putRule(serviceEquals("grpc.health.v1.Health"), Sampler.NEVER_SAMPLE)
+  			.putRule(userAuth, RateLimitingSampler.create(100)).build();
+  }
+}

For more, see https://github.com/openzipkin/brave/tree/master/instrumentation/rpc#sampling-policy

12.5 Custom service name

By default, Sleuth assumes that, when you send a span to Zipkin, you want the span’s service name to be equal to the value of the spring.application.name property. That is not always the case, though. There are situations in which you want to explicitly provide a different service name for all spans coming from your application. -To achieve that, you can pass the following property to your application to override that value (the example is for a service named myService):

spring.zipkin.service.name: myService

12.5 Customization of Reported Spans

Before reporting spans (for example, to Zipkin) you may want to modify that span in some way. +To achieve that, you can pass the following property to your application to override that value (the example is for a service named myService):

spring.zipkin.service.name: myService

12.6 Customization of Reported Spans

Before reporting spans (for example, to Zipkin) you may want to modify that span in some way. You can do so by using the FinishedSpanHandler interface.

In Sleuth, we generate spans with a fixed name. Some users want to modify the name depending on values of tags. You can implement the FinishedSpanHandler interface to alter that name.

The following example shows how to register two beans that implement FinishedSpanHandler:

@Bean
@@ -81,7 +95,7 @@ FinishedSpanHandler handlerTwo() {
 			return true; // keep this span
 		}
 	};
-}

The preceding example results in changing the name of the reported span to foo bar, just before it gets reported (for example, to Zipkin).

12.6 Host Locator

[Important]Important

This section is about defining host from service discovery. +}

The preceding example results in changing the name of the reported span to foo bar, just before it gets reported (for example, to Zipkin).

12.7 Host Locator

[Important]Important

This section is about defining host from service discovery. It is NOT about finding Zipkin through service discovery.

To define the host that corresponds to a particular span, we need to resolve the host name and port. The default approach is to take these values from server properties. If those are not set, we try to retrieve the host name from the network interfaces.

If you have the discovery client enabled and prefer to retrieve the host address from the registered instance in a service registry, you have to set the spring.zipkin.locator.discovery.enabled property (it is applicable for both HTTP-based and Stream-based span reporting), as follows:

spring.zipkin.locator.discovery.enabled: true
Prev   Next
11. Managing Spans with Annotations Home 13. Sending Spans to Zipkin
\ No newline at end of file diff --git a/2.1.x/multi/multi__integrations.html b/2.1.x/multi/multi__integrations.html index e810833df..5ef048bf0 100644 --- a/2.1.x/multi/multi__integrations.html +++ b/2.1.x/multi/multi__integrations.html @@ -73,9 +73,9 @@ You can configure which URIs you would like to skip by using the ManagementServerProperties on the classpath, its value of contextPath gets appended to the provided skip pattern. If you want to reuse Sleuth’s default skip patterns and append your own, pass those patterns by using the spring.sleuth.web.additionalSkipPattern.

To change the order of tracing filter registration, please set the spring.sleuth.web.filter-order property.

15.5.5 Dubbo RPC support

Via the integration with Brave, Spring Cloud Sleuth supports Dubbo. -It’s enough to add the brave-instrumentation-dubbo-rpc dependency:

<dependency>
+It’s enough to add the brave-instrumentation-dubbo dependency:
<dependency>
     <groupId>io.zipkin.brave</groupId>
-    <artifactId>brave-instrumentation-dubbo-rpc</artifactId>
+    <artifactId>brave-instrumentation-dubbo</artifactId>
 </dependency>
You need to also set a dubbo.properties file with the following contents:
dubbo.provider.filter=tracing
 dubbo.consumer.filter=tracing
You can read more about Brave - Dubbo integration here.
 An example of Spring Cloud Sleuth and Dubbo can be found here.

15.6 HTTP Client Integration

15.6.1 Synchronous Rest Template

We inject a RestTemplate interceptor to ensure that all the tracing information is passed to the requests. diff --git a/2.1.x/multi/multi_spring-cloud-sleuth.html b/2.1.x/multi/multi_spring-cloud-sleuth.html index bd0a5ecdc..424d0dd7f 100644 --- a/2.1.x/multi/multi_spring-cloud-sleuth.html +++ b/2.1.x/multi/multi_spring-cloud-sleuth.html @@ -1,3 +1,3 @@ - Spring Cloud Sleuth

Spring Cloud Sleuth
   Next

Spring Cloud Sleuth

Adrian Cole, Spencer Gibb, Marcin Grzejszczak, Dave Syer, Jay Bryant

Table of Contents

1. Introduction
1.1. Terminology
1.2. Purpose
1.2.1. Distributed Tracing with Zipkin
1.2.2. Visualizing errors
1.2.3. Distributed Tracing with Brave
1.2.4. Live examples
1.2.5. Log correlation
JSON Logback with Logstash
1.2.6. Propagating Span Context
Baggage versus Span Tags
1.3. Adding Sleuth to the Project
1.3.1. Only Sleuth (log correlation)
1.3.2. Sleuth with Zipkin via HTTP
1.3.3. Sleuth with Zipkin over RabbitMQ or Kafka
1.4. Overriding the auto-configuration of Zipkin
2. Additional Resources
3. Features
3.1. Introduction to Brave
3.1.1. Tracing
3.1.2. Local Tracing
3.1.3. Customizing Spans
3.1.4. Implicitly Looking up the Current Span
3.1.5. RPC tracing
One-Way tracing
4. Sampling
4.1. Declarative sampling
4.2. Custom sampling
4.3. Sampling in Spring Cloud Sleuth
5. Propagation
5.1. Propagating extra fields
5.1.1. Prefixed fields
5.1.2. Extracting a Propagated Context
5.1.3. Sharing span IDs between Client and Server
5.1.4. Implementing Propagation
6. Current Tracing Component
7. Current Span
7.1. Setting a span in scope manually
8. Instrumentation
9. Span lifecycle
9.1. Creating and finishing spans
9.2. Continuing Spans
9.3. Creating a Span with an explicit Parent
10. Naming spans
10.1. @SpanName Annotation
10.2. toString() method
11. Managing Spans with Annotations
11.1. Rationale
11.2. Creating New Spans
11.3. Continuing Spans
11.4. Advanced Tag Setting
11.4.1. Custom extractor
11.4.2. Resolving Expressions for a Value
11.4.3. Using the toString() method
12. Customizations
12.1. Customizers
12.2. HTTP
12.3. TracingFilter
12.4. Custom service name
12.5. Customization of Reported Spans
12.6. Host Locator
13. Sending Spans to Zipkin
14. Zipkin Stream Span Consumer
15. Integrations
15.1. OpenTracing
15.2. Runnable and Callable
15.3. Hystrix
15.3.1. Custom Concurrency Strategy
15.3.2. Manual Command setting
15.4. RxJava
15.5. HTTP integration
15.5.1. HTTP Filter
15.5.2. HandlerInterceptor
15.5.3. Async Servlet support
15.5.4. WebFlux support
15.5.5. Dubbo RPC support
15.6. HTTP Client Integration
15.6.1. Synchronous Rest Template
15.6.2. Asynchronous Rest Template
Multiple Asynchronous Rest Templates
15.6.3. WebClient
15.6.4. Traverson
15.6.5. Apache HttpClientBuilder and HttpAsyncClientBuilder
15.6.6. Netty HttpClient
15.6.7. UserInfoRestTemplateCustomizer
15.7. Feign
15.8. gRPC
15.8.1. Variant 1
Dependencies
Server Instrumentation
Client Instrumentation
15.8.2. Variant 2
15.9. Asynchronous Communication
15.9.1. @Async Annotated methods
15.9.2. @Scheduled Annotated Methods
15.9.3. Executor, ExecutorService, and ScheduledExecutorService
Customization of Executors
15.10. Messaging
15.10.1. Spring Integration and Spring Cloud Stream
15.10.2. Spring RabbitMq
15.10.3. Spring Kafka
15.10.4. Spring JMS
15.11. Zuul
16. Running examples
   Next
   
\ No newline at end of file + Spring Cloud Sleuth
Spring Cloud Sleuth
   Next

Spring Cloud Sleuth

Adrian Cole, Spencer Gibb, Marcin Grzejszczak, Dave Syer, Jay Bryant

Table of Contents

1. Introduction
1.1. Terminology
1.2. Purpose
1.2.1. Distributed Tracing with Zipkin
1.2.2. Visualizing errors
1.2.3. Distributed Tracing with Brave
1.2.4. Live examples
1.2.5. Log correlation
JSON Logback with Logstash
1.2.6. Propagating Span Context
Baggage versus Span Tags
1.3. Adding Sleuth to the Project
1.3.1. Only Sleuth (log correlation)
1.3.2. Sleuth with Zipkin via HTTP
1.3.3. Sleuth with Zipkin over RabbitMQ or Kafka
1.4. Overriding the auto-configuration of Zipkin
2. Additional Resources
3. Features
3.1. Introduction to Brave
3.1.1. Tracing
3.1.2. Local Tracing
3.1.3. Customizing Spans
3.1.4. Implicitly Looking up the Current Span
3.1.5. RPC tracing
One-Way tracing
4. Sampling
4.1. Declarative sampling
4.2. Custom sampling
4.3. Sampling in Spring Cloud Sleuth
5. Propagation
5.1. Propagating extra fields
5.1.1. Prefixed fields
5.1.2. Extracting a Propagated Context
5.1.3. Sharing span IDs between Client and Server
5.1.4. Implementing Propagation
6. Current Tracing Component
7. Current Span
7.1. Setting a span in scope manually
8. Instrumentation
9. Span lifecycle
9.1. Creating and finishing spans
9.2. Continuing Spans
9.3. Creating a Span with an explicit Parent
10. Naming spans
10.1. @SpanName Annotation
10.2. toString() method
11. Managing Spans with Annotations
11.1. Rationale
11.2. Creating New Spans
11.3. Continuing Spans
11.4. Advanced Tag Setting
11.4.1. Custom extractor
11.4.2. Resolving Expressions for a Value
11.4.3. Using the toString() method
12. Customizations
12.1. Customizers
12.2. HTTP
12.3. TracingFilter
12.4. RPC
12.5. Custom service name
12.6. Customization of Reported Spans
12.7. Host Locator
13. Sending Spans to Zipkin
14. Zipkin Stream Span Consumer
15. Integrations
15.1. OpenTracing
15.2. Runnable and Callable
15.3. Hystrix
15.3.1. Custom Concurrency Strategy
15.3.2. Manual Command setting
15.4. RxJava
15.5. HTTP integration
15.5.1. HTTP Filter
15.5.2. HandlerInterceptor
15.5.3. Async Servlet support
15.5.4. WebFlux support
15.5.5. Dubbo RPC support
15.6. HTTP Client Integration
15.6.1. Synchronous Rest Template
15.6.2. Asynchronous Rest Template
Multiple Asynchronous Rest Templates
15.6.3. WebClient
15.6.4. Traverson
15.6.5. Apache HttpClientBuilder and HttpAsyncClientBuilder
15.6.6. Netty HttpClient
15.6.7. UserInfoRestTemplateCustomizer
15.7. Feign
15.8. gRPC
15.8.1. Variant 1
Dependencies
Server Instrumentation
Client Instrumentation
15.8.2. Variant 2
15.9. Asynchronous Communication
15.9.1. @Async Annotated methods
15.9.2. @Scheduled Annotated Methods
15.9.3. Executor, ExecutorService, and ScheduledExecutorService
Customization of Executors
15.10. Messaging
15.10.1. Spring Integration and Spring Cloud Stream
15.10.2. Spring RabbitMq
15.10.3. Spring Kafka
15.10.4. Spring JMS
15.11. Zuul
16. Running examples
   Next
   
\ No newline at end of file diff --git a/2.1.x/single/spring-cloud-sleuth.html b/2.1.x/single/spring-cloud-sleuth.html index 92cf6e594..46c4544c9 100644 --- a/2.1.x/single/spring-cloud-sleuth.html +++ b/2.1.x/single/spring-cloud-sleuth.html @@ -1,6 +1,6 @@ - Spring Cloud Sleuth

Spring Cloud Sleuth

Adrian Cole, Spencer Gibb, Marcin Grzejszczak, Dave Syer, Jay Bryant

Table of Contents

1. Introduction
1.1. Terminology
1.2. Purpose
1.2.1. Distributed Tracing with Zipkin
1.2.2. Visualizing errors
1.2.3. Distributed Tracing with Brave
1.2.4. Live examples
1.2.5. Log correlation
JSON Logback with Logstash
1.2.6. Propagating Span Context
Baggage versus Span Tags
1.3. Adding Sleuth to the Project
1.3.1. Only Sleuth (log correlation)
1.3.2. Sleuth with Zipkin via HTTP
1.3.3. Sleuth with Zipkin over RabbitMQ or Kafka
1.4. Overriding the auto-configuration of Zipkin
2. Additional Resources
3. Features
3.1. Introduction to Brave
3.1.1. Tracing
3.1.2. Local Tracing
3.1.3. Customizing Spans
3.1.4. Implicitly Looking up the Current Span
3.1.5. RPC tracing
One-Way tracing
4. Sampling
4.1. Declarative sampling
4.2. Custom sampling
4.3. Sampling in Spring Cloud Sleuth
5. Propagation
5.1. Propagating extra fields
5.1.1. Prefixed fields
5.1.2. Extracting a Propagated Context
5.1.3. Sharing span IDs between Client and Server
5.1.4. Implementing Propagation
6. Current Tracing Component
7. Current Span
7.1. Setting a span in scope manually
8. Instrumentation
9. Span lifecycle
9.1. Creating and finishing spans
9.2. Continuing Spans
9.3. Creating a Span with an explicit Parent
10. Naming spans
10.1. @SpanName Annotation
10.2. toString() method
11. Managing Spans with Annotations
11.1. Rationale
11.2. Creating New Spans
11.3. Continuing Spans
11.4. Advanced Tag Setting
11.4.1. Custom extractor
11.4.2. Resolving Expressions for a Value
11.4.3. Using the toString() method
12. Customizations
12.1. Customizers
12.2. HTTP
12.3. TracingFilter
12.4. Custom service name
12.5. Customization of Reported Spans
12.6. Host Locator
13. Sending Spans to Zipkin
14. Zipkin Stream Span Consumer
15. Integrations
15.1. OpenTracing
15.2. Runnable and Callable
15.3. Hystrix
15.3.1. Custom Concurrency Strategy
15.3.2. Manual Command setting
15.4. RxJava
15.5. HTTP integration
15.5.1. HTTP Filter
15.5.2. HandlerInterceptor
15.5.3. Async Servlet support
15.5.4. WebFlux support
15.5.5. Dubbo RPC support
15.6. HTTP Client Integration
15.6.1. Synchronous Rest Template
15.6.2. Asynchronous Rest Template
Multiple Asynchronous Rest Templates
15.6.3. WebClient
15.6.4. Traverson
15.6.5. Apache HttpClientBuilder and HttpAsyncClientBuilder
15.6.6. Netty HttpClient
15.6.7. UserInfoRestTemplateCustomizer
15.7. Feign
15.8. gRPC
15.8.1. Variant 1
Dependencies
Server Instrumentation
Client Instrumentation
15.8.2. Variant 2
15.9. Asynchronous Communication
15.9.1. @Async Annotated methods
15.9.2. @Scheduled Annotated Methods
15.9.3. Executor, ExecutorService, and ScheduledExecutorService
Customization of Executors
15.10. Messaging
15.10.1. Spring Integration and Spring Cloud Stream
15.10.2. Spring RabbitMq
15.10.3. Spring Kafka
15.10.4. Spring JMS
15.11. Zuul
16. Running examples

2.1.5.BUILD-SNAPSHOT

1. Introduction

Spring Cloud Sleuth implements a distributed tracing solution for Spring Cloud.

1.1 Terminology

Spring Cloud Sleuth borrows Dapper’s terminology.

Span: The basic unit of work. For example, sending an RPC is a new span, as is sending a response to an RPC. + Spring Cloud Sleuth

Spring Cloud Sleuth

Adrian Cole, Spencer Gibb, Marcin Grzejszczak, Dave Syer, Jay Bryant

Table of Contents

1. Introduction
1.1. Terminology
1.2. Purpose
1.2.1. Distributed Tracing with Zipkin
1.2.2. Visualizing errors
1.2.3. Distributed Tracing with Brave
1.2.4. Live examples
1.2.5. Log correlation
JSON Logback with Logstash
1.2.6. Propagating Span Context
Baggage versus Span Tags
1.3. Adding Sleuth to the Project
1.3.1. Only Sleuth (log correlation)
1.3.2. Sleuth with Zipkin via HTTP
1.3.3. Sleuth with Zipkin over RabbitMQ or Kafka
1.4. Overriding the auto-configuration of Zipkin
2. Additional Resources
3. Features
3.1. Introduction to Brave
3.1.1. Tracing
3.1.2. Local Tracing
3.1.3. Customizing Spans
3.1.4. Implicitly Looking up the Current Span
3.1.5. RPC tracing
One-Way tracing
4. Sampling
4.1. Declarative sampling
4.2. Custom sampling
4.3. Sampling in Spring Cloud Sleuth
5. Propagation
5.1. Propagating extra fields
5.1.1. Prefixed fields
5.1.2. Extracting a Propagated Context
5.1.3. Sharing span IDs between Client and Server
5.1.4. Implementing Propagation
6. Current Tracing Component
7. Current Span
7.1. Setting a span in scope manually
8. Instrumentation
9. Span lifecycle
9.1. Creating and finishing spans
9.2. Continuing Spans
9.3. Creating a Span with an explicit Parent
10. Naming spans
10.1. @SpanName Annotation
10.2. toString() method
11. Managing Spans with Annotations
11.1. Rationale
11.2. Creating New Spans
11.3. Continuing Spans
11.4. Advanced Tag Setting
11.4.1. Custom extractor
11.4.2. Resolving Expressions for a Value
11.4.3. Using the toString() method
12. Customizations
12.1. Customizers
12.2. HTTP
12.3. TracingFilter
12.4. RPC
12.5. Custom service name
12.6. Customization of Reported Spans
12.7. Host Locator
13. Sending Spans to Zipkin
14. Zipkin Stream Span Consumer
15. Integrations
15.1. OpenTracing
15.2. Runnable and Callable
15.3. Hystrix
15.3.1. Custom Concurrency Strategy
15.3.2. Manual Command setting
15.4. RxJava
15.5. HTTP integration
15.5.1. HTTP Filter
15.5.2. HandlerInterceptor
15.5.3. Async Servlet support
15.5.4. WebFlux support
15.5.5. Dubbo RPC support
15.6. HTTP Client Integration
15.6.1. Synchronous Rest Template
15.6.2. Asynchronous Rest Template
Multiple Asynchronous Rest Templates
15.6.3. WebClient
15.6.4. Traverson
15.6.5. Apache HttpClientBuilder and HttpAsyncClientBuilder
15.6.6. Netty HttpClient
15.6.7. UserInfoRestTemplateCustomizer
15.7. Feign
15.8. gRPC
15.8.1. Variant 1
Dependencies
Server Instrumentation
Client Instrumentation
15.8.2. Variant 2
15.9. Asynchronous Communication
15.9.1. @Async Annotated methods
15.9.2. @Scheduled Annotated Methods
15.9.3. Executor, ExecutorService, and ScheduledExecutorService
Customization of Executors
15.10. Messaging
15.10.1. Spring Integration and Spring Cloud Stream
15.10.2. Spring RabbitMq
15.10.3. Spring Kafka
15.10.4. Spring JMS
15.11. Zuul
16. Running examples

2.1.5.BUILD-SNAPSHOT

1. Introduction

Spring Cloud Sleuth implements a distributed tracing solution for Spring Cloud.

1.1 Terminology

Spring Cloud Sleuth borrows Dapper’s terminology.

Span: The basic unit of work. For example, sending an RPC is a new span, as is sending a response to an RPC. Spans are identified by a unique 64-bit ID for the span and another 64-bit ID for the trace the span is a part of. Spans also have other data, such as descriptions, timestamped events, key-value annotations (tags), the ID of the span that caused them, and process IDs (normally IP addresses).

Spans can be started and stopped, and they keep track of their timing information. Once you create a span, you must stop it at some point in the future.

[Tip]Tip

The initial span that starts a trace is called a root span. The value of the ID @@ -723,32 +723,28 @@ Its class name has to be passed as the value of the resolv }

No custom implementation of a TagValueExpressionResolver leads to evaluation of the SPEL expression, and a tag with a value of 4 characters is set on the span. If you want to use some other expression resolution mechanism, you can create your own implementation of the bean.

11.4.3 Using the toString() method

Consider the following annotated method:

@NewSpan
 public void getAnnotationForArgumentToString(@SpanTag("test") Long param) {
-}

Running the preceding method with a value of 15 leads to setting a tag with a String value of "15".

12. Customizations

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

12.2 HTTP

If a customization of client / server parsing of the HTTP related spans is required, -just register a bean of type brave.http.HttpClientParser or +}

Running the preceding method with a value of 15 leads to setting a tag with a String value of "15".

12. Customizations

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

12.2 HTTP

If a customization of client / server parsing of the HTTP related spans is +required, just register a bean of type brave.http.HttpClientParser or brave.http.HttpServerParser. If client /server sampling is required, just -register a bean of type brave.http.HttpSampler and name the bean - sleuthClientSampler for client sampler and sleuthServerSampler for server sampler. - For your convenience the @ClientSampler and @ServerSampler - annotations can be used to inject the proper beans or to - reference the bean names via their static String NAME fields.

Check out Brave’s code to see an example of how to make a path-based sampler +register a bean of type brave.sampler.SamplerFunction<HttpRequest> and name +the bean sleuthHttpClientSampler for client sampler and +sleuthHttpServerSampler for server sampler.

For your convenience the @HttpClientSampler and @HttpServerSampler +annotations can be used to inject the proper beans or to reference the bean +names via their static String NAME fields.

Check out Brave’s code to see an example of how to make a path-based sampler https://github.com/openzipkin/brave/tree/master/instrumentation/http#sampling-policy

If you want to completely rewrite the HttpTracing bean you can use the SkipPatternProvider interface to retrieve the URL Pattern for spans that should be not sampled. Below you can see -an example of usage of SkipPatternProvider inside a server side, HttpSampler.

@Configuration
+an example of usage of SkipPatternProvider inside a server side, Sampler<HttpRequest>.
@Configuration
 class Config {
-  @Bean(name = ServerSampler.NAME)
-  HttpSampler myHttpSampler(SkipPatternProvider provider) {
+  @Bean(name = HttpServerSampler.NAME)
+  SamplerFunction<HttpRequest> myHttpSampler(SkipPatternProvider provider) {
   	Pattern pattern = provider.skipPattern();
-  	return new HttpSampler() {
-
-  		@Override
-  		public <Req> Boolean trySample(HttpAdapter<Req, ?> adapter, Req request) {
-  			String url = adapter.path(request);
-  			boolean shouldSkip = pattern.matcher(url).matches();
-  			if (shouldSkip) {
-  				return false;
-  			}
-  			return null;
+  	return request -> {
+  		String url = request.path();
+  		boolean shouldSkip = pattern.matcher(url).matches();
+  		if (shouldSkip) {
+  			return false;
   		}
+  		return null;
   	};
   }
 }

12.3 TracingFilter

You can also modify the behavior of the TracingFilter, which is the component that is responsible for processing the input HTTP request and adding tags basing on the HTTP response. @@ -778,10 +774,28 @@ You can customize the tags or modify the response headers by registering your ow chain.doFilter(request, response); } -}

12.4 Custom service name

By default, Sleuth assumes that, when you send a span to Zipkin, you want the span’s service name to be equal to the value of the spring.application.name property. +}

12.4 RPC

Sleuth automatically configures the RpcTracing bean which serves as a +foundation for RPC instrumentation such as gRPC or Dubbo.

If a customization of client / server sampling of the RPC traces is required, +just register a bean of type brave.sampler.SamplerFunction<RpcRequest> and +name the bean sleuthRpcClientSampler for client sampler and +sleuthRpcServerSampler for server sampler.

For your convenience the @RpcClientSampler and @RpcServerSampler +annotations can be used to inject the proper beans or to reference the bean +names via their static String NAME fields.

Ex. Here’s a sampler that traces 100 "GetUserToken" server requests per second. +This doesn’t start new traces for requests to the health check service. Other +requests will use the global sampling configuration.

@Configuration
+class Config {
+  @Bean(name = RpcServerSampler.NAME)
+  SamplerFunction<RpcRequest> myRpcSampler() {
+  	Matcher<RpcRequest> userAuth = and(serviceEquals("users.UserService"),
+  			methodEquals("GetUserToken"));
+  	return RpcRuleSampler.newBuilder()
+  			.putRule(serviceEquals("grpc.health.v1.Health"), Sampler.NEVER_SAMPLE)
+  			.putRule(userAuth, RateLimitingSampler.create(100)).build();
+  }
+}

For more, see https://github.com/openzipkin/brave/tree/master/instrumentation/rpc#sampling-policy

12.5 Custom service name

By default, Sleuth assumes that, when you send a span to Zipkin, you want the span’s service name to be equal to the value of the spring.application.name property. That is not always the case, though. There are situations in which you want to explicitly provide a different service name for all spans coming from your application. -To achieve that, you can pass the following property to your application to override that value (the example is for a service named myService):

spring.zipkin.service.name: myService

12.5 Customization of Reported Spans

Before reporting spans (for example, to Zipkin) you may want to modify that span in some way. +To achieve that, you can pass the following property to your application to override that value (the example is for a service named myService):

spring.zipkin.service.name: myService

12.6 Customization of Reported Spans

Before reporting spans (for example, to Zipkin) you may want to modify that span in some way. You can do so by using the FinishedSpanHandler interface.

In Sleuth, we generate spans with a fixed name. Some users want to modify the name depending on values of tags. You can implement the FinishedSpanHandler interface to alter that name.

The following example shows how to register two beans that implement FinishedSpanHandler:

@Bean
@@ -804,7 +818,7 @@ FinishedSpanHandler handlerTwo() {
 			return true; // keep this span
 		}
 	};
-}

The preceding example results in changing the name of the reported span to foo bar, just before it gets reported (for example, to Zipkin).

12.6 Host Locator

[Important]Important

This section is about defining host from service discovery. +}

The preceding example results in changing the name of the reported span to foo bar, just before it gets reported (for example, to Zipkin).

12.7 Host Locator

[Important]Important

This section is about defining host from service discovery. It is NOT about finding Zipkin through service discovery.

To define the host that corresponds to a particular span, we need to resolve the host name and port. The default approach is to take these values from server properties. If those are not set, we try to retrieve the host name from the network interfaces.

If you have the discovery client enabled and prefer to retrieve the host address from the registered instance in a service registry, you have to set the spring.zipkin.locator.discovery.enabled property (it is applicable for both HTTP-based and Stream-based span reporting), as follows:

spring.zipkin.locator.discovery.enabled: true

13. Sending Spans to Zipkin

By default, if you add spring-cloud-starter-zipkin as a dependency to your project, when the span is closed, it is sent to Zipkin over HTTP. @@ -907,9 +921,9 @@ You can configure which URIs you would like to skip by using the ManagementServerProperties on the classpath, its value of contextPath gets appended to the provided skip pattern. If you want to reuse Sleuth’s default skip patterns and append your own, pass those patterns by using the spring.sleuth.web.additionalSkipPattern.

To change the order of tracing filter registration, please set the spring.sleuth.web.filter-order property.

15.5.5 Dubbo RPC support

Via the integration with Brave, Spring Cloud Sleuth supports Dubbo. -It’s enough to add the brave-instrumentation-dubbo-rpc dependency:

<dependency>
+It’s enough to add the brave-instrumentation-dubbo dependency:
<dependency>
     <groupId>io.zipkin.brave</groupId>
-    <artifactId>brave-instrumentation-dubbo-rpc</artifactId>
+    <artifactId>brave-instrumentation-dubbo</artifactId>
 </dependency>
You need to also set a dubbo.properties file with the following contents:
dubbo.provider.filter=tracing
 dubbo.consumer.filter=tracing
You can read more about Brave - Dubbo integration here.
 An example of Spring Cloud Sleuth and Dubbo can be found here.

15.6 HTTP Client Integration

15.6.1 Synchronous Rest Template

We inject a RestTemplate interceptor to ensure that all the tracing information is passed to the requests. diff --git a/2.1.x/spring-cloud-sleuth.xml b/2.1.x/spring-cloud-sleuth.xml index e488ee9ee..7223c5a08 100644 --- a/2.1.x/spring-cloud-sleuth.xml +++ b/2.1.x/spring-cloud-sleuth.xml @@ -1555,35 +1555,32 @@ public void getAnnotationForArgumentToString(@SpanTag("test") Long param) {

HTTP -If a customization of client / server parsing of the HTTP related spans is required, -just register a bean of type brave.http.HttpClientParser or +If a customization of client / server parsing of the HTTP related spans is +required, just register a bean of type brave.http.HttpClientParser or brave.http.HttpServerParser. If client /server sampling is required, just -register a bean of type brave.http.HttpSampler and name the bean - sleuthClientSampler for client sampler and sleuthServerSampler for server sampler. - For your convenience the @ClientSampler and @ServerSampler - annotations can be used to inject the proper beans or to - reference the bean names via their static String NAME fields. +register a bean of type brave.sampler.SamplerFunction<HttpRequest> and name +the bean sleuthHttpClientSampler for client sampler and +sleuthHttpServerSampler for server sampler. +For your convenience the @HttpClientSampler and @HttpServerSampler +annotations can be used to inject the proper beans or to reference the bean +names via their static String NAME fields. Check out Brave’s code to see an example of how to make a path-based sampler https://github.com/openzipkin/brave/tree/master/instrumentation/http#sampling-policy If you want to completely rewrite the HttpTracing bean you can use the SkipPatternProvider interface to retrieve the URL Pattern for spans that should be not sampled. Below you can see -an example of usage of SkipPatternProvider inside a server side, HttpSampler. +an example of usage of SkipPatternProvider inside a server side, Sampler<HttpRequest>. @Configuration class Config { - @Bean(name = ServerSampler.NAME) - HttpSampler myHttpSampler(SkipPatternProvider provider) { + @Bean(name = HttpServerSampler.NAME) + SamplerFunction<HttpRequest> myHttpSampler(SkipPatternProvider provider) { Pattern pattern = provider.skipPattern(); - return new HttpSampler() { - - @Override - public <Req> Boolean trySample(HttpAdapter<Req, ?> adapter, Req request) { - String url = adapter.path(request); - boolean shouldSkip = pattern.matcher(url).matches(); - if (shouldSkip) { - return false; - } - return null; + return request -> { + String url = request.path(); + boolean shouldSkip = pattern.matcher(url).matches(); + if (shouldSkip) { + return false; } + return null; }; } } @@ -1621,6 +1618,33 @@ class MyFilter extends GenericFilterBean { }
+
+RPC +Sleuth automatically configures the RpcTracing bean which serves as a +foundation for RPC instrumentation such as gRPC or Dubbo. +If a customization of client / server sampling of the RPC traces is required, +just register a bean of type brave.sampler.SamplerFunction<RpcRequest> and +name the bean sleuthRpcClientSampler for client sampler and +sleuthRpcServerSampler for server sampler. +For your convenience the @RpcClientSampler and @RpcServerSampler +annotations can be used to inject the proper beans or to reference the bean +names via their static String NAME fields. +Ex. Here’s a sampler that traces 100 "GetUserToken" server requests per second. +This doesn’t start new traces for requests to the health check service. Other +requests will use the global sampling configuration. +@Configuration +class Config { + @Bean(name = RpcServerSampler.NAME) + SamplerFunction<RpcRequest> myRpcSampler() { + Matcher<RpcRequest> userAuth = and(serviceEquals("users.UserService"), + methodEquals("GetUserToken")); + return RpcRuleSampler.newBuilder() + .putRule(serviceEquals("grpc.health.v1.Health"), Sampler.NEVER_SAMPLE) + .putRule(userAuth, RateLimitingSampler.create(100)).build(); + } +} +For more, see https://github.com/openzipkin/brave/tree/master/instrumentation/rpc#sampling-policy +
Custom service name By default, Sleuth assumes that, when you send a span to Zipkin, you want the span’s service name to be equal to the value of the spring.application.name property. @@ -1857,10 +1881,10 @@ If you want to reuse Sleuth’s default skip patterns and append your own, p
Dubbo RPC support Via the integration with Brave, Spring Cloud Sleuth supports Dubbo. -It’s enough to add the brave-instrumentation-dubbo-rpc dependency: +It’s enough to add the brave-instrumentation-dubbo dependency: <dependency> <groupId>io.zipkin.brave</groupId> - <artifactId>brave-instrumentation-dubbo-rpc</artifactId> + <artifactId>brave-instrumentation-dubbo</artifactId> </dependency> You need to also set a dubbo.properties file with the following contents: dubbo.provider.filter=tracing