Как исправить ошибку 503 при запросе через haproxy?

Question

[by_EL]

Здраствуйте , У меня возник интересная ситуация , есть сайт которые работет через haproxy с ssl терминацией на самом haproxy , написал простой скрипт который проверяет состояние сайта и haproxy по коду ответа http если кож ответа отличается от 200, то скрипт запускает определенные действии , Проблема в том что иногда при нормальном работающем сайте, haproxy отвечает на запросы (через curl) кодом 503, и наоборот если для проверки изменить бакэнд сайта на другой ip , и заново запускать скрипт или команду curl , то иногда я получаю 200 как будто все нормально,но на самом деле он должен отвечать кодом 503, и к стати в логах тоже самое , Пожалуйста вот логи

Apr 10 04:50:15 haproxy1 haproxy[1917]: 192.168.1.154:6440 [10/Apr/2023:04:50:15.545] frontend_01~ example.com/s2 2/0/1/2/5 200 202 - - ---- 1/1/0/0/0 0/0 "HEAD / HTTP/1.1"
Apr 10 04:50:20 haproxy1 haproxy[1959]: 192.168.1.154:6448 [10/Apr/2023:04:50:17.622] frontend_01~ example.com/s2 2/0/-1/-1/3009 503 108 - - SC-- 1/1/0/0/3 0/0 "HEAD / HTTP/1.1"
Apr 10 04:50:24 haproxy1 haproxy[23458]: 192.168.1.153:6882 [10/Apr/2023:04:50:24.719] stats stats/<STATS> 0/0/0/-1/0 400 251 - - LR-- 1/1/0/0/0 0/0 "HEAD /stat HTTP/1.1"
Apr 10 04:50:25 haproxy1 haproxy[23465]: 192.168.1.154:6456 [10/Apr/2023:04:50:22.721] frontend_01~ example.com/s2 3/0/-1/-1/3010 503 108 - - SC-- 1/1/0/0/3 0/0 "HEAD / HTTP/1.1"
Apr 10 04:50:27 haproxy1 haproxy[1917]: 192.168.1.154:43170 [10/Apr/2023:04:50:27.798] frontend_01~ example.com/s2 2/0/1/2/5 200 202 - - ---- 1/1/0/0/0 0/0 "HEAD / HTTP/1.1"
Apr 10 04:50:32 haproxy1 haproxy[23458]: 192.168.1.154:43172 [10/Apr/2023:04:50:29.893] frontend_01~ example.com/s2 2/0/-1/-1/3009 503 108 - - SC-- 1/1/0/0/3 0/0 "HEAD / HTTP/1.1"
Apr 10 04:50:37 haproxy1 haproxy[1959]: 192.168.1.154:41422 [10/Apr/2023:04:50:34.953] frontend_01~ example.com/s2 2/0/-1/-1/3009 503 108 - - SC-- 1/1/0/0/3 0/0 "HEAD / HTTP/1.1"
Apr 10 04:50:39 haproxy1 haproxy[23465]: 192.168.1.153:32656 [10/Apr/2023:04:50:39.724] stats stats/<STATS> 0/0/0/-1/0 400 251 - - LR-- 1/1/0/0/0 0/0 "HEAD /stat HTTP/1.1"
Apr 10 04:50:43 haproxy1 haproxy[23458]: 192.168.1.154:41438 [10/Apr/2023:04:50:40.023] frontend_01~ example.com/s2 2/0/-1/-1/3008 503 108 - - SC-- 1/1/0/0/3 0/0 "HEAD / HTTP/1.1"

Спасибо за внимание !!

Comments

[Valentin Barbolin]

302 и 303 получается игнорируешь?

[Vitsliputsli]

А как настроен haproxy? Connection timeout, limit?

[by_EL]

Vitsliputsli,

