in reply to Determining debug levels

My question is: what guidelines you have used for determining what is logged at each debug level?

I've built logging into several enterprise systems to support diagnosis in the field, and have always used simple numeric levels. It's a lot more convenient to write   log("diagnostic stuff") if $DEBUG > 1; (or the equivalent from Log::Dispatch::Config) than it is to wrestle with symbolic names for levels.

Stay simple, and don't get too hung up with a rigid numbering schemes. I've gotten a lot of mileage out of the following:

All warning and error messages go into the log, unconditionally. Each log message is timestamped. That provides a cheap way of doing performance profiling.

95% of the time, turning on level 1 has been sufficient to gather enough info to reproduce the problem locally, if not make it glaringly evident just what had gone off the rails and why. It's amazing how hard it is to believe that users will try certain sequences of actions, or that certain sequence are even possible, until you see hard evidence in the logs.

Replies are listed 'Best First'.
Re: Re: Determining debug levels
by clemburg (Curate) on Feb 28, 2002 at 10:38 UTC

    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

[reply]
      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.

[reply]

        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

[reply]
      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.
[reply]
Re: Re: Determining debug levels
by drewbie (Chaplain) on Feb 28, 2002 at 17:24 UTC
    I think you've hit the nail on the head dws! This is exactly what I was going for. I agree 100% with you on always logging warnings & errors. Right now these apps are very simple, but as they grow having discreet debug levels will help out tremendously. Thanks!
[reply]

In Section Seekers of Perl Wisdom