Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

jplindstrom (594)

jplindstrom
  (email not shown publicly)

Journal of jplindstrom (594)

Sunday January 12, 2003
02:35 PM

Solid programs III

[ #9916 ]

Logging isn't for when things go right, it's for when things go wrong.
But you don't know when things go wrong until it already happened,
        so log everything, all the time, and rotate often.

In one family of programs we have two levels of logging: Error and Debug. However, I find that in production it's never useful to turn off debug-logging, because that level of detail is actually useful when an error strikes.

In my programs I usually have three levels of logging: Info, Error, Fatal Error, and Debug. The admin is notified of Fatal Errors. The other logs provide more information.

I've been thinking of a "smart" error logging facility; you log debug and error-messages as usual, but the smart error logging will keep track of the n most recent debug messages at all times. When an actual error is logged, the recent debug lines are also written to the error log, providing the context that lead to the error. The subsequent n debug messages will also be written to the error log, providing details of what happened as a result of the error (if anything).

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • Years back I implemented a circular queue error log, which would keep n messages in memory and dump the log to disk on error. The advantage of having the log in memory was that it would still be displayable if the application dumped core. (Ah, the joys of working in C...)

    We logged each user "gesture" (entered "foo" in the bar field, clicked OK, etc.), which gave us a trail of breadcrumbs to follow to repeat the failure, though in practice we rarely had to look back more than a dozen entries from the end o

  • It is for the implementation of this type of level logging that I use Log::Log4perl [cpan.org] - This module incorporates a very flexible category and class logging system which allows for differing log actions to be defined based upon the class and level of the invoking log message. These actions include logging to DBI handle, email, file, syslog or screen.

    If does not currently incorporate the type of contextual logging which you seek, but would form an excellent base from which to build an alternate logging platfo