Наши серверы приложений (weblogic) используют log4j для входа в тот же файл на сетевом ресурсе. Вдобавок к этому у нас есть все веб-приложения в ошибках ведения журнала управляемого сервера для общего error.log. Я не могу представить, что это хорошая идея, но хотелось услышать от некоторых профессионалов. Я знаю, что каждое веб-приложение имеет свой собственный загрузчик классов, поэтому любая синхронизация потоков происходит только в приложении. Итак, что происходит, когда несколько процессов начинают сходиться в одном файле журнала? Можем ли мы ожидать вкрапленные записи журнала? Проблемы с производительностью? Как насчет нескольких веб-приложений, регистрирующих общий файл журнала? Среда - это Solaris.
Вход в систему из нескольких приложений/процессов в один файл журнала
Ответ 1
Это общая плохая идея, чтобы не синхронизировать доступ на запись к файлу и, конечно, плохую практику программирования. Единственный случай, когда он может работать, - это добавить файл на локальный компьютер - все просто добавляются строки в конце файла.
Но, поскольку ваш файл находится в сетевом ресурсе, он, вероятно, быстро превратится в мусор. Вы не указали, какую распределенную файловую систему вы используете, но для NFS вы можете найти следующее объяснение на открытой (2) странице руководства:
O_APPEND Файл открывается в режиме добавления. Перед каждой записью() смещение файла позиционируется в конце файла, как будто с lseek(). O_APPEND может привести поврежденных файлов в файловых системах NFS если несколько процессов добавляют данные в файл сразу. Это связано с тем, что NFS не поддерживает добавление файла, поэтому ядро клиента должно моделировать это, что невозможно сделать без гонки состояние.
Конечно, это C, но поскольку Java реализован на C, он не может сделать ничего лучше (по крайней мере, не в отношении системных вызовов: -)).
Ответ 2
В разумный режим logback будет безопасно обрабатывать несколько JVM, возможно, на разных хостах, записывая их в один и тот же сетевой файл. Он может даже иметь дело с временными сбоями сети. Производительность должна быть вполне приемлемой для нескольких узлов, скажем, 4 или меньше. Для 5 или более узлов, все из которых регистрируются в значительной степени, вы можете заметить поражение в производительности.
Ответ 3
У нас есть требование, когда нам нужно создать один файл со всего управляемого сервера с тем же приложением. мы создали сервер регистрации Java, который открывает порт и прослушивает событие журнала. мы использовали log4j socket appender, чтобы записать событие журнала в тот же порт и создать один файл.
Ответ 4
Мы используем org.apache.log4j.net.SyslogAppender для входа на одну машину с использованием syslog, и это сработало для нас. Я бы рекомендовал изучить это как альтернативу.
Ответ 5
Это выглядит как действительно плохая идея (коррумпированные журналы, неопределенность источника данной записи в журнале - две причины, которые приходят на ум). Если вы используете Log4j в Weblogic, как это, я предлагаю сделать это by-the-book. Это позволит вам использовать один файл для всего сервера приложений без каких-либо проблем.
Предложение синхронизировать запись в журнале не имеет для меня никакого смысла, поскольку в основном вы блокируете все приложения на сервере приложений, когда они пишут журнал. Если регистрация ведется часто, это значительно замедлит все.
Как и для нескольких серверов приложений, вам нужно использовать что-то другое, кроме записи на основе файлов, если вы хотите, чтобы все они были объединены. Существует несколько способов сделать это, один из них заключается в том, чтобы регистрироваться в разных файлах и комбинировать их с другим процессом, но лучшим вариантом является, вероятно, использование репозитория регистрации на основе сети, используя Log4j SocketAppender или какой-либо другой метод (nathan упоминает SyslogAppender, который отлично, если вы хотите Syslog), чтобы гарантировать, что доступ к файлам не будет поврежден.
Ответ 6
В лучшем случае я бы предположил, что у вас есть потенциальная проблема с производительностью при синхронизации с ресурсом файла журнала. Худший случай - это некоторые из описанных вами сценариев.
Я бы попросил два Qs: a) какова была желаемая цель с этой конфигурацией и b) вы можете найти лучшее техническое решение для достижения цели.
Я предполагаю, что у вас есть системный администратор, который хочет получить "единственный файл журнала для системы". Файл будет передан на сетевой ресурс, чтобы было легко добраться. Лучшим ответом для цели может быть несколько файлов, локальных для каждой системы и что-то вроде http://www.splunk.com/ для хорошего монитора.
Ответ 7
Если это возможно, используйте для каждого экземпляра другой файл. Это даст лучший результат с наименьшими усилиями.
Альтернативой log4j для журнала является разумный режим для его автора журнала, который явно перескакивает через обручи, чтобы гарантировать, что новые вещи будут записаны в конце файла. Я не думаю, что тогда будет работать на сетевые ресурсы.
Если вы ДОЛЖНЫ иметь центральное место ведения журнала, подумайте о настройке сервера, принимающего события журнала, и записи их в соответствующие файлы. Это гарантирует, что только один процесс фактически обратится к файловой системе и позволит JVM помочь всем, что он может, с точки зрения синхронизации и т.д.