You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@logging.apache.org by Pat Felsted <pf...@novell.com> on 2006/06/15 00:47:21 UTC
auditing and log4j
I am trying to get a feel of some usage of log4j pertaining to
application auditing. Do you all feel that many use it more for
debugging or is auditing also a common use of it? If it is used for
auditing would it make sense to have a audit method? I have searched
the archives and not seen any talk of audit. Are there projects or
communities that use log4j for auditing that you can refer me to?
Thanks.
Pat
Re: auditing and log4j
Posted by Pat Felsted <pf...@novell.com>.
Great, you feel log4j is a good mechanism for auditing. Where auditing
is as a category of logged messages. Thanks for the info.
Pat
>>> Curt Arnold <ca...@apache.org> 6/14/2006 6:17 PM >>>
On Jun 14, 2006, at 6:54 PM, Pat Felsted wrote:
> Thanks for the response. So are you suggesting there is a better
> way to audit, since you say the purpose of log4j is diagnostics?
> If so do you have suggestions?
>
> Thanks again.
> Pat
>
That was not what I was saying. I was saying that log4j is capable
of serving many different roles, but since diagnostic logging is the
most common use, people think it is the only thing it can do well.
In the same way, they think that logger names have to be the same as
class names. I was suggesting using loggers named after business
entities or actions for "audit" type messages and loggers named after
classes for "diagnostic" type messages. In your configuration, you
can disable or route the diagnostic messages to an destination
appropriate for diagnostians and route the audit messages to a
destination appropriate for auditors.
Re: auditing and log4j
Posted by Curt Arnold <ca...@apache.org>.
On Jun 14, 2006, at 6:54 PM, Pat Felsted wrote:
> Thanks for the response. So are you suggesting there is a better
> way to audit, since you say the purpose of log4j is diagnostics?
> If so do you have suggestions?
>
> Thanks again.
> Pat
>
That was not what I was saying. I was saying that log4j is capable
of serving many different roles, but since diagnostic logging is the
most common use, people think it is the only thing it can do well.
In the same way, they think that logger names have to be the same as
class names. I was suggesting using loggers named after business
entities or actions for "audit" type messages and loggers named after
classes for "diagnostic" type messages. In your configuration, you
can disable or route the diagnostic messages to an destination
appropriate for diagnostians and route the audit messages to a
destination appropriate for auditors.
Re: auditing and log4j
Posted by Pat Felsted <pf...@novell.com>.
Thanks for the response. So are you suggesting there is a better way to
audit, since you say the purpose of log4j is diagnostics? If so do you
have suggestions?
Thanks again.
Pat
>>> Curt Arnold <ca...@apache.org> 6/14/2006 5:36 PM >>>
On Jun 14, 2006, at 5:47 PM, Pat Felsted wrote:
> I am trying to get a feel of some usage of log4j pertaining to
> application auditing. Do you all feel that many use it more for
> debugging or is auditing also a common use of it? If it is used
> for auditing would it make sense to have a audit method? I have
> searched the archives and not seen any talk of audit. Are there
> projects or communities that use log4j for auditing that you can
> refer me to?
>
> Thanks.
> Pat
Additional discussion would be best handled on log4j-user. This list
is reserved for discussions that affect the Logging Services Project
as a whole or don't fit into any of the existing logging frameworks.
The most common use of log4j is to process what I would call
"diagnostic" messages. Messages that are intended to help a
diagnostician (developer or administrator) resolve some observed
problem. Since in many cases interpreting these messages require
some understanding of the code and program flow, it is natural that
class names are used as logger names.
Since that pattern is so prevalent, many people that loggers have to
be named after classes and log4j is only useful for diagnostic
logging. For "business" or "audit" messages, the class name is not
the most useful organizational pattern since the auditor may not have
knowledge of the code and program flow. For this type of use, you
might want to name loggers something like "audit.security" or
"audit.customer.address". In your configuration, you could set the
root logger to handle diagnostic messages and then set the "audit"
logger to go to a different destination (and possibly set additivity
to false so audit messages don't flow into the diagnostic log).
Your suggestion of an audit method is likely a suggestion that there
should be an AUDIT level like the existing DEBUG, INFO, WARN, etc.
However, I believe that "audit" is more an indication of the target
audience of the message and therefore is appropriately done using the
logger name which exists to categorize messages by topic or intended
audience. If you did treat AUDIT as a level, you would lose the
distinction between a severe audit message (when an action might
break a law or cause serious financial harm) and informational audit
messages (like a particular user logged out) unless you added levels
for AUDIT_INFO, AUDIT_WARN, etc.
Re: auditing and log4j
Posted by Curt Arnold <ca...@apache.org>.
On Jun 14, 2006, at 5:47 PM, Pat Felsted wrote:
> I am trying to get a feel of some usage of log4j pertaining to
> application auditing. Do you all feel that many use it more for
> debugging or is auditing also a common use of it? If it is used
> for auditing would it make sense to have a audit method? I have
> searched the archives and not seen any talk of audit. Are there
> projects or communities that use log4j for auditing that you can
> refer me to?
>
> Thanks.
> Pat
Additional discussion would be best handled on log4j-user. This list
is reserved for discussions that affect the Logging Services Project
as a whole or don't fit into any of the existing logging frameworks.
The most common use of log4j is to process what I would call
"diagnostic" messages. Messages that are intended to help a
diagnostician (developer or administrator) resolve some observed
problem. Since in many cases interpreting these messages require
some understanding of the code and program flow, it is natural that
class names are used as logger names.
Since that pattern is so prevalent, many people that loggers have to
be named after classes and log4j is only useful for diagnostic
logging. For "business" or "audit" messages, the class name is not
the most useful organizational pattern since the auditor may not have
knowledge of the code and program flow. For this type of use, you
might want to name loggers something like "audit.security" or
"audit.customer.address". In your configuration, you could set the
root logger to handle diagnostic messages and then set the "audit"
logger to go to a different destination (and possibly set additivity
to false so audit messages don't flow into the diagnostic log).
Your suggestion of an audit method is likely a suggestion that there
should be an AUDIT level like the existing DEBUG, INFO, WARN, etc.
However, I believe that "audit" is more an indication of the target
audience of the message and therefore is appropriately done using the
logger name which exists to categorize messages by topic or intended
audience. If you did treat AUDIT as a level, you would lose the
distinction between a severe audit message (when an action might
break a law or cause serious financial harm) and informational audit
messages (like a particular user logged out) unless you added levels
for AUDIT_INFO, AUDIT_WARN, etc.