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, 04 Oct 2012 18:45:47 GMT

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

Marcelo Vanzin commented on HDFS-3680:

Hi Suresh, I think I addressed all your concerns (will upload new patch after testing).

bq. what is the reason symlink is being done in logAuditEvent? Why is it a part of this jira?

What do you mean "symlink is being done"? I'm not creating any symlinks. I'm creating a FileStatus
object based on an HdfsFileStatus, which is a private audience class and thus cannot be used
in the public audience AuditLogger.

bq. How does one add DefaultAuditLogger with a custom audit loggers? How does isAuditEnabled()
method work if you add an ability to setup DefaultAuditLogger?

I hope I addressed this in the new documentation. For your second question, you should take
a look at the "isDefaultAuditLogger" in FSNamesystem.java.

bq. FSNamesystem#auditLog should be moved to DefaultAuditLogger.

Since that field is public and used in other places, I'd rather not touch that.

bq. Should AuditLogger#logAuditEvent consider throwing IOException to indicate error?

IOException would be one of many exceptions custom audit loggers could throw. So I don't see
why it should be special-cased here. My opinion is that audit loggers in general shouldn't
throw exceptions; if they really want to, having to throw a RuntimeException indicates that
it's not really an expected case.

bq. Sorry I have not caught up all the comments - what is the final decision on how to handle
logger errors? Currently the client gets an exception when logAuditEvent fails. That does
not seem to be correct.

I don't think there was an ultimate decision; my current patch follows the "things work just
like before" approach: currently, if the logging system throws some kind of exception, it
fails the request, just like the new code does. If that's not desired, then it can be changed,
but I think that's outside the scope of this patch.

> 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, hdfs-3680-v6.patch, hdfs-3680-v7.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
For more information on JIRA, see: http://www.atlassian.com/software/jira

View raw message