AppSuite:OX Logging

Revision as of 11:57, 26 January 2015 by Ioannis.chouklis (talk | contribs) (New Features)
This information is valid from 7.4.2 on.
Server-side Logging

With OX App Suite 7.4.2 the groupware server introduces LOGBack as logging implementation. Formerly log4j 1.2 or java.util.logging have been used for logging. As of now the package 'open-xchange-log4j' has become obsolete and LOGBack is entirely contained in 'open-xchange-core'. No additional packages are needed even for syslog-based logging or sophisticated logging configurations anymore. Log4j and java.util.logging have been completely replaced by LOGBack.

For Operators


LOGBacks configuration is defined in /opt/open-xchange/etc/logback.xml. We ship the file pre-configured for new installations and set some useful defaults. Without any changes, the groupware writes log files to /var/log/open-xchange. See chapter #Backward Compatibility for detailed information on product upgrades from older versions. See LOGBack manual for details on configuring LOGBack.

Backward Compatibility

Configuration Migration

In most cases no further work should be necessary after upgrading to OX App Suite 7.4.2. Based on your existing logging configuration (/opt/open-xchange/etc/ or /opt/open-xchange/etc/log4j.xml) we automatically migrate custom configured logger levels via package post installation scripts to the new logback configuration.

We also configure file-based logging or syslog-based logging in accordance with the default configuration of the formerly used logging implementation. That means depending whether open-xchange-log4j was installed or not, the package post installation scripts modify the default logback configuration to send logs to a remote syslog daemon. You don't have to change anything if

  • you use plain file logging and did not modify the 'handler'-section in
  • you use syslog-based logging via log4j and did not change the configured 'SERVER_LOG' appender.

Please note: If you customized handlers or appenders you have to port your changes manually to /opt/open-xchange/etc/logback.xml. See LOGBack manual for details.

Log File Format

We keep the former default layout for log events on product upgrades. So nothing should break if you wrote your own log file parser.

Please note: We also ship a pre-configured new log file layout. You are strongly encouraged to use this one for file-based logging, as it provides more information and is better structured than the old one. To enable it, change the appender reference of appender ASYNC to FILE instead of FILE_COMPAT in /opt/open-xchange/etc/logback.xml.


<appender name="ASYNC" class="ch.qos.logback.classic.AsyncAppender">
  <appender-ref ref="FILE_COMPAT" />


<appender name="ASYNC" class="ch.qos.logback.classic.AsyncAppender">
  <appender-ref ref="FILE" />

New Features

Config-based Asynchronous Logging

Publishing log events to files, syslogd or the like is performed asynchronously. Therefore the root loggers appender is set to 'ASYNC', which is configured as follows:

  <appender name="ASYNC" class="ch.qos.logback.classic.AsyncAppender">
    <appender-ref ref="FILE" />

The most important property is "appender-ref". It denotes the name of the appender, that finally writes log events out in some way. A detailed description of the other parameters can be found here: [1].

If you introduce your own log appender, only change the above mentioned 'appender-ref' property. Don't remove or deactivate the configuration for asynchronous logging! It might decrease the applications performance significantly.

Suppression Of Stacktraces

It is possible to suppress Java stacktraces in log messages for configured categories. Those categories are part of OX App Suites internal error and exception handling. Suppression can be configured in by adjusting the value for 'com.openexchange.log.suppressedCategories'. See below excerpt of /opt/open-xchange/etc/

# Specify the OXException categories (comma separated) to be suppressed when logging.
# The Exception itself will still be logged as configured, but the StackTraces are omitted.
# Default is USER_INPUT.

Tracing Of Sessions, Users and Contexts

It is possible to enable extended logging for defined scopes like sessions, users or contexts at a whole. This means that every log event which belongs to a configured scope will be logged despite of it's level, if it's logger belongs to a configured whitelist. The whitelist is configured in logback.xml:

<property scope="context" name="com.openexchange.logging.filter.loggerWhitelist" value="com.openexchange" />

The whitelists purpose is to avoid flooding your log files with unwanted tracing events from e.g. 3rd party libraries. The "value"-attribute can be adjusted. It may contain a comma-separated list of loggers. It's hierarchical. That means 'com.openexchange' also allows all child-loggers.

