Nous utilisons une combinaison de formats de journaux dans nginx et lmon pour détecter ce genre de choses. Un format de journal NGINX comme :
log_format principal '$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_cache_status "in : $http_cookie"
Cela permet de capturer un grand nombre d'informations de diagnostic utiles, comme le serveur en amont qui a traité la demande, et de mettre l'état en avant pour qu'il soit facile à lire même si les journaux défilent rapidement.
Nous utilisons LMON pour surveiller ces journaux et nous alerter (pagers/email) 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 au moment où il se produit, ce qui est le moment le plus facile pour le déboguer.
L'autre chose que vous devriez probablement prendre en compte si vous ne l'avez pas déjà fait, c'est que par défaut, nginx considère qu'un 500 est une condition fatale et n'essaye pas un autre amont. Si vous avez plusieurs flux ascendants, vous pouvez configurer le serveur pour qu'il en utilise un autre s'il reçoit un 500, en espérant que l'utilisateur ne verra pas l'échec :
http://wiki.nginx.org/NginxHttpProxyModule#proxy_next_upstream
