Многопоточное безопасное ведение журнала

Question

У нас есть приложение, которое работает в нескольких потоках и использует Log4Net в качестве каркаса ведения журнала. Мы столкнулись со сценарием, в котором некоторые события журнала не были зарегистрированы. Как упоминалось в документации, FileAppender и другие Appenders « не безопасны для многопоточных операций». Я искал в Интернете решения или Appenders, но не смог их найти.
Знаете ли вы многопоточный безопасный Log4Net Appender, который использует кольцевой буфер или очередь для обеспечения многопоточной поддержки? Или нам вообще следует использовать другую многопоточную систему безопасного ведения журналов?
Заранее спасибо!

Answer 1

Я написал несколько модульных тестов, чтобы воспроизвести проблему: тест создает 50 потоков, и каждый поток регистрирует 500 сообщений. После этого письменные строки были подсчитаны, и в результате я получил 25 000 (50 x 500) строк в другом порядке. Я проверил его на двухъядерном и восьмиядерном компьютере.
Я тестировал статический регистратор:

private static ILog StaticLog = log4net.LogManager.GetLogger(RepositoryName, "Static logger");

и с регистратором для каждого экземпляра тестового класса / потока:

ILog instanceLog = LogManager.GetLogger(RepositoryName, "Instance logger: " + ThreadId.ToString());

И все тесты были зелеными.

Таким образом, Log4Net работает отлично и хорошо справляется со сценариями многопоточности. Документы Appender следует обновить и указать, что многопоточные операции поддерживаются, если Logger API используется правильно.

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

Спасибо за вашу помощь!

Answer 2

Я никогда не использовал FileAppender и не могу сказать, является ли он потокобезопасным, но у меня никогда не было проблем с RollingFileAppender . Документы утверждают, что члены типа не являются потокобезопасными, но это должно быть нормально, если вы не попытаетесь напрямую написать аппендиру. Вам не нужно добавлять свой собственный код блокировки для вызовов, таких как:

log.Info("message");

Answer 3

Log4Net является поточно-ориентированным, но используемые приложения могут быть проблемой. Файловые аппендеры делают "блокировку" при вызове. Это означает, что в вашем приложении каждый журнал, отправляемый в Log4Net, должен заполнять все приложения, прежде чем вернуться к вашему приложению.

Это поточно-ориентированный, многие потоки могут использовать Log4Net для регистрации сообщений, но там, где Log4Net вызывается, приложение ожидает завершения работы приложений. Время выполнения регистрации добавляется к времени вашего приложения.

Это легко доказать. Смотри: https://www.codeproject.com/Tips/1219696/Log-Net-Singleton-Wrapper-for-Concurrent-Logging

Что я сделал, так это "обернул" функции Log4Net в статический синглтон, который является поточно-ориентированным, и затем поместил каждое сообщение журнала в очередь, запущенную в параллельном потоке. Это делает всю запись в журнал одновременно с приложением, но выполнение приложения не ожидает завершения работы приложений.

Answer 4

То, что тесты зеленого цвета, не означает, что строки были действительно записаны в файл, но исключений не было. Или вы включили проверку, которая читает файл для этого в вашем тесте? Я столкнулся с той же проблемой после включения веб-садов в IIS. В этот момент только один поток записывал строки в файл.

Подробнее о нескольких потоках и log4net здесь: здесь и здесь