Stefan Podkowinski commented on CASSANDRA-12151:

We should not provide solutions that we know will have significant performance 
issues on busy production systems. I don’t mind keeping the FileAuditLogger 
class, as it’s really trivial. But please remove references to it from 
cassandra.yaml and the corresponding entries in logback.xml (don’t like to have 
an empty audit.log file on all nodes either). Let’s nudge users to use to 
BinAuditLogger right away as the recommended solution.

If you don’t think adding an option like include_auditlog_types should be 
necessary, that’s fine. But then let me use my own implementation for filtering 
logs, if my requirements are different. This means that I’d have to be able to 
specify additional parameters (e.g. custom filtering options) along with the 
class name for my implementation. So I'd suggest to use ParameterizedClass for 
the logger in cassandra.yaml to make that easily possible.

Looking at IAuditLogger and thinking about how to filter log events makes me a 
bit worried about the design in general there. We keep generating AuditLogEntry 
instances and create unnecessary garbage, even if we’re only interested in some 
specific entry types. Maybe we should move filtering either into the 
IAuditLogger implementation or make it possible to use a custom AuditLogFilter 
as well (IAuditLogger.getLogFilter() ?).

Just looking at AuditLogFilter makes me also think that the isFiltered logic 
should be reconsidered, as null values will cause entries to always pass, even 
if the include set is not empty.
{quote}How do you suggest we approach this problem? We cannot keep the audit 
log files around indefinitely. Perhaps we can specify a disk quota for audit 
log files in the configuration? We can expose this setting in cassandra.yaml?
How does this work with BinLogger? I haven't looked at that part in detail yet. 
Does it overwrite old entries automatically? How would you suggest users should 
archive logs from there?

> 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

To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

Reply via email to