solo-io
Support listener access logging
Version
1.14.x (latest stable)
Is your feature request related to a problem? Please describe.
Downstream connections that fail to be established are not reported in the HCM or TCP Proxy access logs. There are certain listener metrics that can be used to identify the existence of such connection issues. However, the connection context (e.g. downstream IP, requested server name, failure reason...) is not available, making it difficult to investigate such issues.
According to Envoy Docs:
Downstream connection access logging can be enabled using listener access logs. The listener access logs complement HTTP request access logging and can be enabled separately and independently from filter access logs.
The %DOWNSTREAM_TRANSPORT_FAILURE_REASON% command operator, introduced in envoy 1.26, is only available for listener access logs. This stream info is particularly useful for troubleshooting connection issues.
Describe the solution you'd like
Gloo Edge should support:
- Independent configuration of Listener Access Logs
- The %DOWNSTREAM_TRANSPORT_FAILURE_REASON% command operator (envoy 1.26)
Describe alternatives you've considered
No response
Additional Context
No response
@moshevayner is taking a look at this. I don't have permission to assign to him so just self assigning for now so that folks know someone is looking at it
Hey y'all 👋🏼 ! Excited to work on my first PR for this project! 🤩
I've been trying to dive into the code and figure out what exactly needs to be done, but unfortunately without much success so far..
I'd love to get some pointers as to what should be changed/added, and where.
Thanks!! 🙏🏼
Hey happy to walk through on a call on Saturday or any day next week.
However it sounds like you may have picked this up as a good first issue but I believe this label was erroneously applied. The hard bit about this issue is that we have top level settings commands and lower level gateway configuration. Neither which nicely maps to listener filters which we do allow to be configured in some plugins but is a paradigm that we don't currently do as often.
If you would prefer we can find another good first issue if that's preferable.
I dropped the assignment to avoid confusion or unnecessary delay. I think we can reprioritize and let someone else pick it up
Hey happy to walk through on a call on Saturday or any day next week.
However it sounds like you may have picked this up as a good first issue but I believe this label was erroneously applied. The hard bit about this issue is that we have top level settings commands and lower level gateway configuration. Neither which nicely maps to listener filters which we do allow to be configured in some plugins but is a paradigm that we don't currently do as often.
If you would prefer we can find another good first issue if that's preferable.
Thanks a lot @nfuden ! Yup I'm good with trying to find something more suitable for an entry-level contrib. @ilrudie is helping me out with finding that. 🙏🏼
@DuncanDoyle @sam-heilbron - I see that version v1.17.0-beta16 was already released. Can you commit (as labeled in the issue) that a fix will be provided as part of 1.17 release? Thanks
@idogoren: It's targeted for 1.17. Top of the list in our prio queue for engineering to pick it up.
Merged in 1.17 OSS. Should land in enterprise 1.17 beta2 or 1.17 beta3, will update once that becomes clearer