OpsCenter logback.xml configuration 

Some of the more common logback configuration parameters used by OpsCenter.

Starting with OpsCenter 6.0, the OpsCenter daemon process uses the Java logback library. All logging configuration is now done in the logback.xml file. This section highlights some of the most common configuration properties. Refer to the logback configuration guides for additional details.

Note: Restart OpsCenter for logging changes to take effect.


The location of the logback.xml file depends on the type of installation:

  • Package installations: /etc/opscenter/logback.xml
  • Tarball installations: install_location/conf/logback.xml

opscenterd_log appender 

The main logback appender used by default for OpsCenter is the opscenterd_log appender that controls appending log messages to the application log file. Below is a sample default block.

<appender name="opscenterd_log" class="ch.qos.logback.core.rolling.RollingFileAppender">
       <pattern>%date{ISO8601, UTC} [%X{cluster_id:-opscenterd}] %5level: %msg \(%thread\)%n%exception{20}</pattern>
    <rollingPolicy class="ch.qos.logback.core.rolling.FixedWindowRollingPolicy">
     <triggeringPolicy class="ch.qos.logback.core.rolling.SizeBasedTriggeringPolicy">

Some common configuration parameters include:

This is the base log file name that the current log messages are logged to.
This is the pattern logback follows when rolling a log file over. By default, the log file count is inserted into the filename (with the %i parameter).
This is the integer that logback uses to start counting log files with. The default value is 1.
The integer that logback uses as the max number of log files to keep. If a new log is needed and there are already maxIndex files, logback deletes the minIndex logfile and rolls the remaining log files. The default value is 10.
The log file size that causes logback to rotate the log files. By default, OpsCenter uses 10MB as a limit. Valid values can be found at https://logback.qos.ch/manual/appenders.html#SizeBasedTriggeringPolicy.
Note: The same basic properties also apply to the http_log appender, which is the log destination for HTTP requests, and the repair_log appender, which is the log destination for repair service logs.

Changing OpsCenter Daemon Logging Level 

Changing the level parameter in the <root> XML element only changes the logging level for the OpsCenter daemon and the cluster logging. Below is an example <root> block.

<root level="INFO">
    <appender-ref ref="opscenterd_log"/>
    <appender-ref ref="STDOUT"/>

Valid values for level include DEBUG, INFO, WARN, ERROR or OFF. By default, OpsCenter is configured to log at the INFO level. Setting the logging level to DEBUG or TRACE increases the verbosity of the log messages for troubleshooting.

In addition to the <root> logging level, there are also a set of granular logging-level configurations defined using the <logger> directive.

<logger name="com.datastax.driver" level="WARN" additivity="false"/>
<logger name="com.datastax.driver.core.FrameCompressor" level="ERROR"/>
<logger name="org.python" level="ERROR"/>
<logger name="org.jboss.netty" level="ERROR"/>
<logger name="org.apache.http" level="ERROR"/>
<logger name="com.mchange" level="ERROR"/>
<logger name="lcm" level="INFO"/>
<logger name="lcm.database.migration" level="WARN"/>

DataStax recommends leaving these levels set at their default points. Setting the log levels to a more verbose level might impact the performance of OpsCenter while generating unnecessary output.

Changing Console Log Level, HTTP Request Log Level, Repair Service Log Level, and Security Log Level 

Based on some limitations with logback configurations, changing the log level of the HTTP request logs or the repair service logs requires changing the filter inside of the http_log and repair_log respectively.

<filter class="ch.qos.logback.classic.filter.ThresholdFilter">

The valid values for this level are the same as the valid values listed in the section above.