[In-progress PoC] dumping connection logs #10279
Draft
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I'd appreciate a review of this code to let me know if I'm on a track that you'd be happy to eventually upstream... I have tried to implement as separate wrapper functions so that they can be toggled based on whether this config parameter exists or not with no change to other code.
Unfortunately, the only way I could make it so that the TLS and TCP connections dumped in the same place was to change the signature of
ServeTCP
to include a context object similar to HTTP'sreq.Context()
as I did not want to extendtcp.WriterCloser
to include context. I feel like there should be a better way to do this, but I'm not a golang expert.What does this PR do?
Creates a 'connectionlog' similar to 'accesslog' but on a per-TCP connection level (later can be extended UDP/QUIC)
Motivation
We wish to account for bandwidth more accurately than just the http payload. In order to do this we currently account:
Currently it's just dumping JSON to the standard log, however we will extend it by copying a fair bit of the
accesslog
code to make it relatively compatible with this.The idea is that with appropriate connection open/close timestamps and source ip/port this could then be correlated with the accesslog to create a fuller view of the connection.
More
Additional Notes