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

У нас есть пакетное приложение 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/[email protected]/msg05099.html

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

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


person Gaurav Saini    schedule 25.02.2010    source источник


Ответы (4)


Вот мой вопрос по той же теме: динамическое создание и удаление приложений ведения журнала

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

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

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

person Edward Q. Bridges    schedule 25.02.2010
comment
@eqbridges Вы использовали NDC в log4j? Я получил это от API log4j... Вложенный диагностический контекст, или сокращенно NDC, — это инструмент для различения чередующихся выходных данных журнала из разных источников. Вывод журнала обычно чередуется, когда сервер почти одновременно обрабатывает несколько клиентов. Чередующийся вывод журнала все еще может иметь смысл, если каждая запись журнала из разных контекстов имеет отличительную отметку. Здесь в игру вступают NDC. - person Gaurav Saini; 25.02.2010
comment
Я использовал NDC в прошлом. Это действительно правильное решение того, что вы пытаетесь сделать. Вы просто царапаете поверхность проблем, с которыми столкнетесь, если попытаетесь создать отдельный файл журнала для каждого запроса. - person Edward Q. Bridges; 09.03.2010

Взгляните на SiftingAppender, поставляемый с logback (преемником log4j). создание приложений по критериям времени выполнения.

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

person Ceki    schedule 05.03.2010

С этой проблемой очень хорошо справляется 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);
    }
}

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

person cegas    schedule 23.02.2018

с помощью файлаPattern

<?xml version="1.0" encoding="UTF-8"?>
<Configuration>
<Properties>
<property name="filePattern">${date:yyyy-MM-dd-HH_mm_ss}</property>
</Properties>
<Appenders>
<File name="File" fileName="export/logs/app_${filePattern}.log" append="false">
<PatternLayout
pattern="%d{yyyy-MMM-dd HH:mm:ss a} [%t] %-5level %logger{36} - %msg%n" />
</File>
</Appenders>
<Loggers>
<Root level="debug">
<AppenderRef ref="Console" />
<AppenderRef ref="File" />
</Root>
</Loggers>
</Configuration>
person user13773146    schedule 19.06.2020