Come posso eseguire il debug di nginx oltre al registro degli errori?

Attualmente sto ricevendo un diluvio HTTP abbastanza grande in questo momento, e sta causando il mio proxy inverso nginx per produrre un 502 Bad Gateway.

Ho un server frontend che esegue nginx come proxy per il mio server back-end, ma sta ottenendo solo un sacco di connect() failed (110: Connection timed out) while connecting to upstreamerrori. Tonnellate di loro. Se ignoro il server proxy per connettermi al back-end, posso eseguire il sito bene, quindi so che è nel proxy inverso da qualche parte. Tuttavia, non ho idea di come determinare perché sta scadendo.

Qualsiasi aiuto?

con nginx 1.2.3 su CentOS 6.2

Suppongo che tu abbia già aumentato il livello di registrazione degli errori Nginx fino al debug. Altrimenti, inizia da lì.

Probabilmente la tua scommessa migliore verrà utilizzata straceper visualizzare le chiamate di sistema effettuate da Nginx. In particolare, dovrai prestare attenzione alle connect()chiamate e tenere d'occhio i codici di ritorno di questi ( man 2 connectpuò essere tuo amico qui).

Una volta che si dispone di tali informazioni, è possibile formulare un'ipotesi approfondita se il problema è limitato al proxy front-end o ha a che fare con le interazioni tra il server delle applicazioni proxy e back-end.

Non diventa molto più pedante di questo a meno che tu non voglia inserire sonde dtrace:

1. Imposta livello registro debug: /etc/nginx/nginx.conf:

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

2. Installa tcpdump in un'altra finestra:

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

3. Monitorare i file di registro in un'altra finestra:

   tail -f /var/log/nginx/*
   

4. Avvia nginx in modo interattivo con strace:

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

   E poi

    $ strace nginx 
   

È possibile eseguire ulteriori debug con un nginx compilato --with-debug. Controlla eseguendo:

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

Un altro buon modulo non compilato di default è: HttpStubStatusModule . Con ogni probabilità, qualsiasi installazione decente richiederà un nginx compilato su misura (imballaggio altamente raccomandato utilizzando gli strumenti di imballaggio di Distro).

La maggior parte di questi non sono adatti per l'uso in produzione, osserva la compilazione di nginx con gperf se hai bisogno di più statistiche.

Sembra che tu stia eseguendo il debug di un sito ad alto traffico.

Utilizzare debugcon debug_connectiondirettiva in modo che il registro degli errori di nginx mostrerà i registri di debug solo dal proprio IP.

Una volta che inizi a visualizzare alcuni utili log degli errori anziché attivare l'opzione di debug per l'intera configurazione di nginx, aggiungi una error_log /path/to/some/file/ debug;direttiva separata nel location {..}blocco responsabile della connessione reverse_proxy.

In questo modo sarai in grado di isolare il log degli errori di debug solo dal tuo IP.

Prova a metterlo in relazione con la richiesta che stai facendo (dal tuo browser).

Ad esempio, controlla: https://easyengine.io/tutorials/nginx/debugging/

A un livello superiore, puoi utilizzare HttpEchoModule di Nginx

Non ho mai trovato Nginx un collo di bottiglia, nella maggior parte dei casi è più che capace dei back-end. Ma se hai testato senza Nginx e non hai trovato alcun errore, allora sarà uno (o entrambi):

1. Problema di configurazione di Nginx
   1. Valore di timeout a monte errato
   2. URL sonda errato su upstream
   3. Troppi lavoratori
   4. Eccetera.
2. Collo di bottiglia TCP / IP del sistema operativo
   1. Potrebbe essere che il proxy stesso stia causando una duplicazione di porte e stati aperti. Che si tratti di descrittori di file, porte, connessioni TCP

Senza vedere le tue configurazioni Nginx, nessuno può commentare il primo. E senza output adeguati dal sistema operativo, nessuno può commentare quest'ultimo.