Monitoring - Practical Cassandra - page 109

8. Monitoring
As the old systems adage goes, a service doesn't exist unless it's monitored. In
this chapter, we will cover the basics of monitoring Cassandra. These include file-
based logging, inspection of the JVM, and monitoring of Cassandra itself.
Logging
Under the covers, Cassandra uses the standard Java log library Log4j. Log4j is an-
other Apache project that enables the capability to control the granularity of log
statements using a configuration file. If you want to find out more about what is
happening on a particular node than what nodetool and JMX MBeans (which
we will cover in more detail later in the chapter) are telling you, you can change
the logging levels.
As a front end to the Log4j back end, Cassandra uses Simple Logging Façade
for Java (SLF4J). The logging levels from least verbose to most verbose are
TRACE
DEBUG
INFO
WARN
ERROR
FATAL
Understanding these logging levels is important not only to help monitor what
is going on in the system or on a particular node but also to help troubleshoot prob-
lems. In troubleshooting complex systems such as Cassandra, Cassandra's node-
tool , logging, and even the JMX MBeans can lead to red herrings. So it is neces-
sary to compile as much information pertinent to the problem as possible to help
diagnose what might be going on.
Taking a look at a normal healthy Cassandra node's system.log, you will see
INFO lines that refer to various stages of the system executing their tasks. These
include MemTable flushes, HintedHandoffs, and compactions, just to name a few.