跟踪导致超时的请求答案

【问题标题】：Track requests causing timeouts跟踪导致超时的请求
【发布时间】：2016-01-24 20:34:32
【问题描述】：

我在生产日志中遇到了很多这样的情况：

E, [2016-01-24T20:34:44.862096 #21631] ERROR -- : reaped #<Process::Status: pid 23077 SIGKILL (signal 9)> worker=10
E, [2016-01-24T20:34:44.862282 #21631] ERROR -- : worker=12 PID:23064 timeout (61s > 60s), killing
E, [2016-01-24T20:34:44.876932 #21631] ERROR -- : reaped #<Process::Status: pid 23064 SIGKILL (signal 9)> worker=12
I, [2016-01-24T20:34:44.895914 #23619]  INFO -- : worker=12 ready

我同时使用 New Relic 和 Honeybadger 来跟踪错误，但是由于 Unicorn 工人被杀，我无法弄清楚什么请求需要这么长时间。

我尝试实现this 博客文章中描述的中间件，但是在本地开发人员中测试时抛出以下错误：

I, [2016-01-24T21:22:08.453846 #63197]  INFO -- : [cc042b92-0530-4c9c-9503-73bba529fe20] Completed 200 OK in 1061ms (Views: 1016.8ms | ActiveRecord: 3.8ms)
F, [2016-01-24T21:22:08.458914 #63197] FATAL -- : [cc042b92-0530-4c9c-9503-73bba529fe20] 
ThreadError (killed thread):
  config/initializers/log_before_timeout.rb:19:in `run'
  config/initializers/log_before_timeout.rb:19:in `call'

我能做些什么来解决这个问题？或者，有没有更好的方法来检查这个？

顺便说一句我没有使用默认的 Rails 服务器（webbrick）在本地进行测试。

【问题讨论】：

标签： ruby-on-rails ruby-on-rails-4 rack unicorn

【解决方案1】：

使用它在确保块而不是thr.run 处运行线程

Thread.current.run

【讨论】：