-
Notifications
You must be signed in to change notification settings - Fork 288
Conversation
Codecov Report
@@ Coverage Diff @@
## master #310 +/- ##
=========================================
+ Coverage 87.15% 87.4% +0.25%
=========================================
Files 54 57 +3
Lines 2965 3065 +100
=========================================
+ Hits 2584 2679 +95
- Misses 269 273 +4
- Partials 112 113 +1
Continue to review full report at Codecov.
|
33f6d59
to
7df0db7
Compare
Thanks for the PR! I'll take a look in a bit |
I'm curious, are you currently using jaeger client with a zipkin backend so that you can use the opentracing api? |
Yes, the current relationship between Zipkin and Opentracing is pretty tenuous (e.g. opentracing/opentracing.io#258) and we'd rather use a tracer that is fully committed to OpenTracing for the long run, even though Zipkin does have an opentracing wrapper available. |
Understood, I'm gonna have to play around this a bit because I'd rather not have the github.com/openzipkin/zipkin-go dependency pulled in for everyone using this client. If we could somehow vendor the github.com/openzipkin/zipkin-go dependency so that it's only pulled in if you configure the tracer to use the zipkin reporter then we'll be golden. |
@keitwb why not use Jaeger as the backend too? Operation reasons or features? |
) | ||
|
||
// BuildZipkinV2Span converts a Jaeger span to a Zipkin v2 span | ||
func BuildZipkinV2Span(span *Span) *zipkinModel.SpanModel { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
is there a way to stash these files under zipkin/
package? We don't want to increase the footprint of the client for users who only use it with non-zipkin parts
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The only way I see to be able to move it to the zipkin
package is to add several accessor methods on the jaeger Span struct that we need to do the conversion (e.g. logs, duration, tags are all unexported fields of Span
).
Doesn't seem too hard to pull off, but I'm not sure if it is ok to augment the public interface of the Span struct so much.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@black-adder I think this would also allow the zipkin-go lib to be only pulled in if projects were using code from the zipkin subpackage (at least this is my understanding of how glide/dep work).
utils/utils.go
Outdated
@@ -75,6 +75,13 @@ func PackIPAsUint32(ip net.IP) uint32 { | |||
return 0 | |||
} | |||
|
|||
// UnpackUint32AsIP does the reverse of PackIPAsUint32 | |||
func UnpackUint32AsIP(ip uint32) net.IP { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
please move new functions to internal/utils.go. we don't want to be adding more public methods that are not part of the client API.
@yurishkuro As far as why we don't use Jaeger on the backend, it's more just a matter that we got established with Zipkin a while back and it suits our purposes well enough so far. I wasn't part of the team that originally chose Zipkin over the other backends so I can't speak to why they chose it in the first place. We really like the OpenTracing initiative though and are sorry to see that Zipkin seems to be moving away from it. |
zipkin_v2_span.go
Outdated
kind = zipkinModel.Consumer | ||
} | ||
default: | ||
tags[string(tag.key)] = stringify(tag.value) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
unnecessary conversion
zipkin_v2_span.go
Outdated
kind = zipkinModel.Consumer | ||
} | ||
default: | ||
tags[string(tag.key)] = stringify(tag.value) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
unnecessary conversion
This reporter wraps an instance of a Zipkin reporter, which closely matches the interface for Jaeger reporters, so the adaptation is very simple. Most of the complexity lies in converting from a Jaeger span to a Zipkin v2 span. The existing Zipkin v1 Thrift code is left untouched. Signed-off-by: Ben Keith <[email protected]>
Signed-off-by: Ben Keith <[email protected]>
Signed-off-by: Ben Keith <[email protected]>
Signed-off-by: Ben Keith <[email protected]>
Expands span reporter selection by breaking out Reporter into base QueueReporter class and using reporting method-specific ThriftReporter and ZipkinV2Reporter. Also breaks LocalAgentSender into two classes including LocalAgentReader for ThriftReporter only usage of TBufferedTransport. These changes allow users to continue reporting spans oob to the local jaeger-agent but with the option of reporting to Zipkin backend. In the spirit of jaegertracing/jaeger-client-java#399 and jaegertracing/jaeger-client-go#310 Signed-off-by: Ryan Fitzpatrick <[email protected]>
Expands span reporter selection by breaking out Reporter into base QueueReporter class and using reporting method-specific ThriftReporter and ZipkinV2Reporter. Also breaks LocalAgentSender into two classes including LocalAgentReader for ThriftReporter only usage of TBufferedTransport. These changes allow users to continue reporting spans oob to the local jaeger-agent but with the option of reporting to Zipkin backend. In the spirit of jaegertracing/jaeger-client-java#399 and jaegertracing/jaeger-client-go#310 Signed-off-by: Ryan Fitzpatrick <[email protected]>
Expands span reporter selection by breaking out Reporter into base QueueReporter class and using reporting method-specific ThriftReporter and ZipkinV2Reporter. Also breaks LocalAgentSender into two classes including LocalAgentReader for ThriftReporter only usage of TBufferedTransport. These changes allow users to continue reporting spans oob to the local jaeger-agent but with the option of reporting to Zipkin backend. In the spirit of jaegertracing/jaeger-client-java#399 and jaegertracing/jaeger-client-go#310 Signed-off-by: Ryan Fitzpatrick <[email protected]>
Expands span reporter selection by breaking out Reporter into base QueueReporter class and using reporting method-specific ThriftReporter and ZipkinV2Reporter. Also breaks LocalAgentSender into two classes including LocalAgentReader for ThriftReporter only usage of TBufferedTransport. These changes allow users to continue reporting spans oob to the local jaeger-agent but with the option of reporting to Zipkin backend. In the spirit of jaegertracing/jaeger-client-java#399 and jaegertracing/jaeger-client-go#310 Signed-off-by: Ryan Fitzpatrick <[email protected]>
Expands span reporter selection by breaking out Reporter into base QueueReporter class and using reporting method-specific ThriftReporter and ZipkinV2Reporter. Also breaks LocalAgentSender into two classes including LocalAgentReader for ThriftReporter only usage of TBufferedTransport. These changes allow users to continue reporting spans oob to the local jaeger-agent but with the option of reporting to Zipkin backend. In the spirit of jaegertracing/jaeger-client-java#399 and jaegertracing/jaeger-client-go#310 Signed-off-by: Ryan Fitzpatrick <[email protected]>
We can solve our use-case by using the Jaeger HTTP transport added in #161. I'll leave the branch on our repo for a bit in case anybody else finds it useful but am closing this PR for now. |
Which problem is this PR solving?
Short description of the changes
This reporter wraps an instance of a Zipkin reporter, which closely
matches the interface for Jaeger reporters, so the adaptation is very
simple.
Most of the complexity lies in converting from a Jaeger span to a Zipkin
v2 span.
The existing Zipkin v1 Thrift code is left untouched.