without this change there's a problem with the time when the SS is set on a span. Currently it's done in TraceFilter's finally block. The problem is that this code is executed after the response has been sent back to the client. Thus CR sometimes was set faster than SS (it doesn't make any sense from the logical point of view).
with this change we're introducing wrappers over the HttpServletResponse where we annotate the span with SS just after the response gets sent to the recipient.
fixes#492#431
without this change you couldn't register your own client (for example to set your ssl config) for Sleuth to reuse it
with this change we're reusing a registered feign client bean or creating a default one if necessary
fixes#502
* Add a new log method that allows for setting the time
* Clarify with time unit
* Simple test and spelling correction
* Consolidate "logic" and add a test for the other log method
without this change it's pretty much impossible to enforce sampling for certain traces
with this change setting the X-B3-Flags to 1 for HTTP messages / spanFlags to 1 for messaging will override any sampling decisions
fixes#496
without this tag it's impossible to discern from which server was the given span originated
with this change we're adding a tag in which we're passing the instance id value. The value can be taken either from Cloud Foundry or from a concatanation of some local properties like instance_id / application name / application port etc.
fixes#369
without this change the non web apps can't start
with this change the missing bean gets registered
also in terms of non boot apps if there is no port or address set we're providing some default values. In terms of the service name one can always use the override via the spring.zipkin.service.name property
fixes#32
without this change during asynchronous communication some components are trying to detach or close spans that were aready detached. This leads to exceptions utils warnings and spans were not closed.
with this change we're adding additional checks to ensure that we're tracing
fixes#447
without this change we have 2 different properties. One is `spring.sleuth.metric` and the other is `spring.sleuth.metrics`.
with this change we're introducing conditionality on `spring.sleuth.metric.enabled`
fixes#477
without this change an explicit new span is created on the server side. Its name is equal to the method name of the controller. It introduces some nice advantages in terms of readability of trace.
with this change we're continuing a previous span on the server side. We're attaching the tags and logs to that span with information about controller class and controller name. Also events related to start and finish of the controller are there.
fixes#471#469#427
With this change we change the approach to continue spans (if they already exist) instead of starting new ones. The RPC spans would still be generated but Hystrix, Async, Callables / Runnables will reuse an existing span if there is one.
the scenarios are as follows:
Assuming that we have a trace X with span Y
* if you used tracer.wrap(Callable) or trace.wrap(Runnable) then:
* previously you'd get a span Z created when the Callable / Runnable is executed
* with this change you'll continue the span Y
* if you used a HystrixCommand then
* previously you'd get a span Z together with added tags when the command got executed
* with this change you'll continue the span Y and the tags will be added to span Y
* if you used a ExecutorService then
* previously you'd get a span Z together with added tags when a method from ExecutorService got executed
* with this change you'll continue the span Y and the tags will be added to span Y
Assuming that there was no span then everything will work as previously.
In order to create a new span you just have to create it manually. Example of creating a new span for an `@Async` annotated method.
```
// obviously you should inject via constructor ;)
@Autowired Tracer tracer;
@Async
public Future<String> foo() {
Span span = tracer.createSpan("newSpan");
try {
// do your stuff
} finally {
this.tracer.close(span);
}
}
```
fixes#174
Provides custom HTTP status codes support
without this change applications using custom HTTP status codes are currently having issues with Spring Cloud Sleuth. TraceFilter.httpStatusSuccessful() is throwing an IllegalArgumentException on HttpStatus.valueOf(response.getStatus()).
with this change that gets fixed
without this change tracing worked fine but the custom types were not registered as beans. Thus autowiring of them was not possible
with this change the bean post processor is removed and an aspect is used - that way tracing is still working fine but we don't interfere in bean registration
fixes#445
This supports 128-bit traces via a new field traceIdHigh, which matches
other zipkin implementations. In encoded form, the trace ID is simply
twice as long (32 hex characters).
With this change in, a 128-bit trace propagated will not be downgraded
to 64-bits when sending downstream, reporting to Zipkin or adding to
the logging context.
This will be followed by a change to support initiating 128-bit traces.
Before, we were using variable encoding for trace and span identifiers.
This complicates search for those who are copy/pasting fixed-length IDs
provisioned upstream. This moves to standard formatting, while
maintaining tolerant reads.
The code added will also be used to support 128-bit (32 char) trace IDs.
Fixes#449
without this change there is no support for context propagation
with this change whenever you pass the `baggage-...` for http or `baggage_` for messaging headers then such a value will be propagated through your system
fixes#237
without this change ExecutorService was treated as an Executor and wrapped in the Executor bean. Due to this the bean was missing / bean of invalid type was registered.
with this change we do not wrap ExecutorService with a Executor bean, instead we wrap it in a TraceableExecutorService representation.
fixes#445
without this change we had to treat every mean of injecting and extracting span information separately
with this change all means of communications are abstracted. That way you configure things once only.
part of #237
without this change when you disable Sleuth web client the context fails to load
with this change it's working fine. We've moved beans around + the async web client will be turned off automatically if the sync one is also disabled
fixes#433
without this change there's no error colouring on Zipkin side
with this change we set error tags
- whenever there is an exception thrown on the server side (5xx)
- wheneber on the client side it's impossible to send a message
fixes#384
without this example it might be misleading for users how to work with callables and custom executors.
with this example we're showing both the case when you're using a custom executor (in this case you just have to register it as a bean and then use that bean in your callable); and also we show an example of how to reuse the taskScheduler one (it's enough to wrap it with LazyTraceExecutor).
fixes#423
without this change any exception occurring while creating a span will be swallowed.
with this change we're propagating the exception so that it gets handled properly.
fixes#426
without this change if the users sends invalid headers then exceptions are thrown.
with this change extractors catch the exception, log it and then a new span is created. That of course will lead to an invalid trace graph cause a new trace will be created but at least business apps will not be broken due to an issue in instrumentation.
fixes#425
When wrapping a ThreadPoolTaskExecutor in a bean postprocessor
we should take care that the delegate gets the lifecycle callbacks
from the container. Otherwise when it is first used, the thread pool
will not have been initialized, resulting in an exception.
(Can't believe this ever actually worked)
Some components in Spring assume (perhaps wrongly) that a channel
interceptor will not convert a mutable message into an immutable
one, and they continue to modify the headers dowstream. We can
dosge the issue of whether this is right or wrong by keeping the
message headers mutable, just in case.
It would probably be better to refactor the SpanInjector so that
it works with something other than the MessageBuilder, but we can
defer doing that in favour of this smaller change that works.
Adds a test for mutability. Also tested with the
gs-messaging-stomp-websocket guide from spring.io.
Fixes gh-276
