Question

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

gunicorn有setting errorlog = "/somepath/gunicorn-errors.log"
nginx有setting error_log /somepath/nginx-errors.log;
我的应用有一个InternalErrorView dispatch 无条件的raise Exception("Just for testing.") 该视图已映射到网址/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_now网址的跟踪。的为什么吗

奖金问题： 当我将其与原始生产问题进行比较时，我得到了那里有不同的回应：9行文档 <h1><p>Internal Server Error</p></h1>作为核心信息。的为什么吗

奖金问题2： 当我将我的数据库内容复制到我的登台服务器（这是相同的在配置到生产服务器）和设置在那里的Django DEBUG=True，/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"。特殊字符显然能够制作当它处理这种反应时，gunicorn会绊倒。

写这个问题对诊断这种情况有很大帮助。现在，如果这个回应有助于其他人， StackOverflow魔法再次发挥作用。

Answer 2

可能是服务器响应500登录在access_log而非错误日志

在nginx默认文件

中

access_log  /var/log/nginx/example.log;

我认为<h1><p>Internal Server Error</p></h1>是由生产中的nginx生成的。

在debug = False

引发异常被视为错误或http500，因此除非您更改了handler500的视图，否则将显示默认的500错误页面

debug = true 引发异常显示在花哨的djnago的调试页面

中

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

2 个答案: