I have set up my log configuration using logback.
The configuration sets up my logs in a rolling manner in a custom location. This means that I'm not using either:
"logging.file" or "logging.path" in my application.yml configuration, and as a consequence, the logfile endpoint no longer works.
Does anybody know of a way to customize this endpoint, so that I can point to the location/file specified in my logback.xml configuration?
Reading the two sections on Logging 26 & 74. It looks like it recommends using the logback-spring.xml config file with the base.xml configuration. With that you can still use the logging.file or logging.path application properties within the configuration. That way the /logfile endpoint is still valid for the current log file (probably won't look into the rolling files if that is what you setup).
You can specify the log file source from which the actuator will read.
To do that, try to use this property in your application.properties
endpoints.logfile.external-file=/var/log/app.log
or (based on your springboot version):
management.endpoint.logfile.external-file=/var/log/app.log
Related
I would like to run my Quarkus app in a container where the best practice is to only log to the console and not to a file.
How can I do that?
To disable logging, edit your application.properties file and add the following property:
quarkus.log.file.enable=false
By default Quarkus logs to both the console and to a file named quarkus.log.
In cases where writing to the log file is not necessary (for example when running a Quarkus app in a Kubernetes Pod), quarkus.log.file.enable=false can be used.
This property can be set either in application.properties or be overridden at runtime (using -Dquarkus.log.file.enable=false).
See this guide for more information about logging.
UPDATE
With this PR, logging to a file is now disabled by default.
I am setup to use logback with my SpringBoot application and everything is running fine and dandy.
I noticed a property called logging.path in the application.properties file which sets the value for ${LOG_PATH} in logback.xml. How does it do it?
I went through the SpringBoot logging documentation.
Any documentation I could find on property placeholder configurer
Yet I don't understand how logging.path could pass the value for ${LOG_PATH}. Though not a killer issue, I would like to know how this mapping is made.
The magic is spring will transfter logging.path into System propeties LOG_PATH.
Description from spring doc:
To help with the customization some other properties are transferred from the Spring Environment to System properties:
And it also says:
All the logging systems supported can consult System properties when parsing their configuration files. See the default configurations in spring-boot.jar for examples.
Details:
https://docs.spring.io/spring-boot/docs/1.5.6.RELEASE/reference/htmlsingle/#boot-features-custom-log-configuration
For more recent versions of Spring Boot, such as 2.5.x, the logging.file.path maps to LOG_PATH.
I have a setup where I am using the following:
Spring Boot 1.5.13 with Spring Cloud Version Edgware.S3
I have Spring Cloud Config Server and my Spring Boot apps are its clients
Each app carries a bootstrap.yml with the config server uri and some other properties.
Running containers on a Docker Swarm
I am currently passing Swarm secrets to the clients via a custom script which reads the files put into /run/secrets/ and creating a /config/bootstrap.properties file. It ends up looking like this:
spring.cloud.config.username=user
spring.cloud.config.password=password
My Docker image's default command is then this:
java -Djava.security.egd=file:/dev/./urandom -jar /${appName}.jar --spring.cloud.bootstrap.location=file:/config/bootstrap.properties"
Great. This is working without a problem. The app, seemingly, reads:
The external bootstrap.properties to read in the config server's credentials
The classpath bootstrap.yml to read in the rest of the config client props
Fetches and reads in the config server's application-appName.yml
Then reads the bundled application.yml from the classpath
Now. I'm moving the apps to Spring Boot 2.0.3 with Finchley.RELEASE and well, this breaks.
What is happening now is:
The external bootstrap.properties is read in to get the config server's credentials
The classpath bootstrap.yml is SKIPPED entirely (UNEXPECTED!)
Fetches and reads in the config server's application-appName.yml
Then reads the bundled application.yml from the classpath
The problem is that the properties that were set in the internal bootstrap.yml are now missing for the app so it blows up on start. I've been able to reproduce it outside the container environment by doing the same thing; point the app to an external bootstrap.properties. If I copy over the bootstrap.yml properties into the bootstrap.properties, then it works just fine. Also, if I don't provide an external properties file, then the internal bootstrap.yml kicks in without a problem. So it's either one or the other!
I'v also tried modifying the bootstrap location to include the default locations but no luck:
-- spring.cloud.bootstrap.location=file:/config/bootstrap.properties,classpath:,classpath:/config,file:,file:config/
Any ideas where to look next? Maybe there is a new spring.cloud.config property I'm missing? Or can anyone confirm which behavior is the correct behavior? Assuming they fixed a potential loophole in Finchley then I can just put this to rest and look for another solution. If it's 'broken' in Finchley, I guess an issue report is in order?
Well, some more digging showed that it looks like this is the new behavior:
https://github.com/spring-projects/spring-boot/wiki/Spring-Boot-2.0-Migration-Guide
The behavior of the spring.config.location configuration has been fixed; it previously added a location to the list of default ones, now it replaces the default locations. If you were relying on the way it was handled previously, you should now use spring.config.additional-location instead.
It didn't look to be Spring Cloud specific but I had nothing to lose.
Changing my java command to use this new property did the trick:
--spring.config.additional-location=file:/config/bootstrap.properties
Thanks.
I have a Spring boot application which use logback.xml for logging configurations.I am looking for options to dynamically change log level.
For instance if I have deployed an app with loglevel as ERROR,Let say I want to change this to INFO but I don't want to redeploy/restart my JVM.
Is there any possibility we can configure logback.xml like config server to achieve this
You can configure Logback to Automatically reloading configuration file upon modification
Yes, this is quite possible. Expose a rest endpoint where you supply the className and log level. With slf4j you can get the LoggerContext and change the level.
LoggerContext context = (LoggerContext) LoggerFactory.getILoggerFactory();
context.getLogger(className).setLevel(Level.valueOf(level));
Apache Commons logging and others have similar features.
If you are using spring cloud then you can have this in your yml file
logging:
level:
root: INFO
Then you can change it and refresh the configuration using actuator refresh to fetch new configuration changes no need to restart the service.
Also if you need some sort of UI to do this stuff you can explore the Spring-cloud-dashboard It is pretty cool and uses the features from the actuator to do and show you a lot of stuff not only changing log levels.
we put properties in a specific place(kept by zooKeeper, and already parsed into spring), not in classpath. Now in logback.xml, I need a DBAppender to log messages into mysql, I don't want to copy a properties into classpath, and I try to use placeholder ${url} directly without importing properties in logback.xml, it does not work.
So is there a way to use configuration in spring for logback?
No logback can only access system properties. And also logback tends to be intialised before spring, although you can cause it to be reconfigured.
Have a look at how spring-boot does it. It copies some (about 3 or 4) properties from spring config into system properties before re-initialising logback. In this way the log file path can be interpolated via spring properties and variable replacement.