[
https://issues.apache.org/jira/browse/HDFS-3680?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13418896#comment-13418896
]
Andy Isaacson commented on HDFS-3680:
-------------------------------------
Those tests aren't implicated by this change, so no worries.
Thank you very much for coding up this plugin interface! I like the core ideas.
What is the expected use case for {{FSAccessLogger}}? Suppose I want to send a
message on a socket (syslog, or any of the message bus protocols). Then my
FSAccessLogger implementation's {{.initialize}} method probably has to do a
fairly heavyweight setup. It seems a bit unfortunate to do that in every
{{FSNamesystem}} constructor. It's not too unusual to have lots of
FSNamesystem objects within a single JVM, and having many sockets (or whatever)
open would be a resource hog.
I'm somewhat inclined to say the FSAccessLogger should be a static singleton in
the FSNamesystem class, largely preserving the existing semantics. I don't know
of a usecase where per-FSNamesystem logging configurability would be useful.
But I can imagine that one might exist, so:
Alternatively we could simply document that FSAccessLogger has to be cheap and
recommend that plugins use a service object or similar (sorry, I don't know the
Design Patterns terminology for this technique, but you make one object that
does the heavy lifting and let all the lightweight client objects find it
through a Factory or whatever).
I don't like the hackiness of your change to {{logAuditEvent}}; I would prefer
to see the existing StringBuilder-based file logging implementation turned into
the premier plugin to the FSAccessLogger interface. As a bonus, this gives us
a feel for how good the plugin interface is to code against.
> Allows customized audit logging in HDFS FSNamesystem
> ----------------------------------------------------
>
> Key: HDFS-3680
> URL: https://issues.apache.org/jira/browse/HDFS-3680
> Project: Hadoop HDFS
> Issue Type: Improvement
> Components: name-node
> Affects Versions: 2.0.0-alpha
> Reporter: Marcelo Vanzin
> Assignee: Marcelo Vanzin
> Priority: Minor
> Attachments: accesslogger-v1.patch, accesslogger-v2.patch
>
>
> Currently, FSNamesystem writes audit logs to a logger; that makes it easy to
> get audit logs in some log file. But it makes it kinda tricky to store audit
> logs in any other way (let's say a database), because it would require the
> code to implement a log appender (and thus know what logging system is
> actually being used underneath the façade), and parse the textual log message
> generated by FSNamesystem.
> I'm attaching a patch that introduces a cleaner interface for this use case.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
