This does two things: ensures samples don't use Zipkin v1 in any way,
and misaligns the version numbers of zipkin v1 and zipkin v2 apis.
This is an attempt to walk around the gradle plugin issue, which only
exists when someone is using both versions of zipkin.
See https://github.com/spring-projects/spring-boot/issues/10778
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 the child span of the HTTP filter span gets changed into a span coming from the Controller aspect. The name of the span becomes the name of the method.
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
Previously, sleuth logged more data than necessary. This led to issues
including spans approaching megabytes each. This pares down default keys
to a minimal set, but allows users to opt-into logging more by extending
`TraceFilter`.
- 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
Brave's span collector, which turned out to not be a great tool for
direct use. Brave internally creates spans before sending to its
collector, so validation is implicit. The flip side of this is using the
collector directly does not validate spans. This means it is easy to
send invalid ones, for example missing span names. The problem is more
difficult as the data is in binary (thrift).
This introduces HttpZipkinSpanReporter, which validates via zipkin-java
classes before sending on the wire. Moreover, this sends in json to make
debugging problems easier.
This does not fully remove the Brave dependency, as further work is
needed. Particularly, Brave is indirectly referenced in other code.
See https://github.com/openzipkin/zipkin-java/issues/68
See #98 (Reporter is an OpenTracing term)
It's not really necessary to use rabbit, but the existing tests
weren't really using the stream components at all because
zipkin spans were being collected by spring-cloud-sleuth-zipkin.
Recent versions of zipkin and brave operate with http instead of scribe.
This changes the implementation accordingly, as well adds a sampler to
the POST endpoint.
A notable impact is that we no longer require a collector process, as
the zipkin server's POST endpoint is a collector.
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).
