Suggestion to track low-level gRPC stream calls #15

New issue

Closed

opened 2024-11-07 08:55:54 +00:00 by alexvanin · 1 comment

alexvanin commented

2024-11-07 08:55:54 +00:00

Owner

Maybe during deep performance investigation, it can be useful to track timestamps of all recv and send events in gRPC stream. Probably we can define more detailed version of gRPC interceptor to track these events.

To do that, span can be stored in serverStream and clientStream structures. Then call span.AddEvent on structure methods, e.g.

func (cs *clientStream) CloseSend() error {
	cs.span.AddEvent("close send")
	err := cs.originalStream.CloseSend()

It will look like this in Jaeger.

This might be overhead for some cases, so don't hesitate to decline.

_Maybe_ during deep performance investigation, it can be useful to track timestamps of all `recv` and `send` events in gRPC stream. Probably we can define more detailed version of gRPC interceptor to track these events. To do that, span can be stored in `serverStream` and `clientStream` structures. Then call `span.AddEvent` on structure methods, e.g. ``` func (cs *clientStream) CloseSend() error { cs.span.AddEvent("close send") err := cs.originalStream.CloseSend() ``` It will look like this in Jaeger. ![image](/attachments/a9d9005e-7423-4cfd-93c4-aa6e7ed0cfe2) This might be overhead for some cases, so don't hesitate to decline.

image.png

103 KiB

alexvanin added the

enhancement

discussion

labels 2024-11-07 08:55:54 +00:00

dstepanov-yadro commented

2024-11-07 09:31:26 +00:00

Member

I will be immensely happy if you make these changes. In an ideal world, tracing should be enabled only for research, not for the general case, so adding important I/O-related spans is only welcome.