Limiting console log output

[holub]

I need to limit console log output to WARN level. At the same time the file log must contain the whole data.
In my project I achieve this functionality by replacing default logback configuration with:

  <property name="CONSOLE_THRESHOLD" value="${logging.threshold.console:-TRACE}"/>
  <appender name="CONSOLE" class="ch.qos.logback.core.ConsoleAppender">
    <filter class="ch.qos.logback.classic.filter.ThresholdFilter">
      <level>${CONSOLE_THRESHOLD}</level>
    </filter>
    <encoder>
      <pattern>${CONSOLE_LOG_PATTERN}</pattern>
      <charset>utf8</charset>
    </encoder>
  </appender>

It will be nice to have such a feature available in default configuration.

[dsyer]

We could add a filter to the console appender I suppose. I wonder if we really want to encourage people to do that though when console logging is the preferred channel for all apps.

[holub]

In case the application is running as a service, the system log is polluted with tons of messages from the console logs.
Another issue here is that we increase the pressure on the IO because we need to flush two files: one from logback file appender and second system out from the console.

[snicoll]

Why don't you use logging.path which will eliminate console logging completely?

[holub]

@snicoll I don't understand why setting logger.path disable output from console appender?

[snicoll]

Yeah ignore me, I thought console log would be disabled when one uses logging.path but it logs in both. Maybe we could add a flag to do that. Thoughts @dsyer ?

[vpavic]

IMO it would be nice to have the ability to configure logging root levels, both for console and file loggers.
Something like logging.root-level.console and logging.root-level.file.

I can create the PR if this change is welcome.

[holub]

You can also discuss this request: #4379

[vpavic]

I've got this change implemented in my fork, take a look at this commit.

Not sure if the naming of new properties is the ideal so I'm a little hesitant about submitting the PR as is.

This feature is quite useful for users who install their Spring Boot apps as services and it would be nice if it could make the 1.3.0.RELEASE together with Unix/Linux services support.

[philwebb]

Since it's possible to configure what you need directly we think it's best that we don't add any additional properties at this time.