[ 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)