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
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
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
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
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
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
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.
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.
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.
Backport of #450
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.
Backport of #450
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 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 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
