Подтвердить что ты не робот

Rails 3.2.2 файлы журнала неупорядочены, запросы переплетаются

Я вспоминаю получение файлов журнала, которые были хорошо упорядочены, чтобы вы могли выполнить один запрос, затем следующий и т.д.

Теперь файлы журнала, так как мой 4-летний говорит, что "все заговорили", что означает, что они больше не являются отдельными четкими фрагментами текста. Логарифмы из двух запросов переплетаются/смешиваются.

Например:

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

Это безумие, потому что я не могу сказать, что происходит в рамках одного запроса.

Это работает на Пассажире.

4b9b3361

Ответ 1

Yep!, они внесли некоторые изменения в ActiveSupport::BufferedLogger, поэтому он больше не ждет, пока запрос не закончится, чтобы очистить журналы:

Но они добавили ActiveSupport:: TaggedLogging, что очень забавно, и вы можете штамповать каждый журнал любым желаемым значком.

В вашем случае может быть хорошо напечатать журналы с запросом UUID следующим образом:

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

Тогда даже если журналы перепутаны, вы все равно можете следить за тем, какие из них соответствуют запросу, за которым вы следуете.

Вы можете сделать более забавные вещи с этой функцией, чтобы помочь вам в изучении журналов:

Ответ 2

Я попытался найти тот же ответ, но не нашел никакой хорошей информации. Я не уверен, что вы должны исправить код сервера или рельсов.

Если вам нужна дополнительная информация об этой проблеме, это фиксация, которая удалила старый способ ведения журнала https://github.com/rails/rails/commit/04ef93dae6d9cec616973c1110a33894ad4ba6ed

Ответ 3

Если вы оцениваете читаемость журнала производства по всему остальному, вы можете использовать

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)

Ответ 4

Ну, для меня решение 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

Насколько я могу сказать, это не повлияло на мое приложение, оно все еще работает, и теперь мои журналы имеют смысл снова.

Ответ 5

Они должны добавить некоторые квази-случайные reqid и записать их в каждой строке относительно одного запроса. Таким образом, вы не смутитесь.

Ответ 6

Я не использовал его, но считаю, что метод Lumberjack unit_of_work может быть тем, что вы ищете. Вы вызываете:

Lumberjack.unit_of_work do
  yield
end

И все записи, сделанные либо в этом блоке, либо в уступленном блоке, помечены уникальным идентификатором.