You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@zookeeper.apache.org by "Edward Ribeiro (JIRA)" <ji...@apache.org> on 2016/08/13 12:43:20 UTC

[jira] [Comment Edited] (ZOOKEEPER-1260) Audit logging in ZooKeeper servers.

    [ https://issues.apache.org/jira/browse/ZOOKEEPER-1260?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15419905#comment-15419905 ] 

Edward Ribeiro edited comment on ZOOKEEPER-1260 at 8/13/16 12:43 PM:
---------------------------------------------------------------------

{quote}
JMX matrices and audit logs serve completely different purposes.
{quote}

Yup, I know, but I was thinking about exporting those metrics to systems like Graphite or Nagios that can keep a record of ops exposed  (given the right adapters), aggregate the data and show them in fancy dashboards. But you right: they are complementary. *I would even go further to suggest that we could have JMX commands to enable/disable the audit log.* ;)

{quote}
Audit logs does not log all the operations, they log only the operations which change the state of the system. 
{quote}

Even so, this can be *a LOT of operations (state changes)*. _THIS, in fact is my only point regarding this issue_, but I am all favour  about the prospect of adding an audit log. Even on previous comment about it (sorry, if I was unclear about that).


{quote}
When the audit log is disabled, the performance impact is negligible. But when audit log is enabled offcourse there will be slight performace degradation
{quote}

Sure. Let's do this and *measure* his performance degradation under a high load of write ops, so that users can be aware of its impact.

TL;DR: I am +1 about adding an audit log, we certainly need this.



was (Author: eribeiro):

{quote}
JMX matrices and audit logs serve completely different purposes.
{quote}

Yup, I know, but I was thinking about exporting those metrics to systems like Graphite or Nagios that can keep a record of ops exposed  (given the right adapters), those views in fancy dashboards. But you right: they are complementary. *I would even go further to suggest that we could have JMX commands to enable/disable the audit log.* ;)

{quote}
Audit logs does not log all the operations, they log only the operations which change the state of the system. 
{quote}

Even so, this can be *a LOT of operations (state changes)*. _THIS, in fact is my only point regarding this issue_, but I am all favour  about the prospect of adding an audit log. Even on previous comment about it (sorry, if I was unclear about that).


{quote}
When the audit log is disabled, the performance impact is negligible. But when audit log is enabled offcourse there will be slight performace degradation
{quote}

Sure. Let's do this and *measure* his performance degradation under a high load of write ops, so that users can be aware of its impact.

TL;DR: I am +1 about adding an audit log, we certainly need this.


> Audit logging in ZooKeeper servers.
> -----------------------------------
>
>                 Key: ZOOKEEPER-1260
>                 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1260
>             Project: ZooKeeper
>          Issue Type: New Feature
>    Affects Versions: 3.4.0
>            Reporter: Mahadev konar
>            Assignee: Arshad Mohammad
>             Fix For: 3.6.0
>
>
> Lots of users have had questions on debugging which client changed what znode and what updates went through a znode. We should add audit logging as in Hadoop (look at Namenode Audit logging) to log which client changed what in the zookeeper servers. This could just be a log4j audit logger.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)