Open orf opened 2 months ago
I get that it's a lot of frames, and they might not be that interesting, but then again, I do think the frame events are more important than all the other events emitted at trace level. Especially if you're trying to debug what the communication to the peer was.
Perhaps there’s a middle ground here? “Uninteresting” frames, like data frames, could be logged with trace, but less-common ones could be logged as debug messages? Ones that would indicate interesting situations for debugging.
And maybe higher-level things, like “request completed: sent this many bytes, received this many bytes”. Right now, it’s just tracing the happy-path: connections are working, data is being sent. The signal-to-noise ratio seems really off.
Personally, and with someone with little http2 experience, I’m not sure how these messages would help me debug communication issues. It only contains the stream ID and not other relevant information like the size of the frame, which I’d assume would be useful to debug issues?
The length would be a valuable thing to add.
Enabling
DEBUG
tracing/logging when usingh2
results in a very, very large volume of messages being logged: 3,706 messages when making a small number of requests.Emitting a message on every frame received feel much more like it should be
trace
messages, not debug messages. This PR switches them totrace
instead.