nginx: comment retrouver un 500 aléatoire de nginx (pas mon application). A potentiellement quelque chose à voir avec la charge?

Nous avons récemment eu quelques 500 de nginx qui n'étaient en quelque sorte pas enregistrés (nous avons des captures d'écran, mais rien dans les journaux). C'est étrange en soi, car généralement des erreurs apparaissent. Quoi qu'il en soit, je me demande s'il existe quelque chose comme une taille de pool de connexions qui, si elle était maximisée, aboutirait à 500? Nous l'avons corrélé potentiellement à un récent pic de trafic, mais ce n'est pas concluant.

Quelqu'un a-t-il des idées sur la façon de commencer à aborder un tel problème?

Nous utilisons une combinaison de formats de journaux dans nginx et lmon pour attraper des choses comme ça. Un format de journal NGINX comme:

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_addr $ upstream_c " dans: $ http_cookie "'

Capturera de nombreuses informations de diagnostic utiles, comme le serveur en amont qui a traité la demande, ainsi que la mise en avant de l'état afin qu'il soit facile à lire même si les journaux défilent assez rapidement.

Nous utilisons LMON pour regarder ces journaux, puis nous alerter (pagers / e-mail) s'il voit des erreurs, comme 500s, 503s, 400s, dans les journaux:

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

Cela peut vous aider à être alerté d'un problème lorsqu'il survient, ce qui est le moment le plus simple pour le déboguer.

L'autre chose que vous devriez probablement considérer si vous ne l'avez pas déjà fait est que par défaut, nginx considère un 500 comme une condition fatale et n'en essaie pas un autre en amont. Si vous avez plusieurs en amont, vous pouvez le configurer pour en utiliser un autre s'il obtient un 500, en espérant, espérons-le, masquer l'échec de l'utilisateur:

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

error_log $filename debug; activera la journalisation du niveau de débogage dans le journal des erreurs - cela vous donnera beaucoup, beaucoup de détails sur l'état interne de nginx au moment de l'erreur, et s'il est compilé avec --with-debug (ce que plusieurs distributions font par défaut), il 'donnerai encore plus.

Soyez averti que le niveau de "débogage" génère vraiment beaucoup de sortie, au point que vous voudrez peut-être surveiller votre espace disque ...

Dans mon cas, le fichier conf n'était pas nommé correctement (était example.com au lieu de example.com.conf) et n'était pas inclus. D'une manière ou d'une autre, cela n'a pas entraîné «Bienvenue dans nginx» mais une erreur HTTP 500 non enregistrée. Eh bien, il a été enregistré, mais dans le fichier d'erreur d'un autre hôte virtuel qui ne pouvait pas fonctionner avec cette URL particulière.