¿Cómo puedo depurar nginx más allá del registro de errores?

Actualmente estoy recibiendo una inundación HTTP bastante grande en este momento, y está causando que mi proxy inverso nginx produzca una 502 Bad Gateway.

Tengo un servidor frontend que ejecuta nginx como proxy para mi servidor back-end, pero solo está recibiendo un montón de connect() failed (110: Connection timed out) while connecting to upstreamerrores. Toneladas de ellos. Si omito el servidor proxy para conectarme al backend, puedo ejecutar el sitio muy bien, así que sé que está en el proxy inverso en alguna parte. Sin embargo, no tengo idea de cómo determinar por qué se está agotando el tiempo de espera.

¿Alguna ayuda?

ejecutando nginx 1.2.3 en CentOS 6.2

Supongo que ya ha aumentado su nivel de registro de errores de Nginx para depurar. Si no, comience allí.

Probablemente su mejor opción sea usar stracepara ver las llamadas al sistema que realiza Nginx. En particular, querrá prestar atención a las connect()llamadas y vigilar los códigos de retorno de estos ( man 2 connectpuede ser su amigo aquí).

Una vez que tenga esa información, puede adivinar mejor si el problema se limita a su proxy de interfaz o si tiene algo que ver con las interacciones entre el proxy y el servidor de aplicaciones de fondo.

No se vuelve mucho más pedante que esto a menos que desee poner sondas dtrace:

1. Establezca el nivel de registro de depuración: /etc/nginx/nginx.conf:

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

2. Configure tcpdump en otra ventana:

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

3. Monitoree los archivos de registro en otra ventana:

   tail -f /var/log/nginx/*
   

4. Inicio nginx interactivamente con strace:

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

   Y entonces

    $ strace nginx 
   

Se puede obtener una mayor depuración con un nginx compilado con --with-debug. Compruébelo ejecutando:

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

Otro buen módulo no compilado por defecto es: HttpStubStatusModule . Con toda probabilidad, cualquier configuración decente requerirá un nginx compilado a medida (paquete altamente recomendado usando las herramientas de empaquetado de distro).

La mayoría de estos no son aptos para el uso en producción, mira compilar nginx con gperf si necesitas más estadísticas.

Parece que estás depurando un sitio de alto tráfico.

Úselo debugcon la debug_connectiondirectiva para que el registro de errores de nginx muestre los registros de depuración solo de su IP.

Una vez que comience a ver algunos registros de errores útiles en lugar de activar la opción de depuración para toda la configuración nginx, agregue una error_log /path/to/some/file/ debug;directiva separada en el location {..}bloque responsable de la conexión reverse_proxy.

De esta manera, podrá aislar el registro de errores de depuración solo de su IP.

Intente relacionarlo con la solicitud que está haciendo (desde su navegador).

Por ejemplo, consulte: https://easyengine.io/tutorials/nginx/debugging/

Un nivel por delante, puede usar HttpEchoModule de Nginx

Nunca he encontrado que Nginx sea un cuello de botella, en la mayoría de los casos es más que capaz que los back-end. Pero si probó sin Nginx y no encontró ningún error, entonces será cualquiera (o ambos):

1. Problema de configuración de Nginx
   1. Valor de tiempo de espera aguas arriba incorrecto
   2. URL de la sonda incorrecta en el flujo ascendente
   3. Muy pocos trabajadores
   4. Etc.
2. Sistema operativo TCP / IP cuello de botella
   1. Podría ser que el proxy en sí mismo esté causando una duplicación de puertos y estados abiertos. Ya se trate de descriptores de archivos, puertos, conexiones TCP

Sin ver sus configuraciones de Nginx, nadie puede comentar sobre la primera. Y sin resultados adecuados del sistema operativo, nadie puede comentar sobre este último.