global
 log /dev/log local0
 log /dev/log local1 notice
 log /dev/log local1 debug
 stats socket /var/lib/haproxy/stats user haproxy group haproxy mode 660 level admin #fast socket file for work haproxy stats 
 stats socket ipv4@127.0.0.1:9999 level admin  # for work a runtime api 
 stats timeout 30s
 chroot /var/lib/haproxy
 pidfile /run/haproxy.pid
 user haproxy
 group haproxy
 daemon
 maxconn 6000 
 nbthread 2
 ssl-default-bind-ciphers ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256
 ssl-default-bind-options ssl-min-ver TLSv1.2 no-tls-tickets 
 ssl-dh-param-file /etc/ssl/dsh2048.pem 
 
defaults http_defaults  #this section for http L7
 log global
 mode  http
 option httplog
 option dontlognull 
 timeout connect 4s 
 timeout client  30s  
 timeout server  4s 
 timeout queue   10s  
 timeout client-fin 30s 
 timeout tunnel  1h 
# timeout http-request 6s 
 option http-buffer-request 
# timeout http-keep-alive 20s 
 retries 3 
 maxconn 6000
 errorfile 400 /etc/haproxy/error_pages/400.http
 errorfile 403 /etc/haproxy/error_pages/403.http
 errorfile 408 /etc/haproxy/error_pages/408.http
 errorfile 500 /etc/haproxy/error_pages/500.http
 errorfile 502 /etc/haproxy/error_pages/502.http
 errorfile 503 /etc/haproxy/error_pages/503.http
 errorfile 504 /etc/haproxy/error_pages/504.http
# option http-server-close
# retry-on empty-response conn-failure response-timeout
 option forwardfor


 frontend per_ip_rates from  http_defaults 
     bind *:80
     bind *:443 ssl crt /etc/ssl/certs/haproxy
     mode http
     http-request redirect scheme https unless { ssl_fc }
     acl ACL_example.com hdr(host) -i example.com www.example.com
	 use_backend example.com if ACL_example.com
	 


backend  example.com  from  http_defaults
    server s2 192.168.1.140:8080

[Vitsliputsli]

by_EL,

Apr 10 04:50:20 haproxy1 haproxy[1959]: 192.168.1.154:6448 [10/Apr/2023:04:50:17.622] frontend_01~ example.com/s2 2/0/-1/-1/3009 503 108 - - SC-- 1/1/0/0/3 0/0 "HEAD / HTTP/1.1"

Здесь мы видим, что от клиента все получено быстро. Судя по коду, не получилось установить коннект к серверу, тем не менее время установки коннекта к серверу отсутствует... Не могу утверждать, но похоже, он не смог найти сервер на уровне ARP. Проблема сетевая между haproxy и сервером.

[Zerg89]

Apr 10 04:50:15 haproxy1 haproxy[1917]: 192.168.1.154:6440 [10/Apr/2023:04:50:15.545] frontend_01~ example.com/s2 2/0/1/2/5 200 202 - - ---- 1/1/0/0/0 0/0 "HEAD / HTTP/1.1"
04:50:27 haproxy1 haproxy[1917]: 192.168.1.154:43170 [10/Apr/2023:04:50:27.798] frontend_01~ example.com/s2 2/0/1/2/5 200 202 - - ---- 1/1/0/0/0 0/0 "HEAD / HTTP/1.1"

Хмм интересно что один и тот же процесс получает правильные данные может дело в тайм-аутах или полуоткрытых соединениях

Answer 1

[AUser0]

Ага, "ключи уронил там, а ищу здесь, под фонарём, потому что здесь светлее".

Ошибка происходит в скриптах, которые должны бы выдавать всегда 200 - вот и ищите в скриптах, в логах HTTP-сервера причину этой ошибки 503.

Comments

[by_EL]

AUser0 дело в том что если просто вручную выполнить команду curl , то тоже самое получается и это ложные ответы коды html даёт сам haproxy которые и в самом логах haproxy тоже видны

[AUser0]

