-
Notifications
You must be signed in to change notification settings - Fork 4.8k
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
Extra logging in 3.7.0 that should be a [debug] log than [notice] and differs from 2.8.x behavior #13205
Comments
I tested my change out via this code change: warmup.lua
And output now looks uniform with no extra acl loggings compared to other resources in notice mode. Gives just enough insight for notice mode I think, and I need to remove plugins since that already happens :P :
|
Side note... I have noticed my Kong runtimes spending a lot of time doing DNS warmups, especially stage and prod, taking as much as 30-60 seconds just to warm up DNS for 1000s of endpoint records. This is a dev environment with like less than 40 proxies on it in this example... why would DNS warmups take so long 4.6+ seconds? Maybe lookups that hang or not found? Any way to speed up DNS cache warmups? Maybe make kong dns lookups fail faster if it was a not found or if the reply from dns server is taking too long(better tuning timeout options maybe that let it time out at 20ms or something?). I know, unrelated to original post but was on my brain re-reading my logs here haha. Some of my own DNS settings:
Maybe a way to tune those or better recommended settings? |
@chobits FYI |
you could modify the attempts:the total number of times of retransmitting the DNS request when receiving a DNS response times out according to the timeout setting. When trying to retransmit the query, the next nameserver according to the round-robin algorithm will be picked up. It will retry times, cycling through the nameserver list. That means if there is only one nameserver,and attempts equals 5, it will retry the query to this one nameserver 5 times. Defaults to 5 times. timeout:the time in second for waiting for the response for a single attempt of request transmission. note that this is ''not'' the maximal total waiting time before giving up, the maximal total waiting time can be calculated by the expression timeout x retrans. Defaults to 2 seconds. |
@chobits let me give some of those suggested tweaks a try and see how it goes. I have:
But I also override some values with the ENV variables too:
By using the DNS_RESOLVER kong var override I think it ignores some of the resolv.conf and such. |
Is there an existing issue for this?
Kong version (
$ kong version
)3.7.0
Current Behavior
When
It seems specifically the acls bit does a lot of extra logging per every single consumer resource in Kong's runtime. This did not happen in notice level on Kong 2.8.x. For Kong instances with 1000s of consumers this print block takes up a lot of stdout early on in the runtime printing all these. Feels to me like the each consumer warmup acl group should be in [debug] mode, not [notice] mode which should be giving more important information.
Expected Behavior
Not log every single consumer uuid built into Kong on cache warmup of acls in notice mode.
See line here: https://github.com/Kong/kong/blob/3.7.0/kong/cache/warmup.lua#L148
I propose Kong makes the success log of it DEBUG level, and let if an acl cache consumer warmup fails like the line below with the err statement can keep that as NOTICE as it is or even ERROR level log since unanticipated behavior.
Steps To Reproduce
Read the current/expected behavior block has all deets
Anything else?
No response
The text was updated successfully, but these errors were encountered: