cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ariel Weisberg (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-12151) Audit logging for database activity
Date Mon, 09 Apr 2018 21:11:00 GMT

    [ 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-unsubscribe@cassandra.apache.org
For additional commands, e-mail: commits-help@cassandra.apache.org


Mime
View raw message