You can also modify the behavior of the TraceFilter, which is the component that is responsible for processing the input HTTP request and adding tags basing on the HTTP response.
+
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 +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 +class Config { + @Bean(name = ServerSampler.NAME) + HttpSampler 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; + } + }; + } +}
You can also modify the behavior of the TraceFilter, which is the component that is responsible for processing the input HTTP request and adding tags basing on the HTTP response.
You can customize the tags or modify the response headers by registering your own instance of the TraceFilter bean.
In the following example, we register the TraceFilter bean, add the ZIPKIN-TRACE-ID response header containing the current Span’s trace id, and add a tag with key custom and a value tag to the span.
@Component @Order(TraceWebServletAutoConfiguration.TRACING_FILTER_ORDER + 1) class MyFilter extends GenericFilterBean { @@ -25,10 +52,10 @@ You can customize the tags or modify the response headers by registering your ow currentSpan.tag("custom", "tag"); chain.doFilter(request, response); } -}
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.
+}
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: myServiceBefore 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: myServiceBefore reporting spans (for example, to Zipkin) you may want to modify that span in some way.
You can do so by using the SpanAdjuster interface.
In Sleuth, we generat spans with a fixed name.
Some users want to modify the name depending on values of tags.
You can implement the SpanAdjuster interface to alter that name.
The following example shows how to register two beans that implement SpanAdjuster:
@Bean SpanAdjuster adjusterOne() {
@@ -37,7 +64,7 @@ You can implement the SpanAdjuster interface to alt
@Bean SpanAdjuster adjusterTwo() {
return span -> span.toBuilder().name(span.name() + " bar").build();
-}The preceding example results in changing the name of the reported span to foo bar, just before it gets reported (for example, to Zipkin).
![[Important]](images/important.png) | Important | ||
|---|---|---|---|
This section is about defining host from service discovery. +} The preceding example results in changing the name of the reported span to
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: true Table of Contents
Table of Contents
|