This is tricky. In gRPC Ruby, the developer retrieves client classes using the rpc_sub_class method on the service itself; specific configurations pass via the initialization method. Here's an example in the demo app.

The gRPC Go package for DataDog supplying the intereceptor when setting up the client.

// from the godocs at https://godoc.org/github.com/DataDog/dd-trace-go/contrib/google.golang.org/grpc
// Create the client interceptor using the grpc trace package.
i := grpctrace.UnaryClientInterceptor(
    grpctrace.WithServiceName("my-grpc-client"),
    grpctrace.WithTracer(tracer.DefaultTracer),
)

// Create initialization options for dialing into a server. Make sure
// to include the created interceptor.
opts := []grpc.DialOption{
    grpc.WithInsecure(),
    grpc.WithUnaryInterceptor(i),
}

// Dial in...
conn, err := grpc.Dial("localhost:50051", opts...)
if err != nil {
    log.Fatal(err)
}
defer conn.Close()

// And continue using the connection as normal.

In Ruby, that would look like:

Demo::Echo::Service.rpc_stub_class
                                  .new('localhost:50051',
                                           :this_channel_is_insecure,
                                           :interceptors => [Datadog::Contrib::GRPC::DatadogInterceptor::Client.new])

Pin information may then be set on the interceptor instance. What do you think of that approach? Would that also mean there's no need for a global pin or monkey patching the InterceptionContext?

Support gRPC #379

Description

Jared-Primeopenedon Mar 20, 2018

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

Jared-Prime
openedon Mar 20, 2018