Spring Cloud Stream changed the names of the headers config
that we need to propagate headers in kafka (and other binders
that do not support headers natively).
Fixes gh-284
now instead of first passing all the spans from the queue to the list and then clearing it we're now draining it contents. If in the meantime any spans will arrive they will be rained at next passing
fixes#259
The FeignBeanPostProcessor was causing other things to misbehave
by forcing early instantiation of all its dependencies. One of those
is a @MessageEndpoint when Sleuth Stream is in use, and the annotation
wasn't being processed because the bean was processed too early.
* Fixed the HttpServlet extractors
(now the response can contain custom headers)
* Changed header names to be Zipkin compatible
* removed qualifiers and properties
* updated the docs
fixes#19
* TraceKeys -> moved to root
* TraceRunnable and TraceCallable moved to root
* Websockets moved as a subpackage of messaging
* created TraceMetricsAutoConfiguration in the metric package (thanks to this the TraeAutoConfiguration doesn't need any metric info)
What’s left?
* the remaining dependencies are related to everybody using events
* there are a couple of usages of NeverSample
Also allows us to actually create a PercentageBasedSampler (I
don't think anyone tried it before) without resorting to
lazy beans and proxies.
Another freature added here is a default percentage sampler
if we know that spans need to be exported (zipkin or stream
is present).
Fixes gh-138
It also turns out that there's a bug in Spring MVC which makes an
empty header blow up in RequestHeaderMapMethodArgumentResolver
so we set the header to "true" instead of empty.
Fixes gh-136
Changes following review
- Reusing CounterService to automatically profit from Dropwizard if present
- NoOp is the default impl for SpanReporterService
- SpanReporterService has configurable metric names (it's enough to change the
name to 'meter.a.b.c' to profit from Dropwizard's meters)
Fixes gh-99
- Changed Random instantiation to a shared Random
- Changed the name of the converter
- Changed generator into random
- Span id is now non-nullable.
- it gets generated in the http filter if it's not there
- it's generated in the spring-integration channels if it wasn't set
Missing service name:
Zipkin service names were logged as null, which is invalid and led to
them showing up as "unknown" in the zipkin ui. This was due to a wiring
bug, and a special-case, which this change fixes.
The special-case was when a sleuth span had no annotations. Since zipkin
service names are attached to annotations, they are only queryable when
annotations exist. When there are no annotations, we add the "lc"
binary annotation, which makes that span attached to the correct service
in zipkin.
Polishing:
Zipkin timestamps were not always set as microseconds. This fixes that.
The de-facto label in zipkin for unknown service is "unknown". This
fixes the code, which formerly fell back to "application".
This also removes complexity in assigning timestamp and duration as we
no longer need to make pseudo-annotations "acquire" and "release".
Finally, this adds tests about above consistently to both scs-zipkin and
scs-zipkin-stream.
If the flag is set then annotations are collected and the data are exported
in zipkin or stream. If not you still get the correlation ids, so a purely
log-oriented solution will always have useful data on all requests.
Instrumentation should be able to get by with only 2
interfaces: TraceManager and TraceAccessor (the former is
not needed if you aren't starting a new Span). No explicit
access to thread locals or manipulation of thread context
is required (except locally where necessary).
A Span is enclosed by a Trace (actually a view of the complete
Trace that would be constructed remotely).
