cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robert Stupp (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (CASSANDRA-9029) Add support for rate limiting log statements
Date Tue, 24 Mar 2015 22:37:53 GMT

    [ https://issues.apache.org/jira/browse/CASSANDRA-9029?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14378761#comment-14378761
] 

Robert Stupp edited comment on CASSANDRA-9029 at 3/24/15 10:37 PM:
-------------------------------------------------------------------

My five cent (from the discussion in CASSANDRA-8584):

I'm pro and contra regarding log-throttling.
Pro, because it may limit the amount of "spam" in the log file (e.g. hundreds of "batch too
big" messages)
Contra, because it may hide the importance of a message (amount of messages is is the level
of importance)
OTOH - who really reads log files (especially in a big cluster)? What I want to say is: is
a log file really the place where important should go to? I think there are some solutions
out there that do some log file scanning and aggregation and alerting. Some people tend to
think that a message which appears very often must be very important. It's more a psychological
than a technical thing (same message appearing 100 times may look more important than one
message saying something occurred 100 times).

IMO we should think of something or use/add support for something that really adds value for
operators of both small and big clusters. Unfortunately I'm not aware of some API that's already
there. It heads more to the direction of operation management stuff, where alerting and monitoring
is daily business.

The other side is notifications to clients (I think there's another ticket regarding warnings
in the native protocol).

System.log currently covers "system" related messages and client related messages (e.g. "batch
too big"). EDIT: we could think of separating these or handle them in a different way and
enrich with client-related information (client IP for example).

(edit: re-order paragraphs)


was (Author: snazy):
My five cent (from the discussion in CASSANDRA-8584):

I'm pro and contra regarding log-throttling.
Pro, because it may limit the amount of "spam" in the log file (e.g. hundreds of "batch too
big" messages)
Contra, because it may hide the importance of a message (amount of messages is is the level
of importance)
OTOH - who really reads log files (especially in a big cluster)? What I want to say is: is
a log file really the place where important should go to? I think there are some solutions
out there that do some log file scanning and aggregation and alerting. Some people tend to
think that a message which appears very often must be very important. It's more a psychological
than a technical thing (same message appearing 100 times may look more important than one
message saying something occurred 100 times).

System.log currently covers "system" related messages and client related messages (e.g. "batch
too big").

But we should think of something or use/add support for something that really adds value for
operators of both small and big clusters. Unfortunately I'm not aware of some API that's already
there. It heads more to the direction of operation management stuff, where alerting and monitoring
is daily business.

The other side is notifications of clients (I think there's another ticket regarding warnings
in the native protocol).

> Add support for rate limiting log statements
> --------------------------------------------
>
>                 Key: CASSANDRA-9029
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-9029
>             Project: Cassandra
>          Issue Type: Improvement
>            Reporter: Ariel Weisberg
>            Assignee: Ariel Weisberg
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message