Verificações de integridade do HAProxy: usando httpchk e observe?

Question

Estou usando o HAProxy 1.4.18 com a seguinte configuração de backend

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

Os servidores estão executando vários aplicativos no apache / passageiro.

A combinação de httpchk e disable-on-404 permite o desligamento normal e a remoção de um servidor da lb com facilidade, enquanto ainda é possível acessar diretamente (ou seja, para testes).

Estou tentando observar a configuração para desativar um servidor quando um aplicativo não está funcionando. Eu quebrei a configuração do aplicativo no staging02 para que ele sempre retorne um 500. É marcado corretamente PARA BAIXO após os primeiros 500, mas marcados como UP no próximo httpchk.

Aqui está o arquivo de log:

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.

Existe uma maneira de combinar essas duas verificações?

    

Answer 1

A diferença que entendo agora é que /check.txt faz na verdade retornar uma resposta 200, mas todas as solicitações para o aplicativo retornam um 500. O HAProxy vê os 500s voltando das solicitações com proxy e assume o servidor fora do pool, mas inicia sua própria verificação, recebe um 200 e coloca o servidor de volta no pool.

A solução seria fazer um dos seguintes:

1. Configure o Apache, em vez do aplicativo, para que cada solicitação retorne uma resposta 500, até mesmo o arquivo estático /check.txt .
2. Altere /check.txt em um aplicativo Ruby que contenha lógica suficiente para escolher entre uma resposta 200 e uma 500, quando apropriado.
3. Defina o inter value como algo ridículo como 3600 Isto deve dar-lhe uma hora para fazer o seu teste ou (se o servidor caiu por conta própria) descobrir o problema e trazê-lo de volta.
4. Defina o valor inter para algo menor como 60, mas defina o valor rise para algo maior como 60. Isso também lhe daria uma hora antes de o servidor ser adicionado novamente ao pool. (Note, estes dois são listados por último porque provavelmente são idéias muito ruins.)