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.
- Merge branch 'master' of https://github.com/gauravrmazra/spring-cloud-sleuth into gauravrmazra-master
- Test scope removed for dependency. Needed for stomp message interceptor support
- Removed unused import from integration test
- Integration tests for TraceStompMessageContextChannelInterceptor
- Refactored code and added integration test for TraceStompMessageChannelInterceptor
- Fix for method which was not available in jdk1.7
- Fix build fail error due to new changes for stomp messages
- Support for STOMP messages over websocket
When a controller throws an exception the servlet container will
eventually set the response status to 500, but it is still 200
generally when the filter chain finishes, unless we catch the
exception and do something with it.
Fixes gh-57
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.
