I Have a JHipster monolith application running successfully along with JHipster Registry. Everything is fine, I can see my application instance and all metrics.
But I get the following hint under the tab Administration/Logs:
No available logfile.
Please check:
- if the microservice is up
- these properties are set:
- logging.path
- logging.file (to avoid using the same spring.log)
See:
- https://docs.spring.io/spring-boot/docs/current/reference/html/production-ready-endpoints.html
- https://docs.spring.io/spring-boot/docs/current/reference/html/howto-logging.html
And a 404 Status response for /management/logfile
As already mentioned the service is running and in application-*.yml logging is set to
logging.file: /opt/tomcat/logs/shorty.log
The read permission for this file is shared by everyone.
Why I can't see the contents of the log file? Did I miss something?
Ok, my Spring Cloud Config was wrong. I had the additional logging.path property set.
But this seems not necessary with the default configuration. After removing this in application.yaml for JHipster Registry everything worked like a charm.
Related
So I want to override some settings for all my microservices, so I create a git repo and an application.yml file for that.
Download registry jar from jhipster.
run it with the following command.
java -jar jhipster-registry-5.0.2.jar --spring.profiles.active=prod --spring.security.user.password=xxx --jhipster.security.authentication.jwt.secret=abcde --spring.cloud.config.server.composite[0].type=git --spring.cloud.config.server.composite[0].uri=https://github.com/xxx --spring.cloud.config.server.composite[0].username=xxx --spring.cloud.config.server.composite[0].password=xxx
The services communicate through feign client which takes its data from the application.yml. The settings look like this:
application:
external:
services:
service-name:
base-url: local
But when I run the jhipster registry pointing to this repo. I get the following error.
Origin: ...
Reason: The elements [] are left unbound
I tried using all kinds of combos for the file name. application.yml, application-prod.yml, application-dev.yml, service-name.yml and also application.yml
There doesn't seem to be a problem for other properties, such as for database password and url. Or even arbitrary chains like abc.abc.abc.abc="data", these work. I even played around and simply messed up the spellings like mistyping external, services and application.
When I misspelled application like aaaaplication. It doesnt give an error. Only when I include "application:" in my yml file jhipster throws an error.
Please confirm if I am correct in assuming that jhipster won't allow application to be overriden. And if yes then how can I override this?
I don't think its optimal to change all the services for this. So is there a workaround for this?
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 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