-
Notifications
You must be signed in to change notification settings - Fork 113
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add gRPC client handler. #95
Conversation
/cc @adriancole for ramen tracking |
/cc @adriancole <https://github.com/adriancole> for ramen tracking
ramen++
|
middleware/grpc/client.go
Outdated
name := spanName(rti) | ||
span, ctx := c.tracer.StartSpanFromContext(ctx, name, zipkin.Kind(model.Client)) | ||
md, ok := metadata.FromOutgoingContext(ctx) | ||
if !ok { |
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.
nit pick, what about doing it the other way around? if ok { } else { }
middleware/grpc/client.go
Outdated
// TagRPC implements per-RPC context management. | ||
func (c *clientHandler) TagRPC(ctx context.Context, rti *stats.RPCTagInfo) context.Context { | ||
name := spanName(rti) | ||
span, ctx := c.tracer.StartSpanFromContext(ctx, name, zipkin.Kind(model.Client)) |
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.
Me again being nit picker but I believe we could make this more readable by declaring the type of the variable span
before so we do:
span, ctx = c.tracer.StartSpanFromContext(ctx, name, zipkin.Kind(model.Client))
and then it is clear we override ctx
. What do you think?
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.
Nit picks are welcome :)
thanks for kick-starting this! One overview comment I'd make is it is probably more helpful to have a name and tagging policy similar to brave (very conservative) vs otherwise as each tag and annotation eat index. https://github.com/openzipkin/brave/blob/master/instrumentation/grpc/src/test/java/brave/grpc/ITTracingClientInterceptor.java#L209 you might notice in brave that we have this XXParser thing which allows people to add anything else they want.. crazy enough some people tag the full bodies sometimes! |
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.
I was so focused on the other golang tracing libraries for inspiration I forgot to check Brave itself indeed. Made it so the tags are the same between the two (only error code tags).
Also took the liberty of adding a testing framework since it made it much easier for me to write them to get better test coverage, hope it's ok.
middleware/grpc/client.go
Outdated
// TagRPC implements per-RPC context management. | ||
func (c *clientHandler) TagRPC(ctx context.Context, rti *stats.RPCTagInfo) context.Context { | ||
name := spanName(rti) | ||
span, ctx := c.tracer.StartSpanFromContext(ctx, name, zipkin.Kind(model.Client)) |
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.
Nit picks are welcome :)
Hmm - was expecting adding the build tag to allow this to work on 1.8, but I think the lack of vendor directory might be causing issues (I believe Before digging more, just wondering if removing support for 1.8 is on the table, then don't have to worry :) |
I’m not ready to give up on 1.8. |
Ok no worries. Took some effort but got it to build on 1.8
I feel sorry for anyone that still has to use 1.8 in production 😮 |
I'll take a look... don't like the idea of having to include a vendor dir here... |
I've inspected the landscape... to make the support burden on us all lower we should drop the 1.8 support for zipkin-go... If people need to stick with 1.8 our latest release will have to do. @anuraaga thanks for the hard work and sorry for making you go through the pain of supporting 1.8. Looking at this it is just not worth it anymore. Can you revert the alterations you needed to do for 1.8? |
137a7bc
to
02d7a8a
Compare
Thanks @basvanbeek - I have removed 1.8 from the build too |
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.
Some minor nits about dot imports, for the rest LGTM.
middleware/grpc/client_test.go
Outdated
"google.golang.org/grpc/stats" | ||
|
||
"github.com/openzipkin/zipkin-go" | ||
. "github.com/openzipkin/zipkin-go/middleware/grpc" |
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.
Can you remove the dot imports?
I'd rather not have them in the code. Rather be verbose prefixing the functions with the package they came from so outsiders understand what method is being called and from which dependency.
middleware/grpc/grpc_suite_test.go
Outdated
"net" | ||
"testing" | ||
|
||
. "github.com/onsi/ginkgo" |
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.
No dot imports, see above.
Thanks - removed the dot imports |
Thanks @anuraaga are you planing on adding a gRPC server interceptor too? |
Yup - hoping to knock it out tomorrow |
Cool... if you can update the Readme gRPC section with the upcoming PR that would be great! |
Mostly inspired by https://github.com/census-instrumentation/opencensus-go/blob/master/plugin/ocgrpc/trace_common.go
When comparing to the httpclient tracing, the main difference is I didn't add a
ClientTags
function since I couldn't see where those default tags were used. And I guess it's generally better to add default tags to the tracer? Not sure - welcome any feedback :)