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.
Still not quite working:
$ docker-compose -f docker-compose.yml -f docker-compose.zipkin.yml up
everything starts up fine (once the database is initialized), but
the zipkin server is not listening to rabbit (and there are errors
in the logs).
@EnableZipkinStreamServer and bind to a Spring Cloud Stream message
broker. That's it. The default span store is in memory, but Zipkin
also supports MySQL (and Cassandra coming soon).
The TraceManager.detach() method should be called by wrapper
tasks submitted to background threads. This change fixes it
in TraceCallable and TraceRunnable. Possibly still some work
to do for Hystrix.
The "detached" flag didn't seem to be doing anything, so I
removed it in the process.
Fixes gh-64, fixes gh-61
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).
