cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Patrick McFadin (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-9193) Facility to write dynamic code to selectively trigger trace or log for queries
Date Tue, 28 Apr 2015 18:00:07 GMT


Patrick McFadin commented on CASSANDRA-9193:

I'm sensing this debate shifting to more about a potential developer centric feature when
it's almost 100% not. This is all about the operators/DBAs that need insight. System log and
JMX mostly work in a postmortem but less so in a real-time diagnostic scenario. The two most
important features are that it's expressive and complete. I don't think that negative side
effect is a deal killer. I would even say if there wasn't any potential negative side-effects
then it's not complete enough. If you look at the original kernel of an idea for this Jira,
"dtrace for Cassandra" it holds up. Dtrace can add a lot of overhead. You can do horrible
things to your OS. Despite of all the downsides, put in the hands of the right operator, dtrace
can save hours of troubleshooting and potentially save the day.

As scary as it might be, this seems to me like a step in the right direction for product maturity.

> Facility to write dynamic code to selectively trigger trace or log for queries
> ------------------------------------------------------------------------------
>                 Key: CASSANDRA-9193
>                 URL:
>             Project: Cassandra
>          Issue Type: New Feature
>            Reporter: Matt Stump
> I want the equivalent of dtrace for Cassandra. I want the ability to intercept a query
with a dynamic script (assume JS) and based on logic in that script trigger the statement
for trace or logging. 
> Examples 
> - Trace only INSERT statements to a particular CF. 
> - Trace statements for a particular partition or consistency level.
> - Log statements that fail to reach the desired consistency for read or write.
> - Log If the request size for read or write exceeds some threshold
> At some point in the future it would be helpful to also do things such as log partitions
greater than X bytes or Z cells when performing compaction. Essentially be able to inject
custom code dynamically without a reboot to the different stages of C*. 
> The code should be executed synchronously as part of the monitored task, but we should
provide the ability to log or execute CQL asynchronously from the provided API.
> Further down the line we could use this functionality to modify/rewrite requests or tasks

This message was sent by Atlassian JIRA

View raw message