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

Ответ 1

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

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

Ответ 2

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

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

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

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

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

Ответ 3

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

Ответ 4

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

Ответ 5

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

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

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

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

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

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