Hi, I am still not sure what your endgoal is. My understanding is that you have some kind of unique id (correlationId, not sure what correlation means here) and you want to attach it your calls, because that information is important for your logs. I can only guess that you might want to pass that Id along with your call graph (a call starts with some id and the server handling that rpc initiates new rpc, assigning them the same id) - i.e. you might want to come up with some very basic version of tracing. Also, I assume the correlation will be different each time a new end-user call is started.
Assuming tracing is the functionality you want, please be aware that gRPC
team is working on fully-fledged tracing/stats support for gRPC that will
be available in all languages (and will work cross-language) and will be
based on a proven design. Tracing support should be available sometime
within first half of 2017, so you might be better off just waiting for the
real tracing functionality to be available instead of trying to hack it
together yourself. Unfortunately, not much info about the tracing support
is available publicly yet (for the time being, you can think of Census the
same way you can about Zipkin or Opentracing).
If you need a short term solution for tracing purposes, just try adding a
metadata entry that carries the "correlationId":
var request = YOUR_PROTOBUF_REQUEST
var requestHeaders = new Metadata
{
{ "tracingId", "UNIQUE_IDENTIFIER_74631984..." }
};
var call = client.FooCall(request, requestHeaders);
on the server side, you will be able to access the "tracingId" metadata
entry through serverCallContext.RequestHeaders.
The advantage of using metadata API instead of adding an extra field to
your protobuf definitions is that the tracingId doesn't pollute your
service schema. Also, this makes more sense semantically as tracing
functionality should be orthogonal to the contents of your requests and
responses.
To some degree, you could automate instrumentation of new calls on the
client side by adding a custom CallInvoker (and that way whenever you start
a new call on a channel that uses that callInvoker, the custom callInvoker
could add the tracingId to the logs for you).
Another response is inline
On Wed, Feb 22, 2017 at 9:56 AM, Artem Miniailo <[email protected]>
wrote:
> Hi Jan, thanks for your reply. In fact, I need to automatize the processus
> of assigning the same correlationId to all the gRPC calls within one
> workflow. I need this correlationId to be able to put it in my logs. For
> this purpose I thought that it was possible to add this logic (assigning of
> correlationId) while generating the code by protoc. As soon as I run this
> command
>
> protoc.exe -I../../protos --csharp_out Greeter
>> ../../protos/helloworld.proto --grpc_out Greeter
>> --plugin=protoc-gen-grpc=\grpc_csharp_plugin.exe
>
>
> I thought it was possible to add another parameter with my own plugin (or
> overwrite "grpc_csharp_plugin.exe") that would add this logic.
> I found in GitHub repository
> <https://github.com/grpc/grpc/blob/master/src/compiler/csharp_generator.cc>
> the
> code for the plugin "grpc_csharp_plugin.exe", so I can add there my logic
> and recompile it... But it's dirty! I hope that exists some cleaner
> solution.
>
Yeah, I strongly recommend not to make any changes to the
grpc_csharp_plugin to add tracing functionality. In short, it's a recipe
for disaster. How would that work? Generating an extra "tracing" field in
every protobuf message is wrong and you probably would be able to wire that
into gRPC internals anyway. Of course, you can manually
add a field "tracingId" to every request message for each RPC you might
want to trace and manually populate it when invoking the RPC. That would be
legitimate if the field logically belonged to your protobuf schema, but for
tracing that is not the case - as opposed to other situations (e.g. you
have a bookstore application and your are passing bookId as part of your
PutBookInBasket and RemoveBookFromBasket RPCs - you see the difference)
> Do you know what I can do ?
>
> P.S. I also saw the tracing systems like Zipkin, Opentracing, but the idea
> is to do as simple as possible. In anyway I didn't find any info about
> "census", could you send me the link to read about it, please ?
>
>
> Kind regards,
> Artem Miniailo
>
> 2017-02-21 15:27 GMT+01:00 Jan Tattermusch <[email protected]>:
>
>> If I understand your question correctly, but it seems that you'll need to
>> add a field (e.g. "correlation_id") to all the requests and responses where
>> you need them. gRPC itself doesn't support anything like "attaching the
>> same field" to all requests and responses (besides metadata, but if your
>> correlationId has the right semantics to become a metadata entry is
>> impossible to decide without more context).
>>
>> If by "plugin" you mean interceptor, currently with C# you can only
>> intercept calls on the client side and you don't have access to messages
>> themselves, only to metadata).
>>
>> If your intention is to trace requests across your microservice stack,
>> you might be interested in the gRPC tracing functionality ("census",
>> currently in development).
>>
>> On Tue, Feb 21, 2017 at 11:22 AM, <[email protected]> wrote:
>>
>>>
>>> I have many microservices en .net communicating with each other via gRPC
>>> (I use "protoc.exe" and "grpc_csharp_plugin.exe" to generate the client and
>>> server parts).
>>> Now I need that the gRPC request keeps the same correlationId passing
>>> through different microservices.
>>>
>>> Please advise if I can add my own gRPC plugin that handle this
>>> automatically?
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "grpc.io" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to [email protected].
>>> To post to this group, send email to [email protected].
>>> Visit this group at https://groups.google.com/group/grpc-io.
>>> To view this discussion on the web visit https://groups.google.com/d/ms
>>> gid/grpc-io/510def25-331a-42c0-8339-1c968faafb11%40googlegroups.com
>>> <https://groups.google.com/d/msgid/grpc-io/510def25-331a-42c0-8339-1c968faafb11%40googlegroups.com?utm_medium=email&utm_source=footer>
>>> .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>
On Tue, Feb 21, 2017 at 11:22 AM, <[email protected]> wrote:
>
> I have many microservices en .net communicating with each other via gRPC
> (I use "protoc.exe" and "grpc_csharp_plugin.exe" to generate the client and
> server parts).
> Now I need that the gRPC request keeps the same correlationId passing
> through different microservices.
>
> Please advise if I can add my own gRPC plugin that handle this
> automatically?
>
> --
> You received this message because you are subscribed to the Google Groups "
> grpc.io" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> To post to this group, send email to [email protected].
> Visit this group at https://groups.google.com/group/grpc-io.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/grpc-io/510def25-331a-42c0-8339-1c968faafb11%40googlegroups.com
> <https://groups.google.com/d/msgid/grpc-io/510def25-331a-42c0-8339-1c968faafb11%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>
--
You received this message because you are subscribed to the Google Groups
"grpc.io" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at https://groups.google.com/group/grpc-io.
To view this discussion on the web visit
https://groups.google.com/d/msgid/grpc-io/CACF4M0StjDtV1kg6aNTYh2apecfMS37scyyoJd7iLMeNwbwWcw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
smime.p7s
Description: S/MIME Cryptographic Signature
