Странноватая логика retry-on в HAProxy

... Какое дело. Всем хорош nginx. За исключением одного неприятного момента. Функционал health-check для бэкенда у него платный. А все ж жадные, с деньгами расставаться не любят. Плюс, у HAProxy есть дюже удобная морда для диагностики и готовые интерфейсы для подключения его к мониторингу и сбора статистики. Поэтому в некоторых проектах "мы подумали и я решил" использовать именно HAProxy.

... Помимо прочего, у HAProxy есть логика "retry-on", которая позволяет прозрачно для клиента перенаправлять тот же самый запрос на другой бэкенд, если текущий, например, ответил 500-ой ошибкой. Но работает она, на мой взгляд, как-то странновато. Вот почему.

1. В документации нигде про это не сказано, но директива "retry-on" конфликтует с опцией "prefer-last-server". Сам демон тоже не выдаст никакой ошибки, просто "retry-on" не отработает. Может, для кого-то это очевидно, но лично для меня — нет.


2. Для режима проксирования на 7м уровне (HTTP) также должна быть включена опция "redispatch". Вот какое отношение она имеет к вопросу, лично мне ни разу не понятно, потому что она про Cookies, а не про коды ошибок. Но без неё тоже не работает, проверено эмпирически.


3. Если какой-то из бэкендов помечен как "backup", то на него не будет распространяться действие "retry-on". Тоже, казалось бы... почему бы не попросить у бэкапного сервера инфу, если все остальные сдались / сдулись? Но нет...

... И напоследок, как проверить действительно ли функционирует логика "retry-on", или же директива в конфиге есть, а толку от неё нет. Надо запросить у балансировщика что-нибудь эдакое, на что один из бэкендов гарантированно ответит 500 и посмотреть в логи. Если там будет видно что-нибудь типа "17/17/0/0/+1", значит "retry-on" сработал. После плюса идёт количество тех самых попыток повтора (retries), которые предпринял HAProxy для обслуживания запроса клиента. По умолчанию максимальное их количество равно трём.