http://qs1969.pair.com?node_id=148182


in reply to Re: Determining debug levels
in thread Determining debug levels

Words of wisdom these are, the words of brother dws. I agree wholeheartedly. Especially the remark about logging *all* warning and error messages. In these days of cheap disk space, freely available filtering languages like our beloved Perl, and fast editors with good search commands, selective logging of warnings and errors is almost certainly the wrong choice. Remember, you can always filter downstream, but if valuable information is ignored, you will never get it back.

And always remember you have other options than just log to a file - you can log to a database, too, and get all kinds of nifty features for free - easy reporting, triggers (like, send email if inserted record has priority level > 3 and text like "%boss%"), etc. I have seen whole system management environments being built around this idea, since it is so much more natural for most people to work with data in a database than with data in files (non-Perl people, that is :-) ... ). Heck, imagine the possibilities: you can just store a mapping of problem categories to people, and have your supporters (or even users) just get their daily reports (or triggered emails, or ... ) where they will find their problems to work on - with direct information from your applications.

Christian Lemburg
Brainbench MVP for Perl
http://www.brainbench.com

Replies are listed 'Best First'.
Re: Re: Re: Determining debug levels
by dws (Chancellor) on Feb 28, 2002 at 10:49 UTC
    In these days of cheap disk space, freely available filtering languages like our beloved Perl, and fast editors with good search commands, selective logging of warnings and errors is almost certainly the wrong choice. Remember, you can always filter downstream, but if valuable information is ignored, you will never get it back.

    That's a good point. Big logs are much less of a problem that in bygone days.

    Still, if you go this way, be sure to do a back-of-the-envelope calculation to guestimate how much disk space your logs will grow per day. You'll also want to have some sort of log aging scheme. Having a system roll over in the field because the disk filled up can be embarrassing, especially when everyone claims it can't happen.

      Log aging scheme - that was the word I was looking for (this was the "etc." free features in my previous post about logging to a database). One point more for the database side. Note that most database systems have monitoring tools that will alert you to conditions like database filling up. Also, usually a well-thought out aging/backup scheme is applied to databases used for real applications, so you get that for free, too.

      Christian Lemburg
      Brainbench MVP for Perl
      http://www.brainbench.com

Re: Re: Re: Determining debug levels
by drewbie (Chaplain) on Feb 28, 2002 at 17:28 UTC
    Excellent idea! I could have all kinds of fun w/ logging to a database. The stuff I'm writing now is too small to be worth the effort, but I can envision all kinds of fun reports. Now that you've mentioned it. I've done some database logging in the past and it's very cool to be able to use SQL to seach for problems, rather than grep & regexes. Idea noted.