Support extra tags for each gRPC call

Currently the tags in the gRPC MetricCollectingServerInterceptor are fixed to service, method, methodType & statusCode.

It would be great if there would be a support for a custom tags that depend on the ServerCall and Metadata as well, not only the method being invoked. This way the user would have freedom to add extra tags with values that depend on the caller.

[oehme]

For me, the main thing that’s missing from the default tags is the target address of the channel. I have an app with multiple channels that use the same service interface, connected to different hosts. If I use the same interceptor for each channel (e.g. like Micronaut does), then all the metrics end up indistinguishable. I’ve worked around this by adding a different interceptor to each channel and using the counterCustomizer/timerCustumizer to add the channel tag. It would be great if that just worked out of the box though, especially when future Micronaut versions add this as a global interceptor.

[ST-DDT]

Do you have an example for the tags that you would like to add?

The preregister methods are optional. I added them because in our applications some methods are called very rarely and I needed a way to identify them easily.

As for the protected calls. They are just a way for me to reuse code across the server and client implementation. They are based on the greatest common data avaiable for both server and client. Adding a TagProvider would render the entire abstract base class useless. Please note that you will need separate TagProvider interfaces for both server and client. ~Maybe its possible to use the same interface if we trash most of the current client implementation and potentially some of the semantics.~

I’m not against this change if it is worth it, but it may come at the price of increased complexity. Depending on the requirements, the client side may work entirely different from the server side. Especially the client side may be affected by the increase of complexity. Please ensure that it is still possible to cancel (and count) client calls, that have not been ClientCall#started due to executor constraints/workload (or at least document any new limlitations).

Please consult the grpc javadocs, regarding the limitations of the scope/thread safety of the related beans.