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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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