Switching Debug Info On and Off

[martin j logan]

We have two logging solutions here. The first is vl_elwrap_h, written
primarily by our very own Hal Snyder, it is an event handler that is
hung off error_logger event manager. It exports handle_call/info/event.
It discovers the location of sasl and error_logger files and wraps them
according to user specs. Every time a logging call is issued this
handlers handle_event function is called, via error_logger event
manager, and vl_elwrap_h checks the size of the sasl and error_logger
files. If the size limit has been reached then the current file is
renamed <current file name>.<integer> a new <current file name> file is
then opened and the old descripter closed. The module is resistant to
crashes and will be re-added following a restart of the error_logger
manager. This is accomplished via gen_event:add_sup_handler/3. If anyone
would like it I can inquire about that, should be no problem.

We also have a home-brewed module that wraps files in the same way and
logs our own special format:) This is useful for all of those special
cases.

I am thinking that perhaps a callback could be optionally defined that
would allow users of either logging mechanism to implement there
finalizing policy for a file that has just been wrapped. This function
could be defined thus CallBackModule:wrapped(WrappedFileName)

Anyway thats what were doing, minus the callback blurb.  

Cheers,
Martin

On Fri, 2003-02-21 at 11:54, Sean Hinde wrote:
> > Matthias Lang <matthias@REDACTED> writes:
> > 
> > > How do others handle logging? 
> > 
> 
> We use the standard tools with a slightly tweaked version of the error
> handler which will forward error reports to anyone connected to a tcp/ip
> server.
> 
> Our support teams use the rb tools OK (though in nasty faults the logs can
> wrap alarmingly quickly).
> 
> I agree though that there are some unfortunate limitations, including all
> those posted on the list.
> 
> It would also be nice to be able to automatically wrap a log after specified
> periods and have the older logs moved out of the way (and gzipped why not)
> rather than deleted.
> 
> Sean
> 
> 
> 
>  NOTICE AND DISCLAIMER:
> This email (including attachments) is confidential.  If you have received
> this email in error please notify the sender immediately and delete this
> email from your system without copying or disseminating it or placing any
> reliance upon its contents.  We cannot accept liability for any breaches of
> confidence arising through use of email.  Any opinions expressed in this
> email (including attachments) are those of the author and do not necessarily
> reflect our opinions.  We will not accept responsibility for any commitments
> made by our employees outside the scope of our business.  We do not warrant
> the accuracy or completeness of such information.
>