I'm using logging provided by Spring Boot in an application.yml like this:
logging:
file: log/info.log
level.com.mycompany.app: INFO
What I actually want is:
1) Log every DEBUG message from our application (com.mycompany.app) to debug.log,
(optional: every INFO message from the whole app / ROOT to debug.log, too)
2) log every INFO message from the whole app / ROOT to info.log
So in pseudo code, it should look like this:
logging:
level: DEBUG
file: debug.log
com.mycompany.app: DEBUG
level:
ROOT: INFO
file: debug.log
level:
ROOT: INFO
file: info.log
How can I achieve this? Please note, we're using SLF4j, not logback (I've read in other threads about logback for writing to multiple files).
Regards,
Bernhard
Related
First, I referenced this thread and this documentation, and various articles like this one, but I'm obviously missing something.
I have tried various combinations. What I currently have is
logging:
level.root: trace
file:
name: ${PWD}/logs/spring.log
max-size : 1MB
max-history : 3
total-size-cap : 2MB
pattern:
file : "%d{yyyy-MM-dd HH:mm:ss} %-5level [%thread] [%class{36}] - %msg%n"
console : ${logging.pattern.file}
rolling-file-name : ${PWD}/logs/archive.%i.log
also tried
logging.logback.rollingpolicy:
file-name-pattern : ${PWD}/logs/${spring.application.name}.%i.log
max-file-size : 2MB
With root log level set to TRACE the logs go over 2MB almost immediately.
It works fine when we use a separate XML file to configure logback, but we're trying to remove the need.
This is the best yaml logback configuration that's working for me with lot of difficulties:
logging:
file:
path: /Volumes/Local Disk/logs
name: spring.log
logback:
rollingpolicy:
total-size-cap: 1MB
max-history: 3
max-file-size: 1MB
file-name-pattern: /Volumes/Local Disk/logs/spring.%d{yyyy-MM-dd}.%d{HH:mm:ss.SSS}.%i.log.gz
level:
root: trace
Screenshot:
For a Spring Cloud Config Server project, we recently migrated from Spring Boot 2.1.8.RELEASE to 2.6.6. However, the application seemed to be flooded with below logs that eventually leads to k8s pod crashing/restarting. And the INFO log is generated each time /actuator/health from kube-probe is called.
2022-08-30 19:20:19.182 INFO [config-server,5bd83ee81e7d3ccb,e17a13026d9c85ee] 1 --- [nio-8888-exec-5] o.s.c.c.s.e.NativeEnvironmentRepository : Adding property source: Config resource 'file [{spring.cloud.config.server.git.basedir}/application.yml]' via location 'file:{spring.cloud.config.server.git.basedir}'
2022-08-30 19:20:19.543 INFO [config-server,7557d9d04d71f6c7,a3d5954fe6ebbab1] 1 --- [nio-8888-exec-8] o.s.c.c.s.e.NativeEnvironmentRepository : Adding property source: Config resource 'file [{spring.cloud.config.server.git.basedir}/application.yml]' via location 'file:{spring.cloud.config.server.git.basedir}'
...
Note that I have replaced the actual file path to config repo in the container with spring.cloud.config.server.git.basedir.
Is there something that we missed on how Spring Cloud Config Server behaves differently since the update? Or how to disable health check endpoint to add a property source? As EnvironmentController.java seems to be the culprit.
Within my Spring Boot application (loglevel=DEBUG) I do log against slf4j, jcl (commons logging), log4j and jul (java util logging). I do use following:
log4j-to-slf4j.jar
slf4j-log4j12.jar
commons-logging.jar
log4j.jar
jul-to-slf4j.jar
Running it on Tomcat (juli) it doesnt print the Spring Boot bannner.
We are using Tomcat with a Logging Bridge. This Logging Bridge contains a LoggingListener (that implments the org.apache.catalina.LifecycleListener) and does redirect every Log from System.out and System.err.
systemOut = System.out;
systemErr = System.err;
System.setOut(new PrintStream(new LoggingOutputStream(Level.DEBUG, systemOut), true));
System.setErr(new PrintStream(new LoggingOutputStream(Level.WARN, systemErr), true));
The execution of this code snipped is based on a class attribute flag (private boolean redirectSystemLogs) which is always true - I tried to steer this flag from outside (tomcat clathpath) but didnt succeed. And still I would expect that with loglevel DEBUG I should be able to see the spring banner in the logs.
You have to tell it to print to the log file and not the console. In your application.yml:
spring:
main:
banner-mode: log
https://docs.spring.io/spring-boot/docs/current/api/org/springframework/boot/Banner.Mode.html
🐞 Bug report ??
image
logging:
level:
com.zaxxer.hikari: DEBUG
org.springframework: INFO
org.kafka.test: TRACE
file: "logs/%d{yyyy-MM-dd HH_mm_ss} pid-${PID}.log"
pattern.console: "%d{HH:mm:ss} - %msg%n"
Hello.
please help with the file name.
The time format does not work well.
I expected to see 1 file named "2020-02-07 10_38_40 pid-17996.log"
I got 2 files and the file names are bad.
Please do not advise using logback-spring.xml
I configure logs through .yml
I'm in the process of executing Maven commands to run tests in the console (MacOSX). Recently, development efforts have produced extraneous messages in the console (info, debug, warning, etc.) I'd like to know how to remove messages like this:
INFO c.c.m.s.c.p.ApplicationProperties - Loading application properties from: app-config/shiro.properties
I've used this code to remove messages from the dbunit tests:
ch.qos.logback.classic.Logger Logger = (ch.qos.logback.classic.Logger)LoggerFactory.getLogger("org.dbunit");
Logger.setLevel(Level. ERROR);
However, I'm unsure how to disable these additional (often verbose and irritating) messages from showing up on the console so that I can see the output more easily. Additional messages appear as above and these:
DEBUG c.c.m.s.c.f.dao.AbstractDBDAO - Adding filters to the Main Search query.
WARN c.c.m.s.c.p.JNDIConfigurationProperties - Unable to find JNDI value for name: xxxxx
INFO c.c.m.a.t.d.DatabaseTestFixture - * executing sql: xxxxx
The successful answer was:
SOLUTION: Solution to issue IS adding a 'logback-test.xml' file to the root of my test folder. I used the default contents (as instructed by the documentation - thanks #Charlie). Once file exists there, FIXED!