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)

Saturday January 11, 2003
04:59 PM

Solid programs II

[ #9906 ]

Adequate programs log errors when things go wrong.
Solid programs also notify the admin when things go wrong,
      and the programmer when insanity strikes.

No-one will actively monitor error logs just for the fun of it. Not for any length of time. So programs need to tell you when they put something in there.

And if the alert e-mails become a major hassle, the problem isn't the numerous e-mails, it's the broken program. Fix the problem (the broken program) to lose the hassle (the e-mail load).

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.
  • This reminds me of the dictum that all programs expand until they can handle email. It's a slippery-slope argument.

    I'd be more inclined to use one of the various monitoring packages that can be configured to look for particular patterns in logsfiles.

    Check out Nagios [nagios.org] for an Open Source monitoring package, and check out the screenshots.

    • I'd say that the concept of active notification is more important than the method.

      Who sends the e-mail or ICQ-message (or inserts the row in the database or whatever) isn't that important.

      One argument for keeping it outside the program (aside from keeping the program as simple as possible) is stability; by keeping the notification mechanism outside you don't risk that the program itself is so screwed up that it can't send e-mail.

      But that may be more of an issue if you write in e.g. C++ or some other lang
      • I think the obvious thing to do is compartmentalise and keep points of failure minimised.

        That is, have the program log somewhere, and have a program such as 'swatch [ucsb.edu]' notify. This way, one could happily replace swatch with something more powerful/flexible. e.g. a POE system that will msg you on irc, or jabber, or wherever as well as email, sms whatever.

        Of course, then you have the problem of "what if my watcher dies".
        --
          ---ict / Spoon