Apache Cassandra 1.1 Documentation

Logging Configuration

This document corresponds to an earlier product version. Make sure you are using the version that corresponds to your version.

Latest Cassandra documentation | Earlier Cassandra documentation

Cassandra provides logging functionality using Simple Logging Facade for Java (SLF4J) with a log4j backend. Additionally, the output.log captures the stdout of the Cassandra process, which is configurable using the standard Linux logrotate facility. You can also change logging levels via JMX using the JConsole tool.

Changing the Rotation and Size of Cassandra Logs

You can control the rotation and size of both the system.log and output.log. Cassandra's system.log logging configuration is controlled by the log4j-server.properties file in the following directories:

  • Packaged installs: /etc/dse/cassandra
  • Binary installs: <install_location>/resources/cassandra/conf


The maximum log file size and number of backup copies are controlled by the following lines:


The default configuration rolls the log file once the size exceeds 20MB and maintains up to 50 backups. When the maxFileSize is reached, the current log file is renamed to system.log.1 and a new system.log is started. Any previous backups are renumbered from system.log.n to system.log.n+1, which means the higher the number, the older the file. When the maximum number of backups is reached, the oldest file is deleted.

If an issue occurred but has already been rotated out of the current system.log, check to see if it is captured in an older backup. If you want to keep more history, increase the maxFileSize, maxBackupIndex, or both. However, make sure you have enough space to store the additional logs.

By default, logging output is placed the /var/log/cassandra/system.log. You can change the location of the output by editing the log4j.appender.R.File path. Be sure that the directory exists and is writable by the process running Cassandra.


The output.log stores the stdout of the Cassandra process; it is not controllable from log4j. However, you can rotate it using the standard Linux logrotate facility. To configure logrotate to work with cassandra, create a file called /etc/logrotate.d/cassandra with the following contents:

/var/log/cassandra/output.log {
  size 10M
  rotate 9

The copytruncate directive is critical because it allows the log to be rotated without any support from Cassandra for closing and reopening the file. For more information, refer to the logrotate man page.

Changing Logging Levels

If you need more diagnostic information about the runtime behavior of a specific Cassandra node than what is provided by Cassandra's JMX MBeans and the nodetool utility, you can increase the logging levels on specific portions of the system using log4j. The logging levels from most to least verbose are:



Be aware that increasing logging levels can generate a lot of logging output on even a moderately trafficked cluster.

Logging Levels

The default logging level is determined by the following line in the log4j-server.properties file:


To exert more fine-grained control over your logging, you can specify the logging level for specific categories. The categories usually (but not always) correspond to the package and class name of the code doing the logging.

For example, the following setting logs DEBUG messages from all classes in the org.apache.cassandra.db package:


In this example, DEBUG messages are logged specifically from the StorageProxy class in the org.apache.cassandra.service package:


Finding the Category of a Log Message

To determine which category a particular message in the log belongs to, change the following line:

log4j.appender.R.layout.ConversionPattern=%5p [%t] %d{ISO8601} %F (line %L) %m%n
  1. Add %c at the beginning of the conversion pattern:

    log4j.appender.R.layout.ConversionPattern=%c %5p [%t] %d{ISO8601} %F (line %L) %m%n

    Each log message is now prefixed with the category.

  2. After Cassandra runs for a while, use the following command to determine which categories are logging the most messages:

    cat system.log.* | egrep 'TRACE|DEBUG|INFO|WARN|ERROR|FATAL' | awk '{ print $1 }' | sort | uniq -c | sort -n
  3. If you find that a particular class logs too many messages, use the following format to set a less verbose logging level for that class by adding a line for that class:


    For example a busy Solr node can log numerous INFO messages from the SolrCore, LogUpdateProcessorFactory, and SolrIndexSearcher classes. To suppress these messages, add the following lines:

  4. After determining which category a particular message belongs to you may want to revert the messages back to the default format. Do this by removing %c from the ConversionPattern.