Вход от нескольких приложений/процессов до единственного файла журнала
Наши серверы приложений (weblogic) все использование log4j для входа в тот же файл на сетевом ресурсе. Вдобавок к этому у нас есть все веб-приложения в управляемом входе сервера ошибки к общему error.log. Я не могу предположить, что это - хорошая идея, но требуемый для получения известия от некоторых профессионалов. Я знаю, что каждое веб-приложение имеет свой собственный classloader, таким образом, любая синхронизация потока только происходит в рамках приложения. Таким образом, что происходит, когда несколько процессов начинают сходиться на единственном файле журнала? Мы можем ожидать вкрапленные операторы журнала? Проблемы производительности? Что относительно нескольких веб-приложений, регистрирующихся к общему файлу журнала? Средой является Солярис.
6 ответов
Вообще говоря, отсутствие синхронизации записи - плохая идея. доступ к файлу и, конечно, плохая практика программирования. Единственный случай, когда это может сработать, - это добавление к файлу на локальной машине - все просто добавляют строки в конец файла.
Но поскольку ваш файл находится в общей сетевой папке, он, вероятно, быстро превратится в мусор. Вы не указали, какую распределенную файловую систему вы используете, но для NFS вы можете найти следующее объяснение на странице руководства open (2):
O_APPEND Файл открывается в режиме добавления. Перед каждой записью () смещение файла позиционируется в конце файла, , как при использовании lseek (). O_APPEND может привести к повреждению файлов в файловых системах NFS , если несколько процессов добавляют данные в файл одновременно. Это связано с тем, что NFS не поддерживает добавление в файл, поэтому клиентское ядро должно имитировать это, что невозможно без гонки состояние.
Конечно, это C, но поскольку Java реализована на C, она не может сделать ничего лучше этого (по крайней мере, в отношении системных вызовов :-)).
Мы используем org.apache.log4j.net.SyslogAppender для входа на отдельную машину с помощью системного журнала, и это хорошо сработало для нас. Я бы порекомендовал изучить это как альтернативу.
Это похоже на действительно плохую идею (поврежденные журналы, неопределенность источника данной записи журнала - две причины, которые приходят на ум). Если вы используете Log4j в Weblogic таким образом, я предлагаю сделать это по инструкции . Это позволит вам без проблем использовать один файл для всего сервера приложений.
Предложение синхронизировать запись журнала для меня не имеет смысла, поскольку вы, по сути, блокируете все приложения на сервере приложений, когда они пишут журнал. Если запись ведется часто, это значительно замедлит работу.
Что касается нескольких серверов приложений, вам нужно использовать что-то другое, кроме ведения журнала на основе файлов, если вы хотите, чтобы все они были объединены. Есть несколько способов сделать это: один - войти в разные файлы и объединить их в другом процессе, но лучшим вариантом, вероятно, будет использование сетевого репозитория журналов, используя SocketAppender Log4j или какой-либо другой метод (Натан упоминает SyslogAppender, который отлично подходит, если вам нужен системный журнал), чтобы гарантировать, что доступ к файлам не будет поврежден.
В разумном режиме логбэк будет безопасно обрабатывать несколько JVM, возможно, на разных хостах, записывающих в один и тот же общий сетевой файл. Он может даже справиться с временными сбоями сети. Производительность должна быть вполне приемлемой для нескольких узлов, скажем, 4 или меньше. Вы можете заметить снижение производительности для 5 или более узлов.
Если это возможно, используйте разные файлы для каждого экземпляра. Это даст наилучший результат с наименьшими усилиями.
Альтернатива log4j имеет предусмотрительный режим для своего регистратора, который явно прыгает через обручи, чтобы гарантировать, что новые вещи записываются в конце файла. Я не думаю, что это будет работать на сетевых акциях тогда.
Если необходимо иметь центральное расположение ведения журнала, рассмотрите возможность настройки сервера, принимающего события журнала и записывая их в соответствующие файлы.Это гарантирует, что это только один процесс, фактически обращающийся к файловой системе, и позволит JVM помочь всем, что он может с точки зрения синхронизации и т. Д.
В лучшем случае я бы предположил, что у вас есть потенциальная проблема производительности с синхронизацией доступа к ресурсу файла журнала. В худшем случае возможны некоторые из сценариев, которые вы упомянули.
Я бы задал два вопроса: а) какова была желаемая цель с помощью этой конфигурации и б) можете ли вы найти лучшее техническое решение для достижения цели.
Я предполагаю, что у вас есть сисадмин, который хочет получить "единый файл журнала для системы". Файл брошен на сетевой ресурс, чтобы до него было легко добраться. Лучшим ответом для этой цели может быть несколько файлов, локальных для каждой системы и что-то вроде http://www.splunk.com/ для красивого монитора.