log4net, могут ли 2 приложения записывать в один и тот же файл журнала?

Question

Возможно ли, чтобы 2 приложения записывали в один и тот же файл журнала с помощью log4net?

Answer 1

MinimalLock частично решает проблему (как упоминалось в @Mark), но если вы используете RollingFileAppender, вы столкнетесь с другими проблемами. Когда файл катится, вы можете оказаться в состоянии гонки, когда один процесс перезаписывает недавно созданный файл журнала другого процесса.

Другие опции включают RemoteLogger, где у вас есть простой сервер, настроенный на получение и запись событий регистрации, отправленных другими процессами. Кроме того, вы можете войти в базу данных SQL. Я написал простое приложение, которое регистрирует в Redis; вам нужно простое приложение для чтения из Redis и записи в файл. Проблема с этими подходами состоит в том, что они все вводят точку отказа. Когда что-то работает неправильно, чаще всего вам нужны журналы, и тогда они могут быть недоступны.

Таким образом, мое решение состояло в том, чтобы полностью избежать этой проблемы, передав каждый журнал процесса в отдельный файл. Это было легко сделать с изменением конфигурации. В вашей конфигурации (Rolling)FileAppender используйте:

<file type="log4net.Util.PatternString" value="c:\mylog-[%processid].txt" />

Идентификатор процесса становится частью имени файла. Да, это означает, что теперь у вас есть несколько файлов журналов, которые нужно прочесать, но агрегатор файлов журналов, такой как Graylog, Splunk или Logscape, может помочь.

Answer 2

Это зависит от FileAppender LockingModel . Если это ExclusiveLock , тогда другой процесс не сможет открыть файл для записи. Альтернатива - MinimalLock , но она не предназначена для этой цели. Он предназначен для того, чтобы позволить другому процессу переместить или удалить файл.

Answer 3

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

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

Answer 4

Да, это возможно, как указано выше, но я провел стресс-тестирование этого сценария.

Настройка довольно проста:

1. Веб-проект 1настроить страницу, на которой регистрируется одна запись, + кнопку, которая отправляет 1000 запросов на одну и ту же страницу, со счетчиком в URL-адресе (выбираемом оператором регистрации).
2. Веб-проект 2 настроен идентичнопротив одного и того же файла журнала.

Когда обе кнопки нажимаются одновременно, записи журнала чередуются по всему журналу.НО, а это большая GOTCHA, судя по сопровождающему счетчику запросов, ясно, что есть условия гонки.Почти каждый раз, когда один веб-проект регистрирует свою запись, другой отказывает (запись пропускается).

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

Тест был выполнен по умолчанию "MinimalLock".Я также переделал тест с «ExclusiveLock», но обнаружил, что первый веб-проект, настроивший регистратор, «победил», в основном блокируя ВСЕ другие запросы на регистрацию.Так что, очевидно, это тоже не пойдет.

Answer 5

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