Application Log Level Tips

Question

I am currently working in a large project with a large number of applications that communicate with each other.

My team and I manage and configure applications on the system with the necessary bug fixes and change requests. The system is used heavily, and applications use a lot of logging.

A typical example:

Messageclient

public void save(final Message message) { logger.info("Trying to save message: {}", message); boolean result = false; try { result = messageService.save(message); } catch (final MessageStoreException e) { logger.warn("Unable to save message {}", message, e); throw e; } catch (final Exception e) { logger.error("Unknown error when trying to save message!", e); } if (!result) { logger.warn("Could not save the message!"); } } 

MessageService

 public boolean save(final Message message) throws MessageStoreException { if (message == null) { throw new IllegalArgumentException("message!"); } final boolean result = messageStore.store(message); if (result) { logger.info("Stored: {}", message.getId()); } else { logger.warn("Unable to store: {}", message.getId()); } return result; } 

NOTE. I know that the sample code does not have better error handling, but it looks like this in many of the applications we manage.

Of course, this makes the log files VERY large.

I would like to enable the info log level and the warn log level in the production environment and leave the error level turned on, so that the log files contain only unexpected errors that require attention, and nothing more.

Other developers do not like this idea, because they do not know how to follow the "application flow" when they look at the log files that look for errors and errors.

I understand these arguments, and I feel that I need some input from the community.

So what's the best thing here? Should we use information / warning log levels in the production environment or should we use only the error log? Or maybe both?

Thanks!

UPDATE: Applications run on several servers, and currently we write everything to a file (a regular log file for each application with RollingFileAppender ). It is a lot of work to start writing to the database, so this is not an option.

CONCLUSION: Logging is not entirely trivial. We will not disable information and warning levels (it was a pretty radical action), but instead, as @jgauffin says, review and analyze business rules for applications that print "unnecessary" log messages.

Case is closed! Thank you all for your great contribution and good advice.

Answer 1

I would like to include information about the log level and the log level in the working environment and leave the error level turned on, so that the log files contain only unexpected errors that require attention and nothing more.

Other developers do not like this idea, because they do not know how to follow the "application flow" when they look at the log files that look for errors and errors.

This is a typical problem. Analyze logging:

 final boolean result = messageStore.store(message); if (result) { logger.info("Stored: {}", message.getId()); } else { logger.warn("Unable to store: {}", message.getId()); } 

This is indeed a problem because the team does not appear to be sure that it is a domain rule that can be stored in a message. I would most likely say that failure to store a message should really be an exception (and therefore an exception should be thrown out). But then again, I don't know anything about domain / business rules.

Such entries generally indicate that business rules are unclear. Therefore, a much better solution is probably to help the team analyze why the registration is so difficult. Is the application a lot of maintenance? Then it is probably better to remove the logging and other error checks (for example, arguments to the verification method) instead of turning log levels.

The comments of the commands that they cannot follow the stream without logging point to the same thing: the arguments are not checked so that the error is entered deep into, and not at the beginning of the application.

Answer 2

Have you considered journaling in different magazines. Transaction data in one log, where you can monitor transactions and log errors in another log. This will allow you to monitor the status of messages and have a log where it is easy to see what is going wrong.

Compare with the web server with the access log and the error log. I agree with your team that unless you have other means to track the flow, you will not be able to disable these messages in production.

Answer 3

You can enter the database. (It should not be so difficult to configure using the correct logging structure.)

From there, you can delete entries based on level and age. Update: First you register everything (including DEBUG if you want). After, say, one week, you delete the DEBUG messages. After a month, you delete the INFO messages. At this point, you have everything that is now stored in your files.

Bonus: if you suspect an error, you temporarily suspend deletion.

After maybe in a year you delete the rest.

Thus, you must be able to solve both needs: the required space and the stored information. This can be adjusted as needed.

Answer 4

Most of the installations I worked with included data, warnings, and error logs. We expect to see a bunch of registration info levels when the system starts up, and quite a bit after that. We expect that during normal operation, an error or warning message will not be logged - if any, because there are problems that need to be addressed.

You seem to be doing a little more information than this. You might consider changing some of them to debug the log, and then either turn it off or write it to a separate log file for errors and warnings.

However, is there a problem with large log files? Are you running out of disk? Having trouble finding useful information in them? If not, leave things as they are. If your problem finds useful information, I would focus on finding ways to work with large log files, rather than trying to reduce them. The information in a detailed log can be very useful in various ways, and there is no fundamental reason that size should be a problem.

Where I work now, we are moving towards investing more and more things in our magazines. Things that are currently processed through monitoring systems (the number of processed messages, timings of database queries, etc.) are moved to logs. Then we simply send all our logs to a central logstash instance, which allows us to easily find and analyze them. We can even generate metrics and warnings from the log stream, rather than process them in applications.

Answer 5

For a production environment, it is best to keep separate log files for the TRACE and ERROR log level.

In the TRACE log file, you can identify unwanted messages; delete these messages.