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 Wed, 15 Apr 2015 00:41:00 GMT


Patrick McFadin commented on CASSANDRA-9193:

I don't think this is too far away from CASSANDRA-7526 with addition of metadata. 

I have used something similar on F5 network appliances in a feature called iRules. It was
a feature to run a trigger based on a network event. My favorite part was how the user specified
actions. You assigned a rule to a network port and wrote a collection of actions on events.
If I were to translate that to a Cassandra use case, you would assign a rule set to a Table.
Inside the rule set would be actions on events. Something like this pseudo code:

   onRequest {
      if(consistencyLevel == ALL) {
         log.WARN ("Dude. Seriously?")

   onResponse {
      if (consistencyError) { something...

      if (data.size > 500000) {
         log.WARN ("Dude. Seriously?")

Not proposing syntax but you get the idea. Could be a very powerful tool for troubleshooting
and insight. 

> 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