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
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
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.
* Use StreamListener for coercing messages from JSON `Span`
Rely on the `contentType` header of the transported message to
tell Spring Cloud Stream how to coerce the message to `Span`.
Formerly, `Span.getAccumulatedMillis()` worked, but could returns
imprecise measurements, particularly local spans. This changes the
internals of Span to keep track of a start tick. Using this, it can
return a more precise `Span.getAccumulatedMicros()`.
To ensure this precision isn't lost in serialization, this adds a
json field `durationMicros`, which is only set when the span is stopped.
This is set instead of start tick because `System.nanoTime()` is JVM
specific and so cannot be used across the network. `durationMicros` uses
null instead of zero comparisons because nano time can be negative.
Fixes#312
This moves to changes made in preparation of zipkin 1.0.
Here are the notables:
* Zipkin has autoconfiguration modules, where maven artifacts have the prefix 'zipkin-autoconfigure-X'
* Zipkin's ui now shares a version with everything else
* Zipkin now namespaces packages and configuration. ex zipkin.storage.X as opposed to zipkin.X
* All autoconfiguration classes are prefixed `Zipkin` to be easier to find
* Zipkin binds components like StorageComponent, as opposed to individual classes like SpanStore.
* Health checks are under the scope "zipkin" and broken down by component
* UI responsiveness is better by conditionally caching names queries for 5 minutes
* New `Collector` class, which makes logging and metrics patterns the same regardless of transport
