This article is the first in a series on managing Alfresco log files. In this introduction we explain why it is not practical to configure logging in Alfresco and provide a better approach. The other two articles in the series will share implementation details for Windows and Linux systems. 

Clearing in Alfresco Can Be a Pain

There are at least six different kinds of logs, three different ways to produce them, three different directories to store them, and four separate configuration files. These numbers don’t include the logs produced by the plethora of new services developed by Alfresco.

In theory, you could configure all the Alfresco related loggers to stop them from mushrooming and eating up all the disk space. Depending on the configuration, you could also configure most of the four loggers separately. However, some settings could be overwritten in the next deployment or upgrade. Even if you were brave enough to configure those components, you couldn’t configure a rolloff policy in catalina.out, which is a redirect of the standard output.

Understanding Alfresco Logs

This is a quick introduction to Alfresco logs. This information is useful to gain a better understanding of how each log is produced, its purpose, and why they seem to be rolled out so differently.  If you don’t need the background, you can skip directly to What Can Be Done.

Different components of ACS use different methods to produce the following logs:

• Log4j – Logs including alfresco.log, share.log, and solr.log are produced using the Apache Log4j library.
• Console redirect – The log catalina.out is the most complete log, but it does not include everything.
• JULI logger – Apache Tomcat uses this logger to produce logs like host-manager.log, localhost.log, localhost_access_log.txt, and manager.log. On Windows, the catalina.*.out file is created by the JULI logger.

Logs created via Log4j

Log4j has a configurable property, MaxBackupIndex, that controls how many logs to keep. Only the Solr out of box configuration includes a MaxBackupIndex.

alfresco.log

Out of box configuration is in <tomcat root>/webapps/alfresco/WEB-INF/classes/log4j.properties. This configuration can be extended placing a file name *-log4j.properties at <tomcat root>/shared/classes/alfresco/extension. There is an out of the box daily rollover, but no roll off for the alfresco.log.

share.log

This is configured in <tomcat root>/webapps/share/WEB-INF/classes/log4j.properties. In contrast with alfresco.log, there is no way to extend this file out of the webapps directory.  Axel Faust has developed an addon for this issue. There is a daily rollover but no out-of-the-box roll off.  

solr.log

This is configured in <alfresco-search-service root>/logs/log4j.properties. Below you will see some sub-optimal default settings for file size, but it does have a roll off configured. We’d go for something bigger than 4MB for max size before rollover.

#- size rotation with log cleanup.
log4j.appender.file=org.apache.log4j.RollingFileAppender
log4j.appender.file.MaxFileSize=4MB
log4j.appender.file.MaxBackupIndex=9

See the log4j documentation (version 1.2 for our example) for more exciting features.

Logs created via Console Redirect

On Linux, catalina.out is a redirect of stdout from the catalina start command. There is no out-of-the-box rollover or roll off.

Logs created via JULI

Tomcat uses the JULI logger, which is a branch of Apache Commons Logging. It is configured in <tomcat home>/tomcat/conf/logging.properties. This logger can be configured to roll off logs via the org.apache.juli.FileHandler.maxDays property, which specifies the maximum age of a log. Roll off is not configured out of box. See the Tomcat logging documentation for more details.

Other logs

Alfresco has been developing more services and components, each of them producing even more logs. Some of these examples include Alfresco Process Services, Alfresco Identity Services, Alfresco Transformation Services, ActiveMQ, and more.

What Can Be Done

We can configure all Alfresco related loggers to have a roll off. This would involve modifying files such as log4j.properties, logger.properties, and others specific to each application. Some applications provide extension points, while applications like share.log are embedded in the application. Still, not everything can be configured. For example, the file catalina.out is a simple stream redirect that can’t be configured to be rolled off.

In response to the madness of the internal method, or modifying the different logging configuration files, our colleague Glenn Merrill found an external method. This method doesn’t touch the configuration files, and uses the tools and utilities provided by the operating system. We will explain how to implement the external method in Windows and Linux in the next two articles.

Conclusion

Controlling log growth is critical to preventing performance issues and crashes. However, the configuration files do not provide a complete solution. The internal method is cumbersome, error prone, and adds complexity to the deployment, management, and upgrade process. In contrast, the external method centralizes and simplifies the control of the roll off process without touching the components’ configurations. 

Stay tuned for future articles and learn how to take control of the Alfresco logs in Windows and Linux. If you need help with something a bit more complicated, please consider using our support and consulting services. Thanks!