apisix
apisix copied to clipboard
request help: How about replace ngx.balancer ?
Issue description
There are many limitations in ngx.balancer :
- Can't set
proxy_next_upstreamdynamically and individually. - Can't get tcp error in log_phase, so can't enable passive tcp check in log_phase
I wanna adding this feature to apisix, but ngx.balancer baffle me.
Environment
- apisix version (cmd:
apisix version): 2.8 - OS (cmd:
uname -a): Linux 5.4.94-1.el7.elrepo.x86_64 centos7 - OpenResty / Nginx version (cmd:
nginx -Voropenresty -V): openresty/1.19.9.1 - luarocks version, if the issue is about installation (cmd:
luarocks --version): 3.4.0
You can extend it via adding new code to https://github.com/api7/apisix-nginx-module/tree/main/patch
Looks like those two things can be done in Lua land so there is no need to patch. What about your opinion? Replace ngx.balancer, of course, is unacceptable.
Can't get tcp error in log_phase, so can't enable passive tcp check in log_phase
OK, seems there is no way to distinguish tcp error from the HTTP error in the log phase. But we already count all the tcp errors as HTTP error in the log phase, count them separately is confusing (The number will be mismatched with the one in the access log). So current way is good enough to me.
I come from apisix-ingress-controller. we have many pod ips, I wanna checking this ips is exists, so i can't using active checker, i use only tcp passive checker. if http return 502 in log phase that is confusing to distinguish tcp error
I come from apisix-ingress-controller. we have many pod ips, I wanna checking this ips is exists, so i can't using active checker, i use only tcp passive checker. if http return 502 in log phase that is confusing to distinguish tcp error
It's inevitable to modify the Nginx core to expose the real cause.
This issue has been marked as stale due to 350 days of inactivity. It will be closed in 2 weeks if no further activity occurs. If this issue is still relevant, please simply write any comment. Even if closed, you can still revive the issue at any time or discuss it on the [email protected] list. Thank you for your contributions.
This issue has been closed due to lack of activity. If you think that is incorrect, or the issue requires additional review, you can revive the issue at any time.