Como posso depurar o nginx mais do que o log de erros?

Question

No momento, estou recebendo uma inundação HTTP bastante grande agora, e está fazendo com que meu proxy reverso nginx produza um 502 Gateway Incorreto.

Eu tenho um servidor de front-end executando nginx como um proxy para o meu servidor de back-end, mas é só pegar um monte de erros connect() failed (110: Connection timed out) while connecting to upstream . Toneladas deles. Se eu ignorar o servidor proxy para se conectar ao backend, posso executar o site muito bem, então eu sei que está no proxy reverso em algum lugar. No entanto, não tenho ideia de como determinar o tempo limite.

Alguma ajuda?

executando o nginx 1.2.3 no CentOS 6.2

    

Answer 1

Estou assumindo que você já elevou seu nível de registro de erro Nginx para depuração. Se não, comece por aí.

Sua melhor aposta provavelmente será usar strace para visualizar as chamadas do sistema feitas pelo Nginx. Em particular, você vai querer prestar atenção a connect() de chamadas, e fique de olho nos códigos de retorno destes ( man 2 connect pode ser seu amigo aqui).

Depois de obter essas informações, você poderá adivinhar melhor se o problema está restrito ao seu proxy de frontend ou se tem algo a ver com as interações entre o proxy e o servidor de aplicativos de back-end.

    

Answer 2

Não é muito mais pedante do que isso, a menos que você queira colocar em testes do dtrace:

1. Defina o nível do registro de depuração: /etc/nginx/nginx.conf:

   ...
   http {
           ...
           error_log /var/log/nginx/error.log debug; # todo testing remove me not for production use
           ...
   }
   

2. Configure o tcpdump em outra janela:

   tcpdump not port 22 -vvv -s0 -q -XXX
   

3. Monitore os arquivos de log em outra janela:

   tail -f /var/log/nginx/*
   

4. Iniciar nginx interativamente com strace:

   # top of /etc/nginx/nginx.conf:
   
   daemon off; # todo testing remove me not for production use
   

   e depois

    $ strace nginx 
   

Mais depuração pode ser obtida com um nginx compilado com --with-debug . Verifique-o executando:

    nginx -V 2>&1 | grep -- '--with-debug' # no output if not debug

Outro bom módulo não compilado por padrão é: HttpStubStatusModule . Com toda a probabilidade, qualquer configuração decente exigirá um nginx compilado sob encomenda (uma embalagem altamente recomendável usando as ferramentas de empacotamento da distro).

A maioria destes é inadequada para uso em produção, olhe para compilar nginx com gperf se você precisar de mais estatísticas.

    

Answer 3

Parece que você está depurando um site de alto tráfego.

Use a diretiva debug with debug_connection para que o log de erros do nginx mostre os logs de depuração somente do seu IP.

Quando você começar a ver alguns logs de erro úteis, em vez de ativar a opção de depuração para toda a configuração do nginx, adicione uma diretiva error_log /path/to/some/file/ debug; separada no bloco location {..} responsável pela conexão reverse_proxy.

Dessa forma, você poderá isolar o registro de erros de depuração apenas do seu IP.

Tente relacioná-lo com a solicitação que você está fazendo (no seu navegador).

Por exemplo, verifique: link

Um nível à frente, você pode usar o HttpEchoModule do Nginx

    

Answer 4

Eu nunca achei o Nginx um gargalo, na maioria dos casos é mais que capaz do que o back-end. Mas se você testou sem o Nginx e não encontrou nenhum erro, então ele será (ou ambos):

1. Problema de configuração do Nginx
   1. Valor do tempo limite de envio errado
   2. URL de sondagem incorreta no upstream
   3. Poucos trabalhadores
   4. Etc.
2. gargalo do sistema operacional TCP / IP
   1. Pode ser que o proxy esteja causando uma duplicação de portas e estados abertos. Seja descritores de arquivos, portas, conexões TCP

Sem ver suas configurações do Nginx, ninguém pode comentar sobre o primeiro. E sem saídas adequadas do sistema operacional, ninguém pode comentar sobre o último.