[
https://issues.apache.org/jira/browse/CASSANDRA-12151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16422918#comment-16422918
]
Vinay Chella commented on CASSANDRA-12151:
------------------------------------------
[[email protected]],
{quote}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.
{quote}
Yes, I took care of this. Removed FileAuditLogger references from
cassandra.yaml and also code defaults
{quote}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() ?).
{quote}
Agreed, just to be clear from my previous reply - I am not against adding a new
filter (include_auditlog_types) or extending the interface, I would like to get
the initial simple version out and iterate on it rather than increasing the
changeset to be too heavy.
{quote}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}
Sure, considered null entries also. Now, {{isFiltered}} logic takes care of
null values when input set is not empty.
> 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: [email protected]
For additional commands, e-mail: [email protected]
