-
Notifications
You must be signed in to change notification settings - Fork 438
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
Support listener access logging #8438
Comments
@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 👋🏼 ! 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 |
Thanks a lot @nfuden ! |
@DuncanDoyle @sam-heilbron - I see that version v1.17.0-beta16 was already released. |
@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 |
Closing and will comment once the enterprise version drops |
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:
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:
Describe alternatives you've considered
No response
Additional Context
No response
┆Issue is synchronized with this Asana task by Unito
The text was updated successfully, but these errors were encountered: