cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sylvain Lebresne (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-9193) Facility to write dynamic code to selectively trigger trace or log for queries
Date Mon, 27 Apr 2015 16:20:40 GMT


Sylvain Lebresne commented on CASSANDRA-9193:

bq. The consumer of this facility would primarily be advanced users that are attempting to
gain visibility into Cassandra internals

I don't entirely disagree, but at the same time, the more easy this is to use, the more likely
this will be to people. In particular, tying this too much to the internals will imo make
it painful in practice because those can change a lot and without warnings.

bq. I want to back port this to older versions of Cassandra \[...\] The reason being is that
the field needs this now and it's going to take a while before whatever branch of 3.X this
lands in becomes readily deployed.

While I understand the need, this is pretty much out of scope for anyting pre-3.0. I also
really think for anything user-facing like this, we should try to make it as clean, generally
useful and easy to maintain moving forward as possible, and this even if this mean taking
more time to deliver it.

> 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