Question

我记得收到订单很好的日志文件，这样你就可以关注一个请求，然后关注下一个请求，依此类推。

现在，日志文件是，正如我4岁时所说的“所有人都被嘲笑”，这意味着他们不再是独立的，不同的文本块。来自两个请求的记录交织在一起/混合在一起。

例如：

Started GET /foobar
...
Completed 200 OK in 2ms (Views: 0.4ms | ActiveRecord: 0.8ms)
Patient Load (wait, that's from another request that has nothing to do with foobar!)
[ blank space ]
Something else

这令人抓狂，因为我不知道在一个请求中发生了什么。

这是在乘客上运行。

Answer 1

我试图搜索相同的答案，但无法找到任何好的信息。我不确定您是否应修复服务器或rails代码。

如果您想了解有关此问题的更多信息，请参阅删除旧记录方式的提交https://github.com/rails/rails/commit/04ef93dae6d9cec616973c1110a33894ad4ba6ed

Answer 2

如果您重视其他所有内容的生产日志可读性，则可以使用

PassengerMaxInstancesPerApp 1

配置。它可能会导致一些扩展问题。或者你可以在application.rb中填写类似的内容：

process_log_filename = Rails.root + "log/#{Rails.env}-#{Process.pid}.log"
log_file = File.open(process_log_filename, 'a')
Rails.logger = ActiveSupport::BufferedLogger.new(log_file)

Answer 3

是的！，他们在ActiveSupport::BufferedLogger做了一些更改，所以在请求结束后不再等待刷新日志了：

但是他们已经添加了ActiveSupport::TaggedLogging，这非常有趣，您可以标记每个日志都有您想要的任何标记。

在您的情况下，使用请求UUID 标记这样的日志可能会很好：

# config/application.rb
config.log_tags = [:uuid]

然后，即使日志搞砸了，您仍然可以按照其中哪一项与您要跟进的请求相对应。

您可以使用此功能制作更多有趣的内容，以帮助您进行日志研究：

Answer 4

好吧，对我来说TaggedLogging解决方案是不行的，如果服务器崩溃严重，我可以忍受一些日志丢失，但我希望我的日志完全有序。所以，按照the issue comments的建议，我将其应用到我的应用中：

# lib/sequential_logs.rb
module ActiveSupport
  class BufferedLogger
    def flush
      @log_dest.flush
    end
    def respond_to?(method, include_private = false)
      super
    end
  end
end

# config/initializers/sequential_logs.rb
require 'sequential_logs.rb'

Rails.logger.instance_variable_get(:@logger).instance_variable_get(:@log_dest).sync = false

据我所知，这并没有影响我的应用程序，它仍在运行，现在我的日志再次有意义。

Answer 5

他们应该添加一些准随机reqid，并在每一行中写一个单一请求。这样你就不会感到困惑。

Answer 6

我没有用它，但我相信Lumberjack's unit_of_work method可能就是你要找的东西。你打电话：

Lumberjack.unit_of_work do
  yield
end

在该块或产生的块中完成的所有日志记录都标有唯一ID。

Rails 3.2.2日志文件无序，请求交织在一起

6 个答案: