-
Notifications
You must be signed in to change notification settings - Fork 227
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: log local TCP address #454
feat: log local TCP address #454
Conversation
The big question is: how do we proceed with such log changes which could be considered breaking? I don't think it's a healthy practice to keep adding flags for each and every individual log field we add 🤔 |
I agree, I hate having to add so many config properties. But sadly, I do think that this is a breaking change. I think of all the logs that operators look at, I think they DO look at access logs. And they are not a nice json format, they are an unwieldy string mess that you would have to write a custom parser for. Here are the options I see...
So, in summary, I would say:
|
That's what I was expecting 😄
That's probably what I will be going for in this PR to prevent accumulating further config flags. Just a flat list, and if anyone needs special properties they can be added and exposed via this mechanism without breaking anyone.
This is my preferred long-term solution, but it will require quite some effort and it's not clear when we will be able to invest. |
eac4b22
to
20a7867
Compare
I've added a new property which allows logging of additional fields in a generic way. The release PR will follow once we agree on this PR. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
❓ Can you add a PR to routing-release so I can deploy and test everything at once?
I've opened cloudfoundry/routing-release#448 as a draft as I'm still adding tests. |
06efc11
to
085cb3b
Compare
The past weeks have been a bit busy, I finally found the time to clean this up. The rr PR is also ready now. Unfortunately test execution on my end is still hindered by cloudfoundry/routing-release#450. I ran the package tests using I'm currently also deploying this to one of our environments. Edit: works! |
@@ -255,6 +256,7 @@ func (rt *roundTripper) RoundTrip(originalRequest *http.Request) (*http.Response | |||
slog.Float64("dns-lookup-time", trace.DnsTime()), | |||
slog.Float64("dial-time", trace.DialTime()), | |||
slog.Float64("tls-handshake-time", trace.TlsTime()), | |||
slog.String("local-addr", trace.LocalAddr()), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
From reading your spec description on the other PR, it is not clear if the "extra_headers" property is only for access logs or not.
❓ Based on my reading of it, I would've thought it would affect these logs too? Thoughts?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hm, in the past we didn't give much thought to the compatibility of non-access-logs, primarily because these are JSON and we expect people to parse it as such. Additional fields shouldn't cause any breakage in those cases. For example the timing info directly above this line is controlled by a feature flag in the access logs but unconditionally included in this log.
I could adjust the wording in the release spec to reflect that clearly.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I could adjust the wording in the release spec to reflect that clearly.
Sounds good to me.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Adjusted the property description.
✅ tests pass |
9b22a57
to
04a92c6
Compare
04a92c6
to
0856d01
Compare
When troubleshooting issues related to keepalive it is often useful to be able to correlate multiple requests made over the same connection. A first step was to introduce the information on whether the request was made on a re-used connection or not which was done with a7dbf84. This commit adds the local address of the TCP connection which adds the capability to distinguish between multiple, parallel keep-alive connections by looking at the client port of gorouter for the backend connection.
0856d01
to
e0d4b36
Compare
Summary
When troubleshooting issues related to keepalive it is often useful to be able to correlate multiple requests made over the same connection. A first step was to introduce the information on whether the request was made on a re-used connection or not which was done with a7dbf84. This commit adds the local address of the TCP connection which adds the capability to distinguish between multiple, parallel keep-alive connections by looking at the client port of gorouter for the backend connection.
Backward Compatibility
Breaking Change? Yes