Ведение журнала из нескольких приложений / процессов в одном файле журнала

Question

Все наши серверы приложений (weblogic) используют log4j для входа в один и тот же файл на сетевом ресурсе.Помимо этого у нас есть все веб-приложения на управляемом сервере, регистрирующие ошибки в общий файл error.log.Я не могу представить, что это хорошая идея, но хотел услышать от некоторых профессионалов.Я знаю, что у каждого веб-приложения есть собственный загрузчик классов, поэтому любая синхронизация потоков происходит только внутри приложения.Так что же происходит, когда несколько процессов начинают сходиться в одном файле журнала?Можем ли мы ожидать чередующиеся записи в журнале?Проблемы с производительностью?Как насчет того, чтобы несколько веб-приложений входили в общий файл журнала?Окружающая среда - Солярис.

Answer 1

В разумном режиме logback будет безопасно обрабатывать несколько JVM, возможно, на разных хостах, записывая в один и тот же сетевой файл.Это может даже иметь дело с временными сбоями сети.Производительность должна быть вполне приемлемой для нескольких узлов, скажем, 4 или меньше.Для 5 и более узлов, которые сильно загружаются, вы можете заметить снижение производительности.

Answer 2

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

Но, поскольку ваш файл находится в общей сетевой папке, он, вероятно, быстро превратится в мусор.Вы не сказали, какую распределенную файловую систему вы используете, но для NFS вы можете найти следующее объяснение на странице man open (2):

O_APPEND Файл открывается в режиме добавления.Перед каждой записью () смещение файла помещается в конец файла, как будто с помощью lseek ().O_APPEND может привести к повреждению файлов в файловых системах NFS, если несколько файлов одновременно добавляют данные в файл.Это связано с тем, что NFS не поддерживает добавление к файлу, поэтому ядро ​​клиента должно имитировать его, что невозможно сделать без условия гонки.

Конечно, это C, но поскольку Javaреализован в C, он не может быть лучше (по крайней мере, в отношении системных вызовов: -)).

Answer 3

У нас есть требование, когда нам нужно создать один файл со всех управляемых серверов, на которых выполняется одно и то же приложение. Мы разработали сервер журналирования Java, который открывает порт и прослушивает событие журнала. мы использовали appender сокета *1001* log4j для записи журнала событий на тот же порт и создали один файл.

Answer 4

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

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

Если вы ДОЛЖНЫ иметь центральное местоположение для ведения журнала, рассмотрите возможность настройки сервера, принимающего события журнала и записывающего их в соответствующие файлы. Это обеспечит доступ к файловой системе только одному процессу и позволит JVM помочь во всем, что касается синхронизации и т. Д.

Answer 5

Это выглядит как очень плохая идея (поврежденные журналы, неопределенность источника данной записи журнала - две причины, которые приходят на ум). Если вы используете Log4j в Weblogic таким образом, я предлагаю сделать это по книге . Это позволит вам без проблем использовать один файл для всего сервера приложений.

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

Что касается нескольких серверов приложений, вам нужно использовать что-то кроме ведения журнала на основе файлов, если вы хотите, чтобы они все были консолидированы. Есть несколько способов сделать это, один из них - войти в разные файлы и объединить их с помощью другого процесса, но, вероятно, лучше использовать сетевой репозиторий журналов, используя SocketAppender Log4j или другой метод (Натан упоминает отлично подходит, если вы хотите Syslog), чтобы гарантировать, что доступ к файлу не будет поврежден.

Answer 6

Мы используем org.apache.log4j.net.SyslogAppender для входа на одну машину с помощью syslog, и это хорошо сработало для нас. Я бы рекомендовал рассмотреть это как альтернативу.

Answer 7

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

Я бы спросил два вопроса: а) Какова была желаемая цель с этим конфигом и б) Можете ли вы найти лучшее техническое решение для достижения цели.

Я предполагаю, что у вас есть системный администратор, который хочет получить "единый файл журнала для системы". Файл создается в общей сетевой папке, чтобы к нему было легко добраться. Лучшим ответом на поставленную цель может быть несколько файлов, локальных для каждой системы и что-то вроде http://www.splunk.com/ для хорошего монитора.