Log4j: Один файл журнала за запрос

Question

У нас есть пакетное приложение weblogic, которое обрабатывает несколько запросов от потребителей одновременно. Мы используем log4j для регистрации пупок. Сейчас мы входим в один файл журнала для нескольких запросов. Будет утомительно отлаживать проблему для данного запроса, так как для всех запросов журналы находятся в одном файле.

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

Мы не можем начинать & каждый раз останавливать производственный сервер, чтобы исключить возможность использования переопределенного файла с отметкой времени или идентификатором запроса. Это то, что описано в следующей статье: http://veerasundar.com/blog/2009/08/how-to-create-a-new-log-file-for-each-time-the-application-runs/

Я также попытался играть с этими альтернативами:

http://cognitivecache.blogspot.com/2008/08/log4j-writing-to-dynamic-log-file-for.html

http://www.mail-archive.com/log4j-user@logging.apache.org/msg05099.html

Такой подход дает желаемых результатов, но он не работает правильно, если одновременно отправляется несколько запросов. Из-за некоторых проблем с параллелизмом журналы появляются здесь и там.

Я ожидаю от вас помощи. Заранее спасибо ....

Answer 1

Вот мой вопрос по этой же теме: dynamically creating & destroying logging appenders

Я следить за этим в потоке, где я обсуждаю делать что-то точно, как это, в списке рассылки Log4J: http://www.qos.ch/pipermail/logback-user/2009-August/001220.html

Ceci Gulcu (изобретатель log4j) не думал, что это была хорошая идея ... вместо этого вместо этого предложил использовать Logback.

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

Answer 2

Посмотрите на отправку SiftingAppender с помощью logback (преемник log4j), он предназначен для обработки создания добавок по критериям времени исполнения.

Если вашему приложению необходимо создать только один файл журнала за сеанс, просто создайте дискриминатор на основе идентификатора сеанса. Написание дискриминатора включает в себя 3 или 4 строки кода и, следовательно, должно быть довольно легко. Кричите в списке рассылки пользователя-пользователя, если вам нужна помощь.

Answer 3

Эта проблема обрабатывается очень хорошо Logback. Я предлагаю выбрать его, если у вас есть свобода.

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

Чтобы разделить файлы на requestId, вы могли бы сделать что-то вроде этого:

Logback.XML

<configuration> 

    <appender name="SIFT" class="ch.qos.logback.classic.sift.SiftingAppender"> 
    <discriminator> 
     <key>requestId</key> 
     <defaultValue>unknown</defaultValue> 
    </discriminator> 
    <sift> 
     <appender name="FILE-${requestId}" class="ch.qos.logback.core.FileAppender"> 
     <file>${requestId}.log</file> 
     <append>false</append> 
     <layout class="ch.qos.logback.classic.PatternLayout"> 
      <pattern>%d [%thread] %level %mdc %logger{35} - %msg%n</pattern> 
     </layout> 
     </appender> 
    </sift> 
    </appender> 

    <root level="DEBUG"> 
    <appender-ref ref="SIFT" /> 
    </root> 

</configuration> 

Как вы можете видеть (внутри discriminator элемента), вы будете различать файлы, используемые для записи журналов на requestId. Это означает, что каждый запрос будет отправлен в файл, соответствующий requestId. Следовательно, если у вас было два запроса: requestId=1 и один запрос, где requestId=2, у вас было бы 2 файла журнала: 1.log (2 записи) и 2.log (1 запись).

На этом этапе вы можете задаться вопросом, как установить key. Это делается путем ввода пар ключ-значение в MDC (обратите внимание, что ключ соответствует один определенный в logback.xml файле):

RequestProcessor.java

public class RequestProcessor { 

    private static final Logger log = LoggerFactory.getLogger(RequestProcessor.java); 

    public void process(Request request) { 
     MDC.put("requestId", request.getId()); 
     log.debug("Request received: {}", request); 
    } 
} 

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