“engine.*.*.log” files are generated when you consult logs through the Convertigo Web Administration Console widget.
These files are renamed files from the standard “engine.log.x” files to fit the widget syntax to parse log files (just “engine.log.x”).
If you don’t look at logs through Administration Console, you’ll never have those kind of files.
If you delete them you’ll loose some past logs.
It seems you changed the “Log4J audit appender max file size” property to 10 (without unit). That will create log files of 10KB size instead of default 10MB, was it intentional ? You may end up with a large amount of 10KB files, depending on logs level.
More “Logs” configuration are available in the “Config” widget of Administration Console, but can’t setup the way Logs widget is renaming the Log4j files.
We indeed changed the log config to 10 10KB files, only for test purpose. Production servers still have 100 10MB files configured.
In my opinion, log retention should only be provided by log4j managed files. These other files aren’t necessary other that to fit the widget syntax, so should be cleaned frequently, otherwise the growth will become a problem in Production environment.
Is it planned to add such a cleaning within Convertigo soon ?
These files are not duplicates of existing log4j files but only renamed ones, this will not double the occupied disk space as it is not new files.
I forgot to mention that in “Logs” widget you have a feature to purge logs older than a particular datetime (based on engine.xxx.yyy.log).
It is possible to call Convertigo Administration API to authenticate to the portal and then call the purge servlet.
Whereas this mechanism does not double the occupied disk space, it makes the applictaion more complex to maintain in Production environment, where the rule is to have all log files managed.
The logging configuration section of the Console thus covers only a part of logging and forces us to create a custom purge script.
Even if the API can provide a better way to purge a range of files based on a particular datetime, the problem remains the same :
we need a simple way to configure the log files creation and retention to prevent a unmanaged growth of the disk usage.