cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <wikidi...@apache.org>
Subject [Cassandra Wiki] Update of "LoggingGuidelines" by PauloMotta
Date Fri, 02 Oct 2015 23:00:51 GMT
Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Cassandra Wiki" for change notification.

The "LoggingGuidelines" page has been changed by PauloMotta:
https://wiki.apache.org/cassandra/LoggingGuidelines

New page:
== Logging Guidelines for Cassandra 2.2+ ==

[[https://issues.apache.org/jira/browse/CASSANDRA-10241|CASSANDRA-10241]] created ''debug.log''
in addition to the traditional ''system.log'' on Cassandra 2.2+. While ''system.log'' will
continue to output the most relevant cluster status information ('''INFO''', '''WARN''' and
'''ERROR''' levels), the new ''debug.log'' ('''DEBUG''' in addition to the previous levels)
will log things that help during troubleshoting, such as intermediate protocol steps and more
detailed operational information. The examples below serve as a general guideline to help
the developer decide what goes into each logging level.

'''INFO''': General cluster status, operations overview. At this level a beginner user or
operator should be able to understand most messages.
Examples:
 * Node startup and shutdown information
 * User or system triggered operations overview
  * Repair start and finish state
  * Cleanup start and finish state
  * Bootstrap start and finish state
  * Index rebuild start and finish state

'''DEBUG''': Low frequency state changes or message passing. Non-critical path logs on operation
details, performance measurements or general troubleshooting information. At this level an
advanced operator or system developer will have elements to investigate or detect erroneous
conditions or performance bottlenecks, extract reproduction steps or inspect advanced operational
information.
Examples:
 * SSTable flushing
 * Compactions in progress
 * Gossip or schema state changes
 * Operations intermediate steps
  * Repair steps
  * Stream session message exchanges

'''WARN''': Use of suboptimal parameters or deprecated options, detection of degraded performance,
capability limitations or missing dependencies. General optimization tips. At this level,
an operator should be able to detect an eminent error condition, use of suboptimal parameters
or non-critical configuration errors.
Examples:
 * Use of chunk_length_in_kb property instead of chunk_length
 * GC above treshold warnings
 * OpenJDK not recommended notice
 * Small sstable size warning (Testing done for CASSANDRA-5727 indicates that performance
improves up to 160MB)

'''ERROR''': A expected error condition has ocurred. Non-critical, transient or recovered
errors might be reported at DEBUG level instead so they don't pollute system.log.
Examples:
 * critical errors in general (corrupted disk, read error, etc)
 * leak detection

'''TRACE''': High frequency state changes or message passing, critical path logs, testing
or development information. This level is disabled by default, so everything that does not
fit in the previous levels and highly verbose stuff must be kept at TRACE level.
Examples:
 * Failure detector checks
 * Gossip digests
 * CassandraServer.insert()

Mime
View raw message