#Logging in Spring Boot
1 messages Ā· Page 1 of 1 (latest)
Here is an AI assisted attempt to answer your question š¤. Maybe it helps! In any case, a human is on the way š. To continue talking to the AI, you can use </chatgpt:1108714622413963314>.
ught, should I log them at the point of occurrence or re-throw them to be logged at a higher level?
⢠What is the best way to configure logging in Spring Boot? Should I use logback, log4j2, or another logging framework?
⢠How can I control the level of logging for different parts of my application? Is it better to define log levels in each class or have a centralized configuration file?
⢠Is it necessary to use a separate logging library like SLF4J in addition to the default logging provided by Spring Boot?
In general, some best practices for logging in Spring Boot include:
⢠Use appropriate log levels (INFO, DEBUG, WARN, ERROR) based on the importance of the message.
⢠Log relevant information such as timestamps, thread names, and context information.
⢠Avoid excessive logging that can impact performance.
⢠Consider using structured logging for easier analysis and troubleshooting.
By following these best practices and considering the questions mentioned above, you can ensure effective and efficient logging in your Spring Boot application.
it depends on a nature of the code that's being run
sometimes exceptions simply resolve into a certain response status code
don't hide stack traces though, they are very useful
In a pre-container time I was using three different loggers:
- OPERATIONS - for the dev guis. technical stuff for the administrators of the system.
- BUSINESS - for the domain stuff needed for the business domain, most time only start/stop of workflows or workflow steps
- default java logging - for developers.
OPERATIONS and BUSINESS had only DEBUG, INFO, WARN, ERROR levels. INFO was the start/stop or domain object changes. DEBUG if they needed more info on the domain objects (like tracing the field values). WARN was a common business error that only affected the current workflow. ERROR was an error that affected the whole system and rendered it not-working.
OPERATIONS contained stack traces, BUSINESS never got them.
the java logging was only for us devolpers when we were called as third level support. there the full range of levels were in and normally I had a lot of TRACE ...
now in a containerized world where logging is captured by STDIN/STDERR, I try to mimic it only on the levels. TRACE is developers-only stuff, DEBUG is for OPERATORS debugging a production problem. INFO is status of the workflow stuff, WARN and ERROR basically stay the same (a local problem for a single request and a global problem with the system basically being down).
I created this system since I had been a system operator before going into development and always dreaded the logging of developers being only meaningful for devs and almost non-understandable to ops guys. So I tried to be better :-).
@supple valley
Your question has been closed due to inactivity.
If it was not resolved yet, feel free to just post a message below
to reopen it, or create a new thread.
Note that usually the reason for nobody calling back is that your
question may have been not well asked and hence no one felt confident
enough answering.
When you reopen the thread, try to use your time to improve the quality
of the question by elaborating, providing details, context, all relevant code
snippets, any errors you are getting, concrete examples and perhaps also some
screenshots. Share your attempt, explain the expected results and compare
them to the current results.
Also try to make the information easily accessible by sharing code
or assignment descriptions directly on Discord, not behind a link or
PDF-file; provide some guidance for long code snippets and ensure
the code is well formatted and has syntax highlighting. Kindly read through
https://stackoverflow.com/help/how-to-ask for more.
With enough info, someone knows the answer for sure š