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)