Steve, here is a properties file to illustrate what I'm thinking of (you
can convert this to xml):
log4j.rootLogger=FATAL, base
#your 'normal' logging
log4j.logger.com.mycompany=WARN, normal
log4j.appender.normal=org.apache.log4j.FileAppender
log4j.appender.normal.file=/usr/logs/mylog.log
# normal uses PatternLayout.
log4j.appender.normal.layout=org.apache.log4j.PatternLayout
log4j.appender.normal.layout.ConversionPattern=%c %t %m %n
#your 'heartbeat logging
log4j.logger.hearbeat.com.mycompany=DEBUG, heartbeats
log4j.appender.heartbeats=org.apache.log4j.RollingFileAppender
log4j.appender.heartbeats.file=/usr/logs/myheartbeats.log
log4j.appender.heartbeats.maxFileSize=1MB
log4j.appender.heartbeats.maxBackups=5
# heartbeats uses PatternLayout.
log4j.appender.heartbeats.layout=org.apache.log4j.PatternLayout
log4j.appender.heartbeats.layout.ConversionPattern=%c -- %d{yyyy-MM-dd
HH:mm:ss,SSS}
#end file
Now each class may have two loggers:
Logger nLog = Logger.getLogger(this.getClass());
Logger heartBeat = Logger.getLogger(new String("heartbeat." +
this.getClass().getName()));
calls to heartBeat will go into /usr/logs/myheartbeats.log
calls to nLog will go into /usr/logs/mylog.log
you could also in code easily put a different appender onto each new
Logger (remember to set additivity to false in this case) to track them
all seperately. Since you can control the maximum space taken by the
files (maxBackups * maxFileSize), I -highly- recommend keeping some
record. That way if things start to hang, you will know exactly when
each part of the code died -- this can be a useful audit for
customers/clients/management/etc. I used heartbeat logging at
PacificBell and was very very glad I kept a record of the heartsbeats
for a while. It made it easy to track a lot of problems.
good luck
Kevin
Steve Cohen wrote:
> Thanks, Kevin.
> I'm new at log4j so please excuse these questions about your answer. With the
>special category, would these messages filter into the regular logs or not? Or would
>regular log messages filter into the heartbeat log? I thought the way it worked was
>that only messages above a certain level made it into any log. So one way or the
>other, it would seem that unwanted messages would get into some log. Or does a
>special category live outside the normal hierarchy?
>
> I'm also not entirely comfortable with the notion of preserving past heartbeats in
>the heartbeat log. Maybe I'm just not used to it. How difficult would it be to
>subclass Appender to create an "Overwriting 'Appender'"?
>
>
>
> -----Original Message-----
> From: Kevin Steppe [mailto:[EMAIL PROTECTED]]
> Sent: Tue 4/30/2002 7:03 PM
> To: Log4J Users List
> Cc:
> Subject: Re: Heartbeat Logging?
>
> Steve,
> I would set up a special catagory/logger for heartbeats
> ("myapp.heartbeat.x", "myapp.heartbeat.y", ...). Attach a FileAppender
> to that category which will output the date-time of the logging. Then
> watch the lastModified() date on that file. The lastModified will
> change with every logging, AND you have a record of all the heartbeats
> which can be valuable. Then you can also seperate out different
> heartbeat categories at deploy or run time by changing the config.
>
> Kevin
>
>
> Steve Cohen wrote:
>
>> A cursory glance at the documentation doesn't reveal support for heartbeat logging
>within Log4j.
>>
>> In my company's previous work, we used a roll-your-own logging approach that
>enabled this, in a way that might be considered kludgey. Every logging message
>participating in this scheme would write its most recent logging message into a
>heartbeat file OVERWRITING its previous contents. Monitoring applications could
>simply look at this file's date, and if necessary, the contents of the last message.
>In Log4j terms, it might best be thought of as an Overwriting "Appender"; in "C"
>terms the file was opened with "w" instead of "a".
>>
>> Now, I don't know that we want to continue in this vein, because I realize that it
>is a kludge, as I indicated, but then the question becomes, how best to implement
>heartbeat logging using Log4j?
>>
>> -----------------------------------------------------------------
>> Steve Cohen
>> Sr. Software Engineer
>> Ignite Sports, Inc.
>> [EMAIL PROTECTED]
>>
>>
>>
>> --
>> 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]>
>
>
>
>
> ------------------------------------------------------------------------
>
> --
> To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
> winmail.dat
>
> Content-Type:
>
> application/ms-tnef
> Content-Encoding:
>
> base64
>
>
> ------------------------------------------------------------------------
> attachment.txt
>
> Content-Type:
>
> text/plain
>
>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
