Add optional histogram of msg size.

[bwplotka]

It would be useful to see e.g avg message size for the frame.

If we want this then for AC:
Add histograms (optional):

• grpc_server_msg_size_received_bytes
• grpc_client_msg_size_received_bytes
• grpc_server_msg_size_sent_bytes
• grpc_client_msg_size_sent_bytes

[yeya24]

Hello, can I work on this?

[brancz]

I believe no one is actively working on this, so feel free to grab it! :)

[robsonmeemo]

Ideally the whole metric collection should move to the grpc.StatsHandler interface. That would give easy access to the message size.

[tonywang]

I can contribute to this task. I have a few questions to confirm with you.

1. How to measure the message size, it is currently difficult to get the message size in the interceptor. What suggestions do you have?
2. Use the histograms for the message bytes. How do we plan the size of the bucket, 4096,8192,12288,...4M?
3. If the default size is changed by caller, do the buckets need to be modified dynamically?

Thanks

[robsonmeemo]

Look at grpc.StatsHandler for the right way to get the message size. But you probably need to move all the code to use that instead of being an interceptor.

I'd make the bucket size configurable by the server during initialization and not worry about the client.

[tonywang]

Whether our message size indicator needs to accumulate all possibilities? For example, the 3 kind of data received by the server, such as the received header, received trailer and received payload.

Do we need to accumulate these three sizes as grpc_server_msg_size_received_bytes metric?

I think the data size of the payload is what we are most concerned about, and the size limit of the message should also be directed at it.

[ghost]

Hy there
I am working on a project that would highly benefit from this issue. Do you mind if I had a look at it? I'll see what I can do to review the proposed PR and maybe get this resolved.

[kutty-kumar]

is this still open? if yes, can i take it up please ?