Подавить все выходные данные Logback для консоли?


Как я могу настроить Logback для подавления всего его вывода на консоль (стандартный вывод)? В частности, я хочу подавить (или перенаправить) собственные сообщения журнала Logback, такие как:

16:50:25,814 |-INFO in ch.qos.logback.classic.LoggerContext[default] - Could NOT find resource [logback-test.xml]
16:50:25,814 |-INFO in ch.qos.logback.classic.LoggerContext[default] - Found resource [logback.xml] at [file:/opt/dap/domains/ap0491/uat1/domain/instance-config/logback.xml]
16:50:25,816 |-WARN in ch.qos.logback.classic.LoggerContext[default] - Resource [logback.xml] occurs multiple times on the classpath.
16:50:25,816 |-WARN in ch.qos.logback.classic.LoggerContext[default] - Resource [logback.xml] occurs at [file:/opt/dap/domains/ap0491/uat1/domain/instance-config/logback.xml]
16:50:25,816 |-WARN in ch.qos.logback.classic.LoggerContext[default] - Resource [logback.xml] occurs at [file:/opt/dap/domains/ap0491/uat1/domain/instance-config/logback.xml]
16:50:25,923 |-INFO in ch.qos.logback.classic.joran.action.ConfigurationAction - debug attribute not set
16:50:25,924 |-INFO in ch.qos.logback.classic.turbo.ReconfigureOnChangeFilter@1a15291 - Will scan for changes in file [/opt/dap/domains/ap0491/uat1/domain/instance-config/logback.xml] every 60 seconds. 

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

Примечание я использую Logback 0.9.21, SLF4J 1.6.0, и наше приложение работает в WebLogic 10.3.2.

10 51

10 ответов:

эти сообщения отображаются только в том случае, если хотя бы одно из следующих значений истинно:

  • вы включили отладку в logback.xml-файл
  • у вас ошибка в конфигурации. Это так здесь-logback жалуется на несколько найденных файлов конфигурации.
  • существует проблема пути к классам, если ваша среда предоставляет конфликтующие файлы. (это пришло мне в голову вчера и было реальной причиной этого вопроса).
  • (есть баг в logback-случилось)

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

Хольгер Хоффштетте был прав в своем диагностика что повторяющееся сообщение записи classpath является признаком ошибка в том, как Logback подсчитывает записи classpath. Роберт Эллиот тоже характеризуется проблемы thread на Logback список рассылки пользователей. По словам Роберта и других в этом отношенииdisussion в списке рассылки SLF4J, когда приложение, которое использует Logback работает в WebLogic контейнер, из-за того, как работает загрузчик классов WebLogic, Logback сообщает о дублировании записей classpath для logback.xml файл конфигурации. Однако независимо от того, должен ли загрузчик классов WebLogic сообщать или не сообщать только уникальные записи пути к классам, Logback должен, безусловно, учитывать только уникальные записи пути к классам, чтобы он не печатал это запутанное, ложное сообщение.

я реализовал исправить на LBCLASSIC-159 что по сути делает то, что Роберт Эллиот рекомендует и использует набор вместо списка для хранения ресурсов, возвращаемых загрузчиком классов, эффективно устраняет любые повторяющиеся ресурсы пути к классам. Я успешно протестировал исправление с Logback 0.9.24, SLF4J 1.6.1 и WebLogic 10.3.2. Как и предсказывал Торбьерн в своем ответ, С этим исправлением на месте Logback больше не отображает повторяющиеся сообщения о состоянии записи classpath (или любые другие информационные сообщения) в стандартном режиме выход.

Я надеюсь, что сопровождающие будут интегрировать мое исправление в основной Logback репозиторий исходного кода и включить его в следующий релиз.

это" я тоже " ответ, Извините!

к счастью, я нашел решение (см. обновление) ниже.

в отличие от некоторых других ответов, я получаю поток конфигурации LogBack INFO сообщения, несмотря на отсутствие ERRORили WARNs в фазе конфигурации.

вот мои сообщения:

13:39:20,457 |-INFO in ch.qos.logback.classic.LoggerContext[default] - Could NOT find resource [logback.groovy]
13:39:20,457 |-INFO in ch.qos.logback.classic.LoggerContext[default] - Could NOT find resource [logback-test.xml]
13:39:20,457 |-INFO in ch.qos.logback.classic.LoggerContext[default] - Found resource [logback.xml] at [file:/home/carl/workspace-LSY/.metadata/.plugins/org.eclipse.wst.server.core/tmp0/wtpwebapps/IceProfile/WEB-INF/classes/logback.xml]
13:39:20,496 |-INFO in ch.qos.logback.classic.turbo.ReconfigureOnChangeFilter@14e2c9c - Will scan for changes in file [/home/carl/workspace-LSY/.metadata/.plugins/org.eclipse.wst.server.core/tmp0/wtpwebapps/IceProfile/WEB-INF/classes/logback.xml] every 60 seconds. 
13:39:20,496 |-INFO in ch.qos.logback.classic.joran.action.ConfigurationAction - Adding ReconfigureOnChangeFilter as a turbo filter
13:39:20,497 |-INFO in ch.qos.logback.core.joran.action.AppenderAction - About to instantiate appender of type [ch.qos.logback.core.ConsoleAppender]
13:39:20,501 |-INFO in ch.qos.logback.core.joran.action.AppenderAction - Naming appender as [STDOUT]
13:39:20,510 |-INFO in ch.qos.logback.core.joran.action.NestedComplexPropertyIA - Assuming default type [ch.qos.logback.classic.encoder.PatternLayoutEncoder] for [encoder] property
13:39:20,510 |-INFO in ch.qos.logback.core.joran.action.NestedComplexPropertyIA - Pushing component [encoder] on top of the object stack.
13:39:20,537 |-INFO in ch.qos.logback.classic.joran.action.RootLoggerAction - Setting level of ROOT logger to DEBUG
13:39:20,537 |-INFO in ch.qos.logback.core.joran.action.AppenderRefAction - Attaching appender named [STDOUT] to Logger[ROOT]
13:39:20,538 |-INFO in ch.qos.logback.classic.joran.action.LoggerAction - Setting level of logger [ch.qos.logback] to OFF
13:39:20,538 |-INFO in ch.qos.logback.classic.joran.action.LoggerAction - Setting additivity of logger [ch.qos.logback] to false
13:39:20,538 |-INFO in ch.qos.logback.classic.joran.action.ConfigurationAction - End of configuration.

