[GitHub] [accumulo-website] ctubbsii commented on a change in pull request #177: Issue-1136-add-audit-docs add audit log info to docs

[GitBox <gi...@apache.org>]

ctubbsii commented on a change in pull request #177: Issue-1136-add-audit-docs add audit log info to docs
URL: https://github.com/apache/accumulo-website/pull/177#discussion_r279594163
 
 

 ##########
 File path: _docs-2/getting-started/design.md
 ##########
 @@ -88,6 +88,13 @@ Multiple Monitors can be run to provide hot-standby support in the face of failu
 forwarding of logs from remote hosts to the Monitor, only one Monitor process should be active
 at one time. Leader election will be performed internally to choose the active Monitor.
 
+### Audit
+Accumulo has a robust audit service that logs most table actions, both successful and 
+failed attempts.  Audit logs are not enabled by default, but can be turned 
+on by editing the conf/log4j-service.properties file.  Audit logs are written to the same 
+location as the master, monitor and tserver logs, unless redirected in the conf/log4j-
+service.properties file.  Audit logs can be configured for the shell in conf/log4j.properties.
 
 Review comment:
   This information doesn't accurately represent auditing. Auditing merely uses our normal slf4j logging facilities, but with a named logger (named `org.apache.accumulo.audit`). This logger can be configured by the user in whatever way they normally configure loggers, which would depend on the specific logging implementation they've configured in their deployment.
   
   They are not necessarily enabled or disabled by default, and editing that file does not necessarily enable them, and it is not true that audit logs are written by default to the same location as the other loggers.
   
   The `conf/log4j-service.properties` file is merely an example. Having our documentation specifically written under the assumption that it is the one way to configure logging, conflicts with the reason a lot of the work was done for logging and scripts in 2.0: that reason being to reduce assumptions in our code about the deployment environment, and thereby giving users greater control.
   
   Documentation should reflect the fact that logging is fully configurable by the user. As far as auditing goes, we should indicate the name of the named slf4j logger we send audit logs to, and point to an the log4j configuration file as an example of what a user could do... but we should not place greater emphasis on the example configuration file we ship than it deserves. After all, it won't even have any effect if they don't have log4j on their class path for their slf4j implementation.

----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
users@infra.apache.org


With regards,
Apache Git Services