[
https://issues.apache.org/jira/browse/CASSANDRA-9193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14495451#comment-14495451
]
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) {
...do 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: https://issues.apache.org/jira/browse/CASSANDRA-9193
> 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 dynamically.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
