On Wed, Nov 24, 2010 at 3:04 AM, Peter Schuller <peter.schul...@infidyne.com> wrote: >> I was told by a colleague that read and write problems in Cassandra can be >> detected by monitoring a Cassandra log file. > > What do you mean by "problem"? If you mean something like a hard I/O > error or corruption causing an internal error, you should get an > exception of some kind in the system log (typically > /var/log/cassandra/output.log or similar, unless otherwise > configured). > > -- > / Peter Schuller >
At the default log level of info you should look for DroppedMessageLogger, -- backpressure is causing failures GCInspector, --garbage collector paused "optimal bloom filter" -- not sure this is critical but appears at times "Large row" -- message from compaction about a really large row "STATE Down" -- message from gossip about node flap "STATE UP" -- message from gossip about node flap "Digest mismatch exception" --Quorum read fixed data (I do not see this much") I use a log4j syslog appender to send info to our splunk/syslog station. I use splunk to count these events based on time buckets.
