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

> gunicorn有setting errorlog =“/ somepath / gunicorn-errors.log”
> nginx有setting error_log /somepath/nginx-errors.log;
>我的应用程序有一个InternalErrorView,其调度执行
无条件提升异常(“仅供测试.”)
该视图映射到URL / fail_now
>我没有修改handler500
>当我使用DEBUG = True运行我的应用程序并拥有我的浏览器请求时
/ fail_now,我看到通常的Django错误屏幕,包括
“只是为了测试.”信息.精细.
>当我使用DEBUG = False运行我的应用程序时,我得到一个包含的响应
仅仅是< h1>服务器错误(500)< / h1>,如预期的那样.精细.
>但是,当我查看gunicorn-errors.log时,没有条目
对于这个HTTP 500事件.为什么？我怎么才能得到它？
我想得到一个追溯.
>同样在nginx-errors.log中：没有500或/ fail_now URL的跟踪.
为什么？

奖金问题：
当我将其与原始生产问题进行比较时,我得到了
那里有不同的回应：9行文档
< h1>< p>内部服务器错误< / p>< / h1>作为中心信息.
为什么？

奖金问题2：
当我将我的数据库内容复制到我的登台服务器(这是相同的
在配置到生产服务器)和设置
在那里的Django中DEBUG = True,/ fail_now按预期工作,但是我原来的
问题仍显示为< h1>< p>内部服务器错误< / p>< / h1>.
WTF？

解决方法:

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

>< h1>服务器错误(500)< / h1>响应来自Django的
django.views.defaults.server_error(如果不存在500.html模板).
>< h1>< p>内部服务器错误< / p>< / h1>来自奖金问题
来自gunicorn的gunicorn.workers.base.handle_error.
> nginx在访问日志文件中记录500错误,而不是错误日志文件;
大概是因为它不是nginx本身就失败了.
>对于/ fail_now,gunicorn还会在访问日志中记录问题,
不是错误日志;大概是因为像枪炮一样
没有失败,只有应用程序有.
>我原来的问题确实出现在gunicorn错误日志中,
但我从来没有在那里寻找它,因为我有
刚刚引入了日志文件(我依赖于Docker日志
输出之前,这是非常令人困惑的)并假设它会
最好使用非常明确的InternalErrorView作为初始
调试. (这是一个有趣的想法.)
>但是,我的实际编程错误涉及发送响应
使用Content-Disposition标头(在Django代码中生成),如下所示：
附件;文件名= “DAG-wönnegården.pdf”.
特殊字符显然能够制作
当它处理这种反应时,gunicorn会绊倒.

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