вот моя конфигурация:

<configuration debug="true" scan="true"> 

  <appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender"> 
    <!-- encoders are  by default assigned the type
         ch.qos.logback.classic.encoder.PatternLayoutEncoder -->
    <encoder>
      <pattern>%d{HH:mm:ss.SSS} [%thread] %-5level %logger{36} - %msg%n</pattern>
    </encoder>
  </appender>

  <root level="debug">
    <appender-ref ref="STDOUT" />
  </root>

  <logger name="ch.qos.logback" level="OFF" additivity="false" />

</configuration>

это спам я не хочу, я считаю себя невиновным в том, что они вызвали и я был бы признателен за помощь в избавлении от него.

один из аспектов, в котором я могу быть "виновен", заключается в том, что я инициализирую свои регистраторы в static переменная; документы рекомендуют использовать переменные экземпляра вместо этого.

варианты:

  • logback-classic-0.9.24.банку
  • logback-core-0.9.24.банку
  • slf4j-api-1.6.1.банку
  • выполнение в приложении IceFaces 2.0, работающем в Tomcat 6.0 под Ubuntu 11.04

обновление

наконец-то понял, в чем проблема!

С документацию ответ Торбьерна):

Установка атрибута debug внутри элемента будет выводить информацию о состоянии, в предположении, что

  1. файл конфигурации найден
  2. файл конфигурации хорошо сформированный XML.

моя ошибка была

<configuration debug="true" scan="true"> 

в ретроспективе, ужас! Надеемся, эта информация поможет другим.

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

вы аппендер должен выглядеть что-то вроде

<appender name="CONSOLE" class="ch.qos.logback.core.ConsoleAppender">

 <filter class="ch.qos.logback.classic.filter.ThresholdFilter">
  <level>info</level>
 </filter>

 <encoder>
  <pattern>%d{yyyy-MM-dd} %d{HH:mm:ss} %.-1level %thread %logger{36}: %m%n</pattern>
 </encoder>

</appender>

Я написал в блоге о более полное описание того, что я изменил, что сработало для меня

Я не знаком с Logback. Но если это печать System.out или System.err, это просто общественная статический PrintStream переменные System класса. Вы могли бы подкласс PrintStream и установите системные выходные переменные в свой подкласс, тем самым контролируя, как он работает.

например:

public class NOPPrintStream extends PrintStream
{
    public NOPPrintStream() { super((OutputStream)null); }

    public void println(String s) { /* Do nothing */ }
    // You may or may not have to override other methods
}

public class MyClass
{
    public static void main(String[] args)
    {
        System.out = new NOPPrintStream();
        // Start program
    }
}

(этот код не тестировался)

в моем случае, у меня был "logback-тест.xml " в зависимом проекте, который был развернут как webapp jar. "Logback-тест.xml " файл начинается с

<configuration debug="false" scan="true">

атрибут 'scan="true "' породил эту ошибку:

ERROR in ch.qos.logback.classic.turbo.ReconfigureOnChangeFilter@716de067 - URL [jar:file:/C:/Local...cut.../WEB-INF/lib/My.Dev.jar!/logback-test.xml] is not of type file

что привело к 67 (!) дополнительные информационные линии.

удалив атрибут 'scan= "true", журнал logback полностью исчез.

собственно то, что тот же logback.расположение xml сообщается несколько раз, кажется, больше похоже на ошибку в logback, чем что-либо еще. Либо сообщите об этом в logback JIRA (здесь) или сначала проверьте, находится ли рассматриваемый jar на пути к классу несколько раз.

У вас, скорее всего, есть элемент, настроенный в вашем logback.XML. Вы можете удалить его, если вы не хотите никаких обновлений консоли о состоянии самой структуры ведения журнала. Тем не менее, Logback framework рекомендует не отключать его для устранения неполадок.

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

Я просто хочу добавить информацию о сообщении заголовка по умолчанию, добавленном в logback 1.0.2:

#logback.classic pattern: %d [%thread] %-5level %logger{36} - %msg%n

Я нашел это в logback news, но это было очень трудно найти.

Если вы хотите, чтобы удалить это сообщение, вы должны настроить outputPatternAsPresentationHeader в false:

<appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender">
    <encoder>
        <pattern>%d %-5level [%thread] %logger{0}: %msg%n</pattern>
        <!-- do not print pattern as a header -->
        <outputPatternAsPresentationHeader>false</outputPatternAsPresentationHeader>
    </encoder>
</appender>
<configuration>
<statusListener class="ch.qos.logback.core.status.NopStatusListener" />
</configuration>

просто используйте класс NopStatusLinstener, и это остановит самостоятельное ведение журнала logback.