Our logging set-up is as follows (in a nut-shell):
1) All the system components (except for the logging components themselves)
log to a dedicated JMS Queue using a custom JMSQueueAppender; this is the
portion of the logging setup for which I am using log4j;
2) A queue message consumer picks up the message from the JMS Queue and
performs some additional processing on it. Mainly, this additional
processing consists of "decoding" the LogEvent's Logger and appending to an
appropriate file such that:
Logger = "system.managers" -> file =
${log_base_dir}/system/managers.html
Logger = "session.steve_12345" -> file=
${log_base_dir}/session/steve_12345.html
etc. Plus "rolling" of files is handled here by a custom log-file manager.
3) A logging-admin servlet which allows access to these current log files,
their archives and the overrides.
So, as you can see, searching for log statements related to a particular
user is trivial because it is in a seperate file with the user's name in the
file name.
I had thought of sending everything to the JMS Queue, and then having the
queue consumer perform the override check. This would alleviate the issue,
as you mentioned, because I could then use the NDC approach. However, each
log message is a network call, and because everything will be getting logged
this will add overhead to the app as a whole. Besides, if I am just going
to let everything continue to the JMS Queue, why even use log4j? Its pretty
simple to just have a singleton which handles logging to the queue and would
be much more light-weight then the log4j setup (I know because this is how I
was doing it originally).
The more I think about it, the less I like the NDC approach to this issue.
----- Original Message -----
From: "Mike Brodhead" <[EMAIL PROTECTED]>
To: "Steve Ebersole" <[EMAIL PROTECTED]>
Cc: "Log4J Users List" <[EMAIL PROTECTED]>
Sent: Friday, December 28, 2001 1:10 PM
Subject: Re: freeing up categories/loggers
>
> > I am logging to JMS and NDC does not appear to be a serializable
> > portion of the logging event.
>
> I don't have any insight into the JMS issue, but I will wager
> it is solvable.
>
> > I need to be able to override the log level/threshold on a by-user
> > basis and, in log4j, that seems to require a seperate Logger
> > instance.
>
> I can think of a couple options:
>
> What about using a Filter? (The class lives in org.apache.log4j.spi.)
> By implementing a custom filter, you can examine the NDC and other
> info to decide whether or not to log.
>
> If you can afford to process the logs after the fact, then you could
> achieve the same ends by logging everything and then filtering for the
> information you want after the fact. That is, write a little tool to
> read the log files and grab out the particular parts you are
> interested in.
>
> Depending on your particular needs, the log-reader approach may have
> support advantages. If you are logging everything, then when user
> Fred has a problem, you can look in the log and see a lot of detail
> regarding Fred's actions. If you are filtering per-user before
> writing anything, then you would have to crank the logging level up
> for Fred and wait for the problem to happen again.
>
> Hmm... now that I think about it, there is a third option as well.
> Throw RAM at the problem. In some cases, it may be cheaper to put a
> lot of memory into your servers than to tie up a lot of developer
> resources on the problem. That's not exactly elegant, but I thought
> I'd throw it out there anyway.
>
> If it were me (and it is on my own app), I would go with a log reader.
> Disk is cheap. With per-user priorities in place at runtime, you
> still have the problem of searching out the info for a particular user
> when you read the logs. If you have a lot of users, then there will
> be a lot of irrelevant information to search through.
>
> But again, I don't know your support requirements, so the
> post-processing approach may not work for you.
>
> Good luck,
>
> --mkb
>
>
>
> --
> To unsubscribe, e-mail:
<mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail:
<mailto:[EMAIL PROTECTED]>
>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
