Skip to content
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

Merged
merged 16 commits into from
Nov 30, 2018
Merged

Conversation

anuraaga
Copy link
Contributor

@anuraaga anuraaga commented Nov 23, 2018

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 :)

@anuraaga
Copy link
Contributor Author

/cc @adriancole for ramen tracking

@coveralls
Copy link

coveralls commented Nov 23, 2018

Coverage Status

Coverage decreased (-2.6%) to 72.26% when pulling f146583 on anuraaga:grpc-client into 2eebe2a on openzipkin:master.

@codefromthecrypt
Copy link
Member

codefromthecrypt commented Nov 23, 2018 via email

name := spanName(rti)
span, ctx := c.tracer.StartSpanFromContext(ctx, name, zipkin.Kind(model.Client))
md, ok := metadata.FromOutgoingContext(ctx)
if !ok {
Copy link
Contributor

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 { }

// 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))
Copy link
Contributor

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?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit picks are welcome :)

@codefromthecrypt
Copy link
Member

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
https://github.com/openzipkin/brave/blob/master/instrumentation/grpc/src/test/java/brave/grpc/ITTracingServerInterceptor.java#L240

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!

Copy link
Contributor Author

@anuraaga anuraaga left a 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.

// 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))
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit picks are welcome :)

@anuraaga
Copy link
Contributor Author

anuraaga commented Nov 25, 2018

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 go get does not care about build tags, and it'd be stabler and faster for the builds to use a vendor directory and not call go get).

Before digging more, just wondering if removing support for 1.8 is on the table, then don't have to worry :)

@basvanbeek
Copy link
Member

I’m not ready to give up on 1.8.

@anuraaga
Copy link
Contributor Author

anuraaga commented Nov 25, 2018

Ok no worries. Took some effort but got it to build on 1.8

  • Checked in vendor since latest x/net will not compile on 1.8
  • Renamed to legacy x/context package
  • Forced IPv4 since IPv6 doesn't work on 1.8 for some reason

I feel sorry for anyone that still has to use 1.8 in production 😮

@basvanbeek
Copy link
Member

I'll take a look... don't like the idea of having to include a vendor dir here...

@basvanbeek
Copy link
Member

basvanbeek commented Nov 29, 2018

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?

@anuraaga
Copy link
Contributor Author

Thanks @basvanbeek - I have removed 1.8 from the build too

Copy link
Member

@basvanbeek basvanbeek left a 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.

"google.golang.org/grpc/stats"

"github.com/openzipkin/zipkin-go"
. "github.com/openzipkin/zipkin-go/middleware/grpc"
Copy link
Member

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.

"net"
"testing"

. "github.com/onsi/ginkgo"
Copy link
Member

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.

@anuraaga
Copy link
Contributor Author

Thanks - removed the dot imports

@basvanbeek basvanbeek merged commit 006f66d into openzipkin:master Nov 30, 2018
@basvanbeek
Copy link
Member

Thanks @anuraaga are you planing on adding a gRPC server interceptor too?

@anuraaga
Copy link
Contributor Author

Yup - hoping to knock it out tomorrow

@basvanbeek
Copy link
Member

Cool... if you can update the Readme gRPC section with the upcoming PR that would be great!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants