The document provides information on tools for monitoring and administering Cassandra clusters. It discusses Cassandra-specific tools like nodetool for monitoring metrics and performing administrative tasks. It also lists system monitoring tools for metrics like CPU usage, disk I/O, network activity, and more. Finally, it gives best practices for hardware selection with Cassandra including recommendations for memory, CPU, and disk space.

1. CassandraAdmin
1. Ops center:
high level overview of your cluster and provides historical metrics for the most
important information.
2. Metrics plugins:
The metrics library allows you to tell Cassandra to report its internal, table level
metrics out to a whole slew of different place and pluggable to push metrics to
anywhere you want.
3. Munin, Nagios, Icinga (or other system metrics monitoring)
useful at graphing system metrics as well as custom application metrics.
4. Statsd, Graphite, Grafana
Your application should be tracking internal metrics. Timing queries, frequently
called functions, etc. These tools let you get a profile of what’s going on with your
code in production. Statsd collects raw stats and aggregates them together, then
kicks them to graphite. Grafana is an optional (better) front end to Graphite.
5. Logstash:
correlating application issues with other failures and useful for application logging
aggregation.
System Tools
1. Iostat: Disk I/O issues like high read write rates Big queue (avgqu-sz).
High service time (svctm) means bottleneck at disk.
2. Htop: load, running processes, memory usage, and a bunch of other information at
a quick glance.
3. iftop & netstat:
iftop is like top, but shows you active connections and the transfer rates between
your server and whoever is at the other end.
Netstat: network connections, routing tables, interface statistics, and a variety of
other network information.
4. Dstat: iostat + more functionality.
5. Strace:system calls for given process.
6. Pcstat: examine a bunch of files and quickly determine how much of each file is in
the buffer cache.

2. Precautions:
Clock skew
server times are different, the last write may not actually win so make sure your clocks
are synced. Ntpdate needs to be used if you clock is significantly off, and ntpd will keep
it at the correct time.
Disk space not reclaimed
if you add new nodes to a cluster, each replica is responsible for less data. it’s streamed to
the new nodes. run nodetool cleanup in order to reclaim that disk space.
Issues adding nodes, or running repairs
2.1 usesincremental updates. trying to repair (or add nodes) to a cluster when the versions do
not match. appear to have started, but will just hang around doing nothing.
Cassandra Tools
Compaction
Compaction is the process of merging SSTables together. can limit the I/O used by
compaction by using nodetool setcompactionthroughput.
2 types of compaction:
Size Tiered is the default and great for write heavy workloads.
Leveled compaction is good for read & update heavy workloads, but since it uses much
higher I/O it’s recommended you use this only if you’re on SSD.
Cfstats and Histograms
understand at both a high level and table level what your performance looks like on a
single node in your cluster. proxyhistograms, give you a quick top level view of all
your tables on a node. This includes network latency.
performance problem isolated to a particular table then run nodetool cfstats on a
keyspace. Gives list of table and abnormalities.which table queried most?.
nodetool cfhistograms lets you identify performance problems with a single
table on a single node.

3. Query Tracing
explain, which tells in in advance what the query plan is for a given query. query
tracing keeps track of the events in the system whewn it actually executes.
JVM Garbage Collection
Diagnosing Problems

4. Selecting hardware for enterprise implementations
Memory
The more memory a Cassandra node has, the better read performance.
More RAM allows for larger cache sizes and reduces disk I/O for reads. More RAM also allows
memory tables (memtables) to hold more recently written data. Larger memtables lead to a
fewer number of SSTables being flushed to disk and fewer files to scan during a read. The ideal
amount of RAM depends on the anticipated size of your hot data.
 For dedicated hardware, the optimal price-performance sweet spot is 16GB to 64GB; the
minimum is 8GB.
 For a virtual environments, the optimal range may be 8GB to 16GB; the minimum is 4GB.
CPU
Insert-heavy workloads are CPU-bound in Cassandra before becoming memory-bound. (All
writes go to the commit log, but Cassandra is so efficient in writing that the CPU is the limiting
factor.) Cassandra is highly concurrent and uses as many CPU cores as available:
Disk¶
Disk space depends a lot on usage, so it's important to understand the mechanism. Cassandra
writes data to disk when appending data to the commit log for durability and when
flushingmemtable to SSTable data files for persistent storage. SSTables are periodically
compacted. Compaction improves performance by merging and rewriting data and discarding
old data. However, depending on the compaction strategy and size of the compactions,
compaction can substantially increase disk utilization and data directory volume.

5. you should leave an adequate amount of free disk space available on a node: 50% (worst case)
for SizeTieredCompactionStrategy and large compactions, and 10% for
LeveledCompactionStrategy.
Tools
Cassandra tools
 The nodetool utility
o cfhistograms
o cfstats
o cleanup
o clearsnapshot
o compact
o compactionhistory
o compactionstats
o decommission
o describering
o disableautocompaction
o disablebackup
o disablebinary
o disablegossip
o disablehandoff
o disablethrift
o drain
o enableautocompaction
o enablebackup
o enablebinary
o enablegossip
o enablehandoff
o enablethrift
o flush
o getcompactionthreshold
o getendpoints
o getsstables

6. o getstreamthroughput
o gossipinfo
o info
o invalidatekeycache
o invalidaterowcache
o join
o move
o netstats
o pausehandoff
o proxyhistograms
o rangekeysample
o rebuild
o rebuild_index
o refresh
o removenode
o repair
o resetlocalschema
o resumehandoff
o ring
o scrub
o setcachecapacity
o setcachekeystosave
o setcompactionthreshold
o setcompactionthroughput
o sethintedhandoffthrottlekb
o setstreamthroughput
o settraceprobability
o snapshot
o status
o statusbinary
o statusthrift
o stop
o stopdaemon
o taketoken
o tpstats
o truncatehints
o upgradesstables
o version