Log4Net и ведение журнала из параллельных экземпляров - PullRequest
11 голосов
/ 28 ноября 2009

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

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

Когда я использую "log4net.Appender.FileAppender + MinimalLock" , есть случаи потери информации. Не все журналы обоих экземпляров сохраняются в файл.

Как я могу решить эту проблему и записать информацию из параллельных экземпляров? А как насчет снижения производительности при использовании опции «MinimalLock»?

Спасибо. Надеюсь на вашу помощь.

Ответы [ 6 ]

18 голосов
/ 11 октября 2010

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

<appender name="MyRollingFileAppender" type="log4net.Appender.RollingFileAppender">
  <file type="log4net.Util.PatternString">
    <conversionPattern value="log_%processid.log" />
  </file>
<!-- ... -->
3 голосов
/ 01 декабря 2009

Я думаю, что это типичная ситуация, когда желательно централизованное ведение журнала. Вместо того, чтобы беспокоиться о файлах и страдать от узких мест в производительности, я бы предпочел асинхронно передавать операторские журналы некоторым удаленным сервисам, которые позаботятся о хранении и обработке журналов. Взгляните на этот агрегатор журналов под названием logFaces , он был разработан с целью отделения приложений от управления их журналами. Он должен работать со стандартным приложением log4net UDP и будет разбивать ваши журнальные данные по приложениям, хостам, потокам и т. Д., Позволяя создавать файлы журналов в любое время, когда они действительно необходимы.

Раскрытие информации : я являюсь автором этого продукта.

0 голосов
/ 10 декабря 2015

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

log4net.Appender.FileAppender+InterProcessLock
0 голосов
/ 28 ноября 2009

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

0 голосов
/ 28 ноября 2009

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

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

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

Более сложный механизм, но он может обеспечить высокопроизводительный путь ведения журнала: написать службу ведения журнала, которая получает строки журнала через TCP или UDP. Служба будет отвечать за буферизацию данных и их запись на диск. В прошлом мы использовали этот подход (не через Log4Net, а как общее решение) для повышения эффективности записи журналов.

0 голосов
/ 28 ноября 2009

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

...