Example: Imagine logback is configured to log on level 'INFO' and additionally the logger 'com.openexchange.example.SomeLogger' is only allowed to log warnings and errors. The whitelist is configured as shown above.

  <property scope="context" name="com.openexchange.logging.filter.loggerWhitelist" value="com.openexchange" />
  <root level="INFO">
    <appender-ref ref="ASYNC" />
  <logger name="com.openexchange.example.SomeLogger" level="WARN"/>

If tracing is activated for user '5' in context '1', events belonging to this user are written out, even if they deceed the configured thresholds. I.e. you can find log entries with level 'DEBUG' from logger 'com.openexchange.example.SomeLogger' that belong to the traced user.

2013-12-09 15:29:31,641 DEBUG [OXWorker-0000001] com.openexchange.example.SomeLogger
Some very useful debug message.

The decision whether to log such an event is based on the whitelist and the context information that every log event carries along. These information is structured as key-value-pairs and always printed below the log events message. Afterwards it's easy to find the tracing events in the log file. You just have to search for 'com.openexchange.session.contextId=1' and 'com.openexchange.session.userId=5'. If you trace a specific session, according events can be found with looking for 'com.openexchange.session.sessionId=session_id_to_trace'.

New Log Event Layout

We ship a new default layout for log events that

  • contains a more precise timestamp
  • carries the name of the current thread
  • is easier to parse


2013-12-11 12:41:35,660 INFO  [LoginPerformer-0000003] com.openexchange.caching.internal.JCSCache
Cache 'UserPermissionBits' is operating in distributed mode

Please note: The new layout applys only for fresh installations. On upgrades you have to enable it manually. See #Log File Format for details.

Remote logging to logstash

This information is valid from 7.6.2 on.

In 7.6.2 we introduced a new feature that allows the OX server to log directly to a logstash[2] server.

To enable that feature you will need (besides the logstash server) to add/enable the OX logstash appender in the logback.xml file:

<property scope="context" name="com.openexchange.logback.extensions.logstash.enabled" value="true" />
<property scope="context" name="com.openexchange.logback.extensions.logstash.alwaysPersistEvents" value="true" />
<property scope="context" name="com.openexchange.logback.extensions.logstash.loadFactor" value="0.67" />
<appender name="LOGSTASH" class="com.openexchange.logback.extensions.logstash.LogstashSocketAppender">
  <encoder class="com.openexchange.logback.extensions.logstash.LogstashEncoder"/>

The three properties defined at the beginning of the XML snippet have the following use:

  • com.openexchange.logback.extensions.logstash.enabled - This flag is used to enable the JMX metrics for the event queue size in the appender
  • com.openexchange.logback.extensions.logstash.alwaysPersistEvents - If set to true, then log events that are in queue and can not be send to the logstash server (for what ever reason) are persisted to open-xchange-console.log as JSON formated logstash events.
  • com.openexchange.logback.extensions.logstash.loadFactor - The load factor of the queue before flushing it.

The logstash appender has to then be referenced to the root logger:

<root level="INFO">
  <appender-ref ref="LOGSTASH" />

Of course the logstash server should also be appropriately configured. You can add the following lines in your input configuration:

