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.

Reply via email to