Switching Debug Info On and Off

[martin j logan]

...allow users of either logging mechanism to implement there
> finalizing policy for a file that has just been wrapped.

That would be,  ...allow users of either logging mechanism to implement
their own specific finalizing policy for a file that has just been
wrapped.

Woops :-( should make better sense now.

\Martin


On Fri, 2003-02-21 at 13:49, martin j logan wrote:
> 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.
> > 
> 
>