gRPC Stream Interceptors

[jpopadak]

Is your feature request related to a problem? Please describe.
There currently exists within apmgrpc UnaryClientInterceptor and UnaryServerInterceptor.

I see within the documentation it says no Stream support exists for gRPC.

There is currently no support for intercepting at the stream level. Please file an issue and/or send a pull request if this is something you need.

Well, here I am asking for a Client and Server Stream Interceptor for gRPC use. 🙃
We have many services that use gRPC Stream APIs, and this is sadly one of our blockers for a quick migration.

Describe the solution you'd like
A similar interceptor (just as easy) as the UnaryClientInterceptor and UnaryServerInterceptor.

Describe alternatives you've considered

Additional context
Unrelated, but gRPC specific: Would be wonderful if we could also get #900 included.

[axw]

What would you expect the stream interceptors to measure? Beginning to end of stream? Anything in between?

[jpopadak]

Something like how the Unary interceptors work.

• Timing
• Deadline if any
• Response code
• Error if any
  I don't think we need the whole message body (most people probably won't use it).

The Logrus interceptor is a good basic example of how to retrieve the data.

[axw]

Thanks @jpopadak. Seems reasonable to create a transaction/span for the entire stream. Maybe in the future we could extend this to log events for individual messages written to and read from the stream, if we implement something like #818.

[jpopadak]

Yeah, the only thing I worry about is the max number of spans. It might be hit quicker for Stream APIs.
For example, one of our services streams its data using thousands of messages on a "single stream".

[axw]

@jpopadak if you have a chance to test this out some time soon I'd appreciate any feedback you may have, so we can make changes before the next release as needed.