Most changes are not very interesting to sleuth, though the server is
quite a lot better with UI fixes galore. For sleuth mainly, small api
unaffecting glitch fixes around the Span.Builder.
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
Local Ip determined from spring.commons InetUtils.
To enable local endpoint resolution via service discovery, DiscoveryClient must be present and 'spring.zipkin.service.locator.discovery' should be set to true.
FallbackHavingEndpointLocator was caching and recreating EndpointLocator in the same time - removed the caching part.
Fixes gh-403
Local Ip determined from spring.commons InetUtils.
To enable local endpoint resolution via service discovery, DiscoveryClient must be present and 'spring.zipkin.service.locator.discovery' should be set to true.
FallbackHavingEndpointLocator was caching and recreating EndpointLocator in the same time - removed the caching part.
Fixes gh-403
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 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 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 only either service discovery service id / spring.application.name can be chosen as a service name for zipkin
with this change you can pass spring.zipkin.service.name property to change override that both for HTTP and Stream collectors
fixes#324
without this only either service discovery service id / spring.application.name can be chosen as a service name for zipkin
with this change you can pass spring.zipkin.service.name property to change override that both for HTTP and Stream collectors
fixes#324
without this only either service discovery service id / spring.application.name can be chosen as a service name for zipkin
with this change you can pass spring.zipkin.service.name property to change override that both for HTTP and Stream collectors
fixes#324
without this change Zipkin doesn't properly visualize the span on the server side.
with this change we're setting SA only if peer tag is set.
fixes#481
without this change Zipkin doesn't properly visualize the span on the server side.
with this change we're setting SA only if peer tag is set.
fixes#481
without this change Zipkin doesn't properly visualize the span on the server side.
with this change we're setting SA only if peer tag is set.
fixes#481
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
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.
This ensures spans that have remote set to true don't send
Span.timestamp/duration.
In the RPC span model, the client owns the timestamp and duration of the
span. If we were propagated an id, we can assume that we shouldn't
report timestamp or duration, rather let the client do that. Worst case
we were propagated an unreported ID and Zipkin backfills timestamp and
duration.
See https://github.com/openzipkin/openzipkin.github.io/issues/49
This ensures spans that have remote set to true don't send
Span.timestamp/duration.
In the RPC span model, the client owns the timestamp and duration of the
span. If we were propagated an id, we can assume that we shouldn't
report timestamp or duration, rather let the client do that. Worst case
we were propagated an unreported ID and Zipkin backfills timestamp and
duration.
See https://github.com/openzipkin/openzipkin.github.io/issues/49
This ensures spans that have remote set to true don't send
Span.timestamp/duration.
In the RPC span model, the client owns the timestamp and duration of the
span. If we were propagated an id, we can assume that we shouldn't
report timestamp or duration, rather let the client do that. Worst case
we were propagated an unreported ID and Zipkin backfills timestamp and
duration.
Now that Endpoint has ipv6, the factory method is even worse than it
was before. This switches to a builder instead.
Note: Endpoint now has a nice toString which should help debugging.
Now that Endpoint has ipv6, the factory method is even worse than it
was before. This switches to a builder instead.
Note: Endpoint now has a nice toString which should help debugging.
AsyncReporter is a more robust version of what we were doing before.
Notably, it can give a memory threshold instead of span count for the
backlog. This change ports to use AsyncReporter internally.
See https://github.com/openzipkin/zipkin-reporter-java#asyncreporter
AsyncReporter is a more robust version of what we were doing before.
Notably, it can give a memory threshold instead of span count for the
backlog. This change ports to use AsyncReporter internally.
See https://github.com/openzipkin/zipkin-reporter-java#asyncreporter
it turned out that some of the tests were leaky and didn't catch that ExceptionUtils were throwing an exception (race condition with Hystrix). That was due to the fact that When Hystrix with Feign were doing retries the RequestInterceptor wasn't called. That means that a new span wasn't created but a parent span was closed.
With this change the only place where the span creation and closing takes place is TraceFeignClient. I removed the Feign RequestInterceptor. Now whenever there is a retry - a new span is created and closed after getting a response. There are no exceptions, special cases etc.
In addition to that since Feign is fully immutable and SpanInjector is by design made to mutate objects I had to wrap the immutable Request in an AtomicReference in order to change the contents of the Request. I'm ashamed but didn't have a better idea. Since that is packaged scope nobody should every see that (outside the package of course)
it turned out that some of the tests were leaky and didn't catch that ExceptionUtils were throwing an exception (race condition with Hystrix). That was due to the fact that When Hystrix with Feign were doing retries the RequestInterceptor wasn't called. That means that a new span wasn't created but a parent span was closed.
With this change the only place where the span creation and closing takes place is TraceFeignClient. I removed the Feign RequestInterceptor. Now whenever there is a retry - a new span is created and closed after getting a response. There are no exceptions, special cases etc.
In addition to that since Feign is fully immutable and SpanInjector is by design made to mutate objects I had to wrap the immutable Request in an AtomicReference in order to change the contents of the Request. I'm ashamed but didn't have a better idea. Since that is packaged scope nobody should every see that (outside the package of course)
