[
https://issues.apache.org/jira/browse/CASSANDRA-12151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16419652#comment-16419652
]
Vinay Chella commented on CASSANDRA-12151:
------------------------------------------
[~spo...@gmail.com] ,
{quote}I'd not use the logback logger for query logging in production. As shown
recently in CASSANDRA-14318, the performance impact is significant and your
benchmark results show that as well. Rotating out log files by simply deleting
them is probably also not what you'd expect from an auditing solution.
{quote}
Agreed, yes, BinAuditLogger is the default for obvious reasons based on my perf
numbers, but if any users are willing to use log back based AuditLogger thereby
willing to compromise on performance while benefiting on easy readability, they
can by changing the yaml configuration.
{quote}NIT: check logger.isEnabled before toString in FileAuditLogger
{quote}
FileAuditLogger::log method is called only when AuditLogger is enabled, do you
think the redundant check is needed inside the IAuditLogger implementations as
well?
{quote}But maybe we can keep the logback logger for some simple auth related
logging and make it also useful for users who would not enable auditing in
first place. How about enabling the FileAuditLogger by default and let it
create an auth.log, which would log all failed login attempts? Maybe add a
comment on how to enable successful attempts as well.
{quote}
Logging just auth failure attempts can be achieved by either the design idea
that you brought up or new feature to filter {{include_auditlog_types}}. But
not sure, if everyone would like or need auth failures attempts by default.
I also see good design ideas in terms of {{multiple implementations in
parallel}} and feature requests {{include_auditlog_types}}, however, do you
agree with me that it is a {{nice to have}} but not {{must to have}} feature
considering the scope of the first iteration, to keep the initial
implementation simple, iterate faster and changeset smaller? If you do, I can
create followup JIRAs for the ideas that you proposed.
Hi [~chovatia.jayd...@gmail.com] .
{quote}Currently if audit is enabled then it will log all types of statements
DDL|DML|DCL, people will have different requirements for logging (say only log
DCL OR DCL + DDL etc.) given DML would generate huge volume of data, so I think
we need to give better control to users as to what they want to log
{quote}
Correct, the current design enables users to have control of what to log since
the use cases could be different (eg., DCL or DCL+DDL etc.,) using yaml
configurations
{quote}probably at what frequency as well.
{quote}
I don't know as a database when it promises for audit logging for compliance if
it does based on some probability. However, if you have such one of use case
(e.g., audit logging for debugging needs instead of compliance needs), you can
implement {{IAuditLogger}} or extend one of existing loggers to have
{{FrequencyBasedAuditLogger}} which logs based on some probability.
> 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
