Sometimes you want to create a manual Span that will wrap a call to an external service which is not instrumented.
What you can do is to create a span with the peer.service tag that will contain a value of the service that you want to call.
-Below you can see an example of a call to Redis that is wrapped in such a span.
org.springframework.cloud.sleuth.Span newSpan = tracer.createSpan("redis"); -try { - newSpan.tag("redis.op", "get"); - newSpan.tag("lc", "redis"); - newSpan.logEvent(org.springframework.cloud.sleuth.Span.CLIENT_SEND); - // call redis service e.g - // return (SomeObj) redisTemplate.opsForHash().get("MYHASH", someObjKey); -} finally { - newSpan.tag("peer.service", "redisService"); - newSpan.tag("peer.ipv4", "1.2.3.4"); - newSpan.tag("peer.port", "1234"); - newSpan.logEvent(org.springframework.cloud.sleuth.Span.CLIENT_RECV); - tracer.close(newSpan); -}
![[Important]](images/important.png) | Important |
|---|---|
Remember not to add both |
By default Sleuth assumes that when you send a span to Zipkin, you want the span’s service name +Below you can see an example of a call to Redis that is wrapped in such a span.
Unresolved directive in spring-cloud-sleuth.adoc - include::../../../..//spring-cloud-sleuth-zipkin-legacy/src/test/java/org/springframework/cloud/sleuth/zipkin/HttpZipkinSpanReporterTest.java[tags=service_name,indent=0] | Important |
|---|---|
Remember not to add both |
By default Sleuth assumes that when you send a span to Zipkin, you want the span’s service name
to be equal to spring.application.name value. That’s 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 it’s enough to just pass the following property
diff --git a/multi/multi__integrations.html b/multi/multi__integrations.html
index 6f1b580fe..94def53ee 100644
--- a/multi/multi__integrations.html
+++ b/multi/multi__integrations.html
@@ -56,7 +56,10 @@ of regular expressions in the spring.sleuth.rxjava.schedul
TraceHandlerInterceptor adds a special request attribute to the given HttpServletRequest. If the
the TraceFilter doesn’t see this attribute set it will create a "fallback" span which is an additional
span created on the server side so that the trace is presented properly in the UI. Seeing that most likely
- signifies that there is a missing instrumentation. In that case please file an issue in Spring Cloud Sleuth.
If your controller returns a Callable or a WebAsyncTask Spring Cloud Sleuth will continue the existing span instead of creating a new one.
We’re injecting a RestTemplate interceptor that ensures that all the tracing information is passed to the requests. Each time a
+ signifies that there is a missing instrumentation. In that case please file an issue in Spring Cloud Sleuth.
If your controller returns a Callable or a WebAsyncTask Spring Cloud Sleuth will continue the existing span instead of creating a new one.
Via the TraceWebFilter all sampled incoming requests result in creation of a Span. That Span’s name is http: + the path to which
+ the request was sent. E.g. if the request was sent to /foo/bar then the name will be http:/foo/bar. You can configure which URIs you would
+ like to skip via the spring.sleuth.web.skipPattern property. If you have ManagementServerProperties on classpath then
+ its value of contextPath gets appended to the provided skip pattern.
We’re injecting a RestTemplate interceptor that ensures that all the tracing information is passed to the requests. Each time a
call is made a new Span is created. It gets closed upon receiving the response. In order to block the synchronous RestTemplate features
just set spring.sleuth.web.client.enabled to false.
| Important |
|---|---|
You have to register |
| Important | ||||||||
|---|---|---|---|---|---|---|---|---|---|
A traced version of an If you’re using the Traverson library
+} We inject a You have to register If you’re using the Traverson library
it’s enough for you to inject a You can accumulate and send span data over
+ The suggested approach is to use the Zipkin’s
+native support for message based span sending. Starting from
+Edgware Zipkin Stream server is deprecated and in Finchley
+it got removed. You can accumulate and send span data over
Spring Cloud Stream by
including the There is a special convenience annotation for setting up a message consumer
-for the Span data and pushing it into a Zipkin will listen for the Span data on whatever transport you provide via a
-Spring Cloud Stream Then you’ll have your app a
-Zipkin server, which hosts
-the UI and api on port 9411. The default The A custom consumer can also easily be implemented using
+type Please refer to the Dalston Documentaion
+on how to create a Stream Zipkin server. That approach has been
+deprecated in Edgware and removed in Finchley release. A custom consumer can also easily be implemented using
Table of Contents Table of Contents |
![[Note]](images/note.png)