nginx: ¿cómo puedo rastrear un 500 al azar de nginx (no es mi aplicación)? ¿Potencialmente tiene algo que ver con la carga?

Recientemente tuvimos unos 500 de nginx en sí que de alguna manera no se registraron (tenemos capturas de pantalla, pero nada en los registros). Eso es extraño en sí mismo, porque generalmente los errores aparecen allí. De todos modos, me pregunto si hay algo como un tamaño de grupo de conexiones que, si se maximiza, daría como resultado un 500. Lo hemos correlacionado potencialmente con un aumento reciente en el tráfico, pero no es concluyente.

¿Alguien tiene alguna idea de cómo comenzar a abordar este problema?

Utilizamos una combinación de formatos de registro en nginx y lmon para capturar cosas como esta. Un formato de registro NGINX como:

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_forwards_for" $ upstream_addr $ upstreamuscache_t en: $ http_cookie "'

Capturará una gran cantidad de información de diagnóstico útil, como el servidor ascendente que manejó la solicitud, y pondrá el estado en primer plano para que sea fácil de leer, incluso si los registros se desplazan bastante rápido.

Usamos LMON para ver estos registros y luego nos alerta (buscapersonas / correo electrónico) si ve errores, como 500, 503, 400, en los registros:

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

Esto puede ayudarlo a ser alertado de un problema cuando está sucediendo, que es el momento más fácil para depurarlo.

La otra cosa que probablemente debería considerar si aún no lo ha hecho es que, por defecto, nginx considera que un 500 es una condición fatal y no prueba con otro flujo ascendente. Si tiene múltiples flujos ascendentes, puede configurarlo para usar otro si obtiene un 500, con la esperanza de ocultar el fallo del usuario:

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

error_log $filename debug; activará el registro de nivel de depuración en el registro de errores; esto le dará muchos detalles del estado interno de nginx en el momento del error, y si se compila con --with-debug (que varias distribuciones hacen por defecto) Daré aún más.

Tenga en cuenta que el nivel de "depuración" realmente genera muchos resultados, hasta el punto de que es posible que desee ver su espacio en disco ...

En mi caso, el archivo conf no fue nombrado correctamente (era example.com en lugar de example.com.conf) y no fue incluido. De alguna manera, esto no resultó en 'Bienvenido a nginx' sino en un error HTTP 500 no registrado. Bueno, en realidad se registró, pero en el archivo de error de un host virtual diferente que no podía funcionar con esa URL en particular.