带有gunicorn和nginx的Django:HTTP 500没有出现在日志文件中

Question

我有一个Django应用程序在gunicorn服务器上运行,前面有一个 nginx.我需要使用HTTP 500结果诊断生产失败,但错误日志文件不包含我期望的信息.正是如此:

gunicorn有环境 errorlog = "/somepath/gunicorn-errors.log"
nginx有设置 error_log /somepath/nginx-errors.log;
我的应用程序有一个InternalErrorView在dispatch其中确实无条件raise Exception("Just for testing.") 这一观点被映射到URL/fail_now
我没有修改过 handler500
当我用DEBUG=True我的浏览器请求运行我的应用程序时/fail_now,我看到通常的Django错误屏幕,包括"Just for testing."消息.精细.
当我运行我的应用程序时DEBUG=False,我得到的响应只包含<h1>Server Error (500)</h1>,正如预期的那样.精细.
但是,当我查看时gunicorn-errors.log,根本没有HTTP 500事件的条目.为什么？我怎么才能得到它？我想得到一个追溯.
同样在nginx-errors.log:没有500或/fail_nowURL的痕迹. 为什么？

奖金问题: 当我将其与我原来的生产问题进行比较时,我得到了一个不同的响应:一个9行文档 <h1><p>Internal Server Error</p></h1>作为中心消息. 为什么？

奖金问题2: 当我将我的数据库内容复制到我的登台服务器(配置与生产服务器相同)并DEBUG=True在那里设置 Django时,/fail_now按预期工作,但我原来的问题仍然显示为<h1><p>Internal Server Error</p></h1>. WTF？

Answer 1

好吧,花了很长时间,但我发现了一切:

在<h1>Server Error (500)</h1>响应来自Django的 django.views.defaults.server_error(如果没有500.html模板存在).
在<h1><p>Internal Server Error</p></h1>从奖金问题来自gunicorn的gunicorn.workers.base.handle_error.
nginx在访问日志文件中记录500错误,而不是错误日志文件; 大概是因为它不是nginx本身就失败了.
因为/fail_now,gunicorn还会在访问日志中记录问题,而不是错误日志; 大概是因为枪炮本身没有失败,只有应用程序有.
我原来的问题确实出现在gunicorn错误日志中,但我从来没有在那里搜索它,因为我刚刚引入了日志文件(之前我曾依赖Docker logs 输出,这非常令人困惑)并且认为它会更好使用非常明确InternalErrorView的初始调试.(这是一个有趣的想法.)
但是,我的实际编程错误包括发送带有Content-Disposition标头的响应(在Django代码中生成),如下所示: attachment; filename="dag-wönnegården.pdf".特殊角色显然能够在处理这种反应时使炮弹绊倒.

写这个问题对诊断这种情况有很大帮助.现在,如果这个响应有助于其他人,那么StackOverflow魔法再次起作用.