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

Mime
View raw message