Add example for sleuth/brave integration

[asarkar]

This is a usage question.

In the Sleuth docs for gRPC, they mention two variants. First one uses io.github.lognet:grpc-spring-boot-starter and io.zipkin.brave:brave-instrumentation-grpc and clients must use SpringAwareManagedChannelBuilder. In the second variant, nothing is said other than "Grpc Spring Boot Starter automatically detects the presence of Spring Cloud Sleuth and brave’s instrumentation for gRPC and registers the necessary client and/or server tooling."

There doesn't seem to be any relation between these projects, and are maintained by different people. yidongnan/grpc-spring-boot-starter doesn't seem to use SpringAwareManagedChannelBuilder anywhere. Should it? Also, does it need io.zipkin.brave:brave-instrumentation-grpc to work?

Perhaps the owners of the two projects should discuss merging them. It seems like a waste of time to develop two parallel projects for the same purpose.

[ST-DDT]

Related issue: #164

In the Sleuth docs for gRPC, they mention two variants. First one uses io.github.lognet:grpc-spring-boot-starter and io.zipkin.brave:brave-instrumentation-grpc and clients must use SpringAwareManagedChannelBuilder. In the second variant, nothing is said other than "Grpc Spring Boot Starter automatically detects the presence of Spring Cloud Sleuth and brave’s instrumentation for gRPC and registers the necessary client and/or server tooling."

We are aware of this, unfortunately there is nothing we can do about it. Our requests for adding better documentation have been refused.

yidongnan/grpc-spring-boot-starter doesn't seem to use SpringAwareManagedChannelBuilder anywhere. Should it?

No, I will explain it in detail below.

Also, does it need io.zipkin.brave:brave-instrumentation-grpc to work?

Yes, the dependency is required for sleuth to work in this context.

There doesn't seem to be any relation between these projects, and are maintained by different people. [...] Perhaps the owners of the two projects should discuss merging them. It seems like a waste of time to develop two parallel projects for the same purpose.

There are two major problems here:

1. IMO it's impolite to ask others to drop their work.
2. Both projects try to achieve different goals.
   • The LogNet one tries to be especially lightweight (server only) and maintain support for Spring-Boot 1.x
   • This one tries to cover the important parts while being extensible/customizable (server + client)

LogNet's goal trying to be lightweight/server only resulted in the controversial state where sleuth added a support class to their code, that is the part of the core of this library. Sleuth somewhat agrees with us that it shouldn't be (necessary to be a) part of Sleuth. See also this javadoc in the sleuth repo.

Sleuth's SpringAwareManagedChannelBuilder is roughly equivalent to our GrpcChannelFactory.

[ST-DDT]

Maybe I should drop a few words in the docs about sleuth/brave-instrumentation-grpc.

[ST-DDT]

Added a few lines in the upcoming documentation. Does this help you?

Ref: #239

[asarkar]

1. "You need a Tracing bean in your application context." A code example would be great.
2. Under additional notes, "those class solely exists" is a grammatical error; should be "those classes solely exist".

Other than the above, looks good to me.

[ST-DDT]

1. Unfortunately I don't have one. All I could do is link to sleuth's TraceAutoConfiguration. Would that be sufficient? Unfortunately I'm not that familiar with sleuth/brave.
2. Fixed

[asarkar]

Short of a working example, I think what you’ve is an excellent start.