Log4j vs Logback: одновременная запись в тот же журнал?

У меня есть несколько веб-приложений, работающих на одном и том же коте.

У меня есть два вопроса:

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

2- В библиотеке журнала есть разумный режим:

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

Я хочу знать, является ли использование Logback благоприятным только для нескольких JVM, или это также полезно для нескольких приложений, запущенных на одном и том же веб-сервере? Если нет, то он идентичен log4j в этом аспекте?

Спасибо

Ответ 1

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

Как уже упоминалось в документах, в разумный режим > logback FileAppender предотвратит повреждение даже при наличии других экземпляров FileAppender в тех же или разных JVM, потенциально работающих на разных хостах. По умолчанию режим осмотрительности отключен.

Консоль не может быть повреждена, поэтому вопрос спорный.

Ответ 2

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

При использовании серверов (и разных загрузчиков классов) в зависимости от развертывания и конфигурации может быть один экземпляр сервера или несколько экземпляров Log4j.

См. выше. Stdout может иметь одинаковую проблему с смешанным выпуском, но не при вращении файлов.
Режим бэкап-бэкапинга будет рассматривать одновременную запись разными экземплярами (то же JVM или нет). Если ваша конфигурация использует серверный экземпляр Log4j, для этого аспекта нет преимуществ.

Ответ 3

Да. В общем, ваш принцип должен заключаться в том, что вы пишете другой файл журнала для каждого приложения (сеть или нет). Альтернативой является то, что вы оставляете это на сервере, чтобы выбрать файл для записи. У JBoss есть способы для общего выхода из системы, который перейдет в тот же файл. Тем не менее, я по-прежнему предпочитаю иметь отдельный журнал для каждого приложения.
Насколько я знаю, как log4j, так и Logback стремятся быть минимальными в накладных расходах, они могут вызвать приложение, поэтому вряд ли это будет более выгодным. Если для вас важны несколько JVM, я считаю, что Logback лучше справляется с этим, но использование его вне этого - неплохая идея.

Ответ 4

Использование Filelocks никогда не является фактически эффективным/безопасным, поэтому, при работе в одном файле из разных приложений /JVM, это не рекомендуется. См. Конфигурацию, которую я взял непосредственно из logback-appenders-faq.

<configuration>
  <appender name="FILE" class="ch.qos.logback.core.rolling.RollingFileAppender">
    <!-- Support multiple-JVM writing to the same log file -->
    <prudent>true</prudent>
    <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">
      <fileNamePattern>logFile.%d{yyyy-MM-dd}.log</fileNamePattern>
      <maxHistory>30</maxHistory> 
    </rollingPolicy>

    <encoder>
      <pattern>%-4relative [%thread] %-5level %logger{35} - %msg%n</pattern>
    </encoder>
  </appender> 

  <root level="DEBUG">
    <appender-ref ref="FILE" />
  </root>
</configuration>

Ваши другие варианты для нескольких JVM, записывающих в какой-то единый источник, это SocketAppenders и JDBCAppender.

JDBCAppender будет полностью заменен в будущем, хотя и не рекомендуется. См. Logbacks список рассылки.

SocketAppenders может быть немного сырым, поскольку вы, вероятно, не планировали писать много кода для журнала.

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