nginx: come posso rintracciare un 500 casuale da nginx (non la mia applicazione). Potenzialmente ha a che fare con il carico?

Recentemente abbiamo avuto circa 500 dalla stessa nginx che in qualche modo non erano registrati (abbiamo schermate, ma nulla nei registri). Questo è strano in sé, perché di solito compaiono errori lì. Indipendentemente da ciò, mi chiedo se esiste qualcosa come una dimensione del pool di connessioni che se al massimo comporterebbe un 500? Lo abbiamo potenzialmente correlato a un recente picco del traffico, ma non è conclusivo.

Qualcuno ha qualche idea su come iniziare ad affrontare un problema del genere?

Usiamo una combinazione di formati di registro in nginx e lmon per catturare cose come questa. Un formato di registro NGINX come:

log_format main '$ status: $ request_time: $ upstream_response_time: $ pipe: $ body_bytes_sent $ connection $ remote_addr $ host $ remote_user [$ time_local] "$ request" "$ http_referer" "$ http_user_agent" "$ http_x_forwarded_for" $ upstream_cdr in: $ http_cookie "'

Acquisirà molte informazioni diagnostiche utili, come il server upstream che ha gestito la richiesta, oltre a mettere lo stato in primo piano in modo che sia facile da leggere anche se i registri scorrono abbastanza velocemente.

Usiamo LMON per guardare questi registri e quindi avvisarci (cercapersone / e-mail) se vengono rilevati errori, come 500, 503, 400, nei registri:

http://www.bsdconsulting.no/tools/lmon-README

Questo può aiutarti ad essere avvisato di un problema quando si verifica che è il momento più semplice per eseguire il debug.

L'altra cosa che dovresti probabilmente considerare se non l'hai già fatto è che per impostazione predefinita nginx considera una 500 una condizione fatale e non prova un'altra a monte. Se hai più upstream, puoi configurarlo per usarne un altro se ne ottiene uno 500, sperando che oscuri l'errore dell'utente:

http://wiki.nginx.org/NginxHttpProxyModule#proxy_next_upstream

error_log $filename debug; attiverà la registrazione a livello di debug nel log degli errori - questo ti fornirà un sacco di dettagli sullo stato interno di nginx al momento dell'errore e, se compilato con --with-debug (che di default fanno diverse distro) darò ancora di più.

Tieni presente che il livello di "debug" genera davvero molto output, al punto che potresti voler controllare lo spazio su disco ...

Nel mio caso il file conf non è stato nominato correttamente (era example.com invece di example.com.conf) e non è stato incluso. In qualche modo questo non ha comportato "Benvenuto in nginx" ma un errore HTTP 500 non registrato. Bene, è stato effettivamente registrato, ma nel file di errore da un host virtuale diverso che non poteva funzionare con quel particolare URL.