Назад | Перейти на главную страницу

Проверки работоспособности HAProxy: с помощью httpchk и наблюдать?

Я использую HAProxy 1.4.18 со следующей конфигурацией серверной части

backend staging
  option httpchk HEAD /check.txt HTTP/1.0
  http-check disable-on-404
  default-server error-limit 1 on-error mark-down
  server staging01 x.x.x.x:80 check observe layer7
  server staging02 x.x.x.x:80 check observe layer7

На серверах запущено несколько приложений на apache / пассажир.

Комбинация httpchk и disable-on-404 позволяет довольно легко плавно завершить работу и удалить сервер из lb, сохраняя при этом прямой доступ (например, для тестирования).

Я пытаюсь настроить наблюдение, чтобы отключить сервер, когда приложение не работает. Я нарушил конфигурацию приложения на staging02, поэтому он всегда возвращает 500. Он правильно помечен DOWN после первых 500, но затем помечен UP на следующем httpchk.

Вот файл журнала:

Server staging/staging02 is DOWN, reason: Health analyze, info: "Detected 1 consecutive errors, last one was: Wrong http response". 1 active and 1 backup servers left. 2 sessions active, 0 requeued, 0 remaining in queue.
Server staging/staging02 is DOWN, reason: Health analyze, info: "Detected 1 consecutive errors, last one was: Wrong http response". 1 active and 1 backup servers left. 1 sessions active, 0 requeued, 0 remaining in queue.
Server staging/staging02 is UP, reason: Layer7 check passed, code: 200, info: "OK", check duration: 0ms. 2 active and 1 backup servers online. 0 sessions requeued, 0 total in queue.

Есть ли способ объединить эти две проверки?

Теперь я понимаю различие в том, что /check.txt делает фактически возвращает ответ 200, но все запросы к приложению возвращают 500. HAProxy видит, что 500 возвращаются из проксированных запросов и извлекает сервер из пула, но затем инициирует собственную проверку, получает 200 и помещает сервер обратно в бассейн.

Решением было бы сделать одно из:

  1. Настройте Apache, а не приложение, чтобы каждый запрос возвращал ответ 500, даже статический файл /check.txt.
  2. + Изменить /check.txt в приложение Ruby, которое содержит достаточно логики, чтобы выбрать ответ 200 или 500, когда это необходимо.
  3. Установить inter стоимость на что-то нелепое, например, 3600. Это даст вам час на то, чтобы провести тестирование или (если сервер вышел из строя сам по себе) выяснить проблему и восстановить ее.
  4. Установить inter значение меньше 60, но установите rise значение выше 60. Это также даст вам час до того, как сервер будет снова добавлен в пул. (Обратите внимание, эти двое указаны последними, потому что они, вероятно, очень плохие идеи.)