我有一个在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会绊倒.
写这个问题对诊断这种情况有很大帮助.
现在,如果这个回应有助于其他人,
StackOverflow魔法再次起作用.
标签：nginx,django,gunicorn 来源： https://codeday.me/bug/20190611/1219070.html
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。