by_EL, неправильный вывод. HAPROXY - это просто прокси. Ему дали - от переслал туда, ему вернулся ответ - он переслал в обратную сторону. Ошибку 503 генерирует не прокси сервер, её генерирует сервер-источник. И вам надо выяснить, почему N запросов из XXX дают ошибку 503.

Протестируйте множественные прямые подключения, без HAPROXY. Все 100% запросов происходят без ошибки 503?

[Vitsliputsli]

AUser0, haproxy такой же сервер, и ошибки могут быть и на его стороне. И 503 он вполне себе генерирует, когда не может достучаться до сервера.

[AUser0]

Vitsliputsli, да,согласен, и такое возможно. Многократные коннекты без прокси всё прояснят.

Answer 2

[d-stream]

А почему бы не научить haproxy проверять живость бэкэнда для начала?
А потом ещё и показывать красивую статистику.

Comments

[Vitsliputsli]

Какая разница при каком коннекте получим ошибку? Хоть при проверочном, хоть при боевом, все равно идти в лог и разбираться.

[by_EL]

Vitsliputsli, дело в том что в логах ни хрена нет , только есть лог типа --SC-- и --LR--

[d-stream]

Vitsliputsli, разницы почти не будет, но если haproxy будет регулярно нюхать живость бэка, притом нюхать и l3/l4 и l7 - то информации в логах и статистике будет больше и всё это будет информативнее -> позволит более точно выявить проблему.
В том числе можно нюхать как ресурс, так и его носитель (nginx/apache/kestrel/wildfly/etc).

[d-stream]

by_EL, сами логи haproxy можно сконфигурить поподробнее

[Vitsliputsli]

by_EL,

дело в том что в логах ни хрена нет , только есть лог типа --SC-- и --LR--

Уже не мало, я по SC и сужу, что он не смог соединиться с сервером, а судя по времени -1, до отправки запроса на TCP соединение дело не дошло, остается только ARP.
И, как верно предложили, посмотреть доку на предмет расширенного логирования.

[by_EL]

Vitsliputsli, но это не правдо именно когда проверяю через curl так получается , и это сценарию я повторял и на Ubuntu и на Rhel ,centos с разными конфигами haproxy

[Vitsliputsli]

by_EL, т.е. это не случайные ошибки, а при конкретных запросах, тогда сравните их с обычными. И curl что-то же пишет.
Что касается обращения к stats там ошибка LR, т.е. не все данные от клиента получены, возможно не получилось согласовать шифрование. Если это обращение к статистике haproxy, то в конфиге она не прописана.
И, как подсказали выше вероятно будет полезно расширенное логирование.

[d-stream]

Vitsliputsli, а есть ли смысл/задача/требование шифровать между haproxy и backend?
Да, в больших корпорациях иногда и между подами mTLS+ пользуют, но в общем случае проще и комфортнее терминировать ssl на балансировщике и дальше ему с бэками общаться по http

[Vitsliputsli]

d-stream, задачи бывают разные, я не эксперт, но в общем случае балансировщик наверное не должен этим заниматься, лучше чтобы он просто пробрасывал далее, чтобы у него была только одна задача. А зачем автору haproxy трудно сказать.

[d-stream]

Vitsliputsli, только вот фигня: когда я в такой схеме обращаюсь к сайту xxx.com - то dns имя ресолвится в ip балансировщика и туда же прилетают запросы, а за ним сидят какие-то бэкэнды с условными адресами b1.xxx.local...bN.xxx.local и нужны во-первых некие танцы с таким пробросом и невалидными сертами с CN xxx.com на хостах bx.xxx.local, во-вторых при большом N и необновлённой парочке сертов - будет весело, в-третьих при использовании того же letsencrypt с certbot - потребуется наворотить кастомную кучку правил.

Да, это всё преодолимо, но повышает количество точек отказа и без принципиальных допусловий - существенно проще и "коробочней" то что предложил я.

[Vitsliputsli]

d-stream, именно так, все зависит от задачи. Нужно исходить из того, что эффективней. И тут я не эксперт.