# For LogX
tcp {
  port => 31337
  type => "LogX"
  codec => line {
    charset => "UTF-8"
    format => "string" 

And the following filter to your filter configuration (note that you will have to adjust your timezone):

if [type] == "LogX" {
   json {
     source => "message"
   date {
       match => ["timestamp", "ISO8601"]
       timezone => "Europe/Berlin"
       remove_field => ["timestamp"]

logconf CLT

The above mentioned features can be managed via the logconf command line tool (/opt/open-xchange/sbin/logconf). It creates log filters for sessions, context and (user/context) tuples, suppresses stacktraces for defined exception categories and dynamically changes log levels of specified loggers. It is also possible to create a filter for a user or a context or a session and set the level of the desired loggers independently.


logconf [-a | -d] [-c <contextid> [-u <userid>] | -s <sessionid>] [-l <logger_name_1>=<logger_level_x> ...] [-U <JMX-User> -P <JMX-Password> [-p <JMX-Port>]]

logconf -oec <category_1>,...

logconf [-cf] | [-lf] | [-ll [<logger_1> ...] | [dynamic]] | [-le] | [-h]


-h,--help Prints usage of the command line tool
-a,--add Flag to add the filter
-d,--delete Flag to delete the filter
-c,--context <contextid> The context id for which to create the log filter
-cf,--clear-filters Clear all logging filters
-u,--user <userid> The user id for which to create the log filter
-s,--session <sessionid> The session id for which to create the log filter
-l,--level <logger_1>=<loglevel_x> ... <logger_n>=<loglevel_y> Define the log level for the specified loggers
-le, --list-exception-category Get a list with all supressed exception categories
-lf, --list-filters Get a list with all logging filters of the system
-ll, --list-loggers Get a list with all loggers of the system.

Can optionally have a list with loggers as arguments, i.e. -ll <logger1> <logger2> OR the keyword 'dynamic' that instructs the command line tool to fetch all dynamically modified loggers. Any other keyword is then ignored, and a full list will be retrieved.

-oec, --override-exception-categories <category name>,... Override the exception categories to be suppressed, comma separated

Follow switches are valid if JMX authentication is enabled

-U, --JMX-User <username> JMX username
-P, --JMX-Password <password> JMX password
-p, --JMX-Port <port> JMX port


Command output

INFO/ERROR/WARNING: [msg1, msg2, ... msgn]

Operation [operation name] with parameters: {...} succeeded.


Create a user/context filter for user 1618 and context 314

# logconf -u 1618 -c 314 -a

INFO: [Created new filter for user with ID "1618", in context with ID "314" and policy "ACCEPT"]

Change the log level for the com.openexchange.appsuite logger

# logconf -l com.openexchange.appsuite=DEBUG com.openexchange.usm=DEBUG

INFO: [Setting log level for "com.openexchange.appsuite" to "DEBUG", Setting log level for "com.openexchange.usm" to "DEBUG"]



INFO: [Setting suppressed Exception Categories to CONFIGURATION,CONNECTIVITY]

Create a user/context filter for user 1618, context 314 and loggers c.o.mail and c.o.appsuite with levels TRACE and DEBUG respectively

# logconf -u 1618 -c 314 -a -l com.openexchange.appsuite=DEBUG com.openexchange.mail=TRACE

INFO: [Created new filter for user with ID "1618", in context with ID "314" and policy "ACCEPT", Added logger "com.openexchange.mail" with level "TRACE", Added logger "com.openexchange.appsuite" with level "DEBUG"]

Remove a logger from a user/context filter with user 1618 and context 314

# logconf -u 1618 -c 314 -d -l com.openexchange.appsuite

INFO: [Removed logger "com.openexchange.appsuite" from user filter for user with ID "1618", context with ID "314" and policy "ACCEPT"]

Remove the entire filter for user 1618 and context 314.

# logconf -u 1618 -c 314 -d

INFO: [Removed user filter for user with ID "1618", context with ID "314" and policy "ACCEPT"]

For Developers

Instantiate Loggers

import org.slf4j.Logger;
import org.slf4j.LoggerFactory;

public class Clazz {

    private static final Logger LOG = LoggerFactory.getLogger(Clazz.class);



Using Apache Commons Logging as logging facade is depracted as of OX App Suite 7.4.2. Formerly we used own wrapper classes to enable extended logging features. With the current logging implementation this is not necessary anymore. Obtaining loggers via

com.openexchange.log.Log.loggerFor(Clazz.class); or
com.openexchange.log.LogFactory.getLog(Clazz.class); or

still works for backward compatibility, but should not be used for new classes. Existing classes should be ported to SLF4J, when touched during refactorings, bugfixes etc.

Of course it is also required to fix the corresponding bundles META-INF/MANIFEST.MF file.





Logging Statements

With SLF4J you should avoid code like this:

if (LOG.isDebugEnabled()) {
    LOG.debug("Some debug message for user " + userId + " in context " + contextId + ".");

Instead relinquish the if-statement completely and make use of SLF4Js printf()-like syntax for log statements:

LOG.debug("Some debug message for user {} in context {}.", userId, contextId);

Please read What is the fastest way of (not) logging? for details.