11

我记得获得了有序的日志文件,这样您就可以遵循一个请求,然后是下一个请求,依此类推。

现在,正如我 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

这令人抓狂,因为我无法在一个请求中说出发生了什么。

这是在乘客上运行的。

4

6 回答 6

4

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

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

于 2012-08-29T20:48:48.370 回答
4

如果您重视生产日志的可读性胜过其他一切,您可以使用

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)
于 2012-09-06T10:14:39.430 回答
3

是的!,他们已经做了一些更改,ActiveSupport::BufferedLogger所以不再等到请求结束来刷新日志:

但是他们添加了非常有趣的ActiveSupport::TaggedLogging 您可以在每条日志上添加任何您想要的标记。

在您的情况下,使用请求 UUID标记日志可能会很好,如下所示:

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

然后,即使日志被弄乱了,您仍然可以跟踪其中哪些与您正在跟进的请求相对应。

您可以使用此功能制作更多有趣的东西来帮助您进行日志研究:

于 2013-01-10T17:00:46.347 回答
3

好吧,对我来说,TaggedLogging 解决方案是行不通的,如果服务器严重崩溃,我可以忍受一些日志丢失,但我希望我的日志得到完美排序。因此,根据问题评论的建议,我将其应用于我的应用程序:

# 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

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

于 2013-02-01T12:10:23.453 回答
0

他们应该添加一些准随机 reqid 并将其写在关于单个请求的每一行中。这样你就不会迷茫了。

于 2012-09-06T10:49:10.450 回答
0

我没用过,但我相信Lumberjack 的unit_of_work方法可能就是你要找的。你打电话:

Lumberjack.unit_of_work do
  yield
end

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

于 2014-05-29T21:03:06.387 回答