How to add permanent log channels.
Contents
- Clearing the history
How to clear obsolete historical versions.
- Clearing the image cache
How to keep the image cache small.
The Log files app offers numerous options for debugging issues on production servers. However, all configured log channles are lost after a server restart. The following section therefore explains how to configure permanent log channels.
You can activate permanent logging for selected features by adding two configurations to OpenCms' Log4j configuration file located at WEB-INF/classes/log4j2.xml. The file already contains configurations for the standard log files opencms.log, opencms-search.log and so on. One can add more configurations, though.
In order to do so, add two configuration elements:
- below the
/Configuration/Appenderspath, add another<RollingFile>configuration element - and below the
/Configuration/Loggerselement another<Logger>element
The example shows a configuration where the package org.opencms.ocee.cluster is logged into a file ocee-cluster.log on the info level and with a decided rolling strategy.
...
<RollingFile name="OCEECluster"
fileName="${sys:opencms.logfolder}ocee-cluster.log"
filePattern="${sys:opencms.logfolder}ocee-cluster.%i.log.gz">
<PatternLayout pattern="%d{DATE} %5p [%30.30C:%4L] %m%n" />
<Policies>
<SizeBasedTriggeringPolicy size="5 MB"/>
</Policies>
<DefaultRolloverStrategy max="10"/>
</RollingFile>
...
<Logger level="info" name="org.opencms.ocee.cluster" additivity="false">
<AppenderRef ref="OCEECluster"/>
</Logger>
...The folder where all log files live, can be referenced with the ${sys:opencms.logfolder} macro.
For more options see the Log4j documentation.
All resources in the virtual file system of OpenCms are versioned. The number of versions kept for each resource can be configured in WEB-INF/config/opencms-system.xml.
<versionhistory enabled="true" count="10" deleted="4" />Versions are not only kept for changed resources (see the @count attribute in the configuration example) but also for deleted resources (see the @deleted attribute) in order to restore them in exceptional cases.
The disadvantage of keeping deleted resources as historical versions is that, over time, many obsolete resources are stored in the database. This leads to unnecessary growth of the database and it can also have data protection implications if content is not permanently deleted.
It is recommended for production systems to configure a scheduled job that clears all historical versions from time to time.
The job is named org.opencms.scheduler.jobs.CmsHistoryClearJob.
Example
The job shown in the example deletes all historic versions every night at 2 o'clock.
The job does so for the whole VFS. If there was a Requested URI set, only the resources below this URI would be cleared.
The parameters in the example are configured as follows:
- clearDeleted=true: activates clearing of deleted resources
- keepTimeRange=7: clears versions older than 7 days
- keepVersions=-1: if older than 7 days, remove all versions and do not even keep the latest version
See here for a complete list of job configuration options.
All image derivatives requested on websites are stored in an image cache directory on the host file system for fast display.
To prevent the image cache directory from growing too large, older images should be deleted from time to time.
There is a scheduled job named org.opencms.scheduler.jobs.CmsImageCacheCleanupJob for this purpose.
The maxage job parameter defines the maximum age of cached images before they are deleted.