[
https://issues.apache.org/jira/browse/CASSANDRA-12151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16431296#comment-16431296
]
Ariel Weisberg commented on CASSANDRA-12151:
--------------------------------------------
Adding a way for clients to subscribe to events is great, but there are couple
of questions that brings up. How does backpressure work? We have to have a
convincing story for what happens so that slow or unavailable clients can't
consume unbounded memory.
The other nice to have is what happens if a client disconnects and reconnects?
Can it get the events that it missed? This ties into being able to consume on
disk artifacts like the BinLog. Do the diagnostic events have enough
information in them that you can tell where in the stream of events for a
particular node you are? Just enough to facilitate at least once delivery with
duplicates dropped.
Are diagnostic events always really going to be used for diagnostic purposes?
I'm just questioning the name. Maybe it should just be SUBSCRIBE and maybe only
some of the more problematic things should be locked behind config options. And
then we have to think about what happens with large numbers of subscribers
although for V1 it could just be a sharp edge.
In terms of using the BinLog as more of a store of record. We need to figure
out how crashes and restarts are going to be handled. I don't recall exactly
what happens, but I suspect that chronicle is just going to leave behind the
old files and start a new one for appending so we need to come back and process
the old files on startup. I think specifying a shell script is probably OK
although if someone specifies the script we should run it immediately once
Chronicle rolls the file. Also if the script is specified we probably shouldn't
delete artifacts.
As these things start to get more complex how are we going to change the YAML
and fqltool to be the ri
Also this entire change set is starting to get really large.
* Generating whole new classes of events, multiple targets for logging
* Modifications to the existing BinLog to add new capabilities like using it as
a store of record, running a users provided script
* Wire protocol changes and a new way to subscribe to have the server push stuff
Would be nice to discuss and review these in more isolation. GL Dinesh!
> Audit logging for database activity
> -----------------------------------
>
> Key: CASSANDRA-12151
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12151
> Project: Cassandra
> Issue Type: New Feature
> Reporter: stefan setyadi
> Assignee: Vinay Chella
> Priority: Major
> Fix For: 4.x
>
> Attachments: 12151.txt, CASSANDRA_12151-benchmark.html,
> DesignProposal_AuditingFeature_ApacheCassandra_v1.docx
>
>
> we would like a way to enable cassandra to log database activity being done
> on our server.
> It should show username, remote address, timestamp, action type, keyspace,
> column family, and the query statement.
> it should also be able to log connection attempt and changes to the
> user/roles.
> I was thinking of making a new keyspace and insert an entry for every
> activity that occurs.
> Then It would be possible to query for specific activity or a query targeting
> a specific keyspace and column family.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
