hadoop-hdfs-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Marcelo Vanzin (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HDFS-3680) Allows customized audit logging in HDFS FSNamesystem
Date Thu, 02 Aug 2012 00:44:04 GMT

    [ https://issues.apache.org/jira/browse/HDFS-3680?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13427045#comment-13427045

Marcelo Vanzin commented on HDFS-3680:

bq. I think you are missing my point. Misbehaving loggers should be removed. But given the
importance of audit logging, if the error condition associated with that logger is fixed,
we need a mechanism to reinstate that logger back without having to restart the namenode.

How can you know that the error condition was fixed, if you have no idea of what it was in
the first place? How can you know that a logger that threw a NullPointerException will now
stop throwing it?

Which is why I took the simpler approach, which is not to make assumptions. The only thing
that needs to be settled, in my view, is what to do when the logger throws an exception: ignore
(and log it), and hope it will recover by itself in subsequent calls, or log, loudly, that
the logger failed, and stop using that logger.

I understand the importance of audit logging, but I think that anybody who's implementing
an audit logger should understand that too, and make their logger resilient to errors. There's
very little the FSNamesystem code can do other than the two options above, from what I can
> 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, hdfs-3680-v3.patch,
hdfs-3680-v4.patch, hdfs-3680-v5.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


View raw message