Configure webapp logging

This section describes how to configure Abiquo webapp logs to reduce the size of these files and periodically delete old files. Customers must determine their own logging requirements and configure the webapp logs in their environment appropriately.

Abiquo Log Documentation

The Abiquo Logs are described in detail in the Troubleshooting section of the Abiquo wiki for each version of Abiquo.

Log Files

A current log is created for each webapp in the directory \{catalina.base}/logs/

In a standard install, this is /opt/abiquo/tomcat/logs. The logs are named after the webapps and renamed with date information when they are rotated.

In Abiquo the log files have the format *.log, for example:

am.log
api.log
bpm-async.log
catalina.out
nars.log
ssm.log
virtualfactory.log
vsm.log

Configuration Files

The logback config file is in WEB-INF/classes in each webapp directory and can be edited.

For example, for the nodecollector webapp, the default file would be /opt/abiquo/tomcat/webapps/nodecollector/WEB-INF/classes/logback.xml

Log Level Example

The default logback.xml file for the VSM in Abiquo 2.4 is shown here. Note that some of the loggers are set to a log level of TRACE, (in the example below: com.abiquo and akka). This can create large amounts of log data. A log level of DEBUG should be sufficient for most Abiquo installations.

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
        <appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender">
                <layout class="ch.qos.logback.classic.PatternLayout">
                        <Pattern>%d{HH:mm:ss.SSS} %-5level %logger{36} %X{akkaSource} - %msg%n</Pattern>
                </layout>
                <filter class="ch.qos.logback.classic.filter.ThresholdFilter">
                        <level>DEBUG</level>
                </filter>
        </appender>
        <appender name="FILE"
                class="ch.qos.logback.core.rolling.RollingFileAppender">
                <file>${catalina.base}/logs/vsm.log</file>
                <layout class="ch.qos.logback.classic.PatternLayout">
                        <Pattern>%d{HH:mm:ss.SSS} %-5level %logger{36} %X{akkaSource} - %msg%n</Pattern>
                </layout>
                <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">
                        <fileNamePattern>${catalina.base}/logs/vsm-%d{yyyy-MM-dd}.%i.log
                        </fileNamePattern>
                        <timeBasedFileNamingAndTriggeringPolicy
                                class="ch.qos.logback.core.rolling.SizeAndTimeBasedFNATP">
                                <maxFileSize>50MB</maxFileSize>
                        </timeBasedFileNamingAndTriggeringPolicy>
                </rollingPolicy>
        </appender>
        <logger name="com.abiquo">
                <level value="TRACE" />
        </logger>
        <logger name="akka">
                <level value="TRACE" />
        </logger>
    <logger name="org.jinterop">
        <level value="ERROR" />
    </logger>
        <root>
                <level value="DEBUG" />
                <appender-ref ref="STDOUT" />
                <appender-ref ref="FILE" />
        </root>
</configuration>

Log Rotation Example

The following example shows the default logback rollingPolicy configuration for nodecollector

<rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">
  <fileNamePattern>${catalina.base}/logs/nodecollector-%d{yyyy-MM-dd}.%i.log</fileNamePattern>
  <timeBasedFileNamingAndTriggeringPolicy class="ch.qos.logback.core.rolling.SizeAndTimeBasedFNATP">
    <maxFileSize>50MB</maxFileSize>
  </timeBasedFileNamingAndTriggeringPolicy>
</rollingPolicy>

This configuration will rotate the logs daily or when the size of the file is larger than 50 MB. However, the standard configuration shown above means that the log files are kept indefinitely, which can cause the system disk to fill up.

So we suggest you specify the maxHistory parameter (as described on http://logback.qos.ch/manual/appenders.html).

The optional maxHistory property controls the maximum number of archive files to keep, deleting older files. For example, if you specify monthly rollover, and set maxHistory to 6, then 6 months worth of archives files will be kept with files older than 6 months deleted. Note as old archived log files are removed, any folders which were created for the purpose of log file archiving will be removed as appropriate.

Set the maxHistory size for each log file by adding a line after maxFileSize and replacing \{NUMBER OF FILES TO KEEP} with a suitable number, for example, 30.

logback.xml

<rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">
  <fileNamePattern>${catalina.base}/logs/nodecollector-%d{yyyy-MM-dd}.%i.log</fileNamePattern>
  <timeBasedFileNamingAndTriggeringPolicy class="ch.qos.logback.core.rolling.SizeAndTimeBasedFNATP">
    <maxFileSize>50MB</maxFileSize>
    <maxHistory>{NUMBER OF FILES TO KEEP}</maxHistory>
  </timeBasedFileNamingAndTriggeringPolicy>
</rollingPolicy>

To enable automatic log compression, set the filename extension as .gz for each log file. This will compress each log automatically to GZIP format each midnight with the daily rollover. For instance, if you want to compress nodecollector logs you would issue:

logback.xml

  <fileNamePattern>${catalina.base}/logs/nodecollector-%d{yyyy-MM-dd}.%i.log.gz</fileNamePattern>

Disk Requirements

This section describes how to calculate the disk space requirements for the webapp logs. Customers must determine their own logging requirements.

If you set the retention for webapps' logs to 30, the worst-case scenario for disk space is:

Monolithic

7 webapps * 50 MB max file size * 30 rotations by day or size = 10.5 GB

Catalina, rotates weekly or when size > 100 MB, 10 rotations kept = 1 GB

This space should be reserved on /opt/abiquo/tomcat/logs. Abiquo recommends that customers should create a isolated logicalvolume of approximately 15 GB and mount it on the /opt/abiquo/tomcat/logs path.

Changes apply within 60 seconds

In versions prior to Abiquo 3.4, after you have made you changes restart the Tomcat server.

In Abiquo 3.4 and later versions, do not restart the Tomcat server because modifications will be applied within 60 seconds.