water has asked for the wisdom of the Perl Monks concerning the following question:

Hi

Anyone have suggestions on best-practices for logging in perl? We have several perl processes that run (via cron) regularly. Our thinking was to have one master log that captures the start and stop (and work done) of each processes, as well as captures any warnings or errors (maybe via Log::WarnDie?). In addition to the master log that gets high-level info on everything and gets errors, there would be app-specific "chatter" logs for more information about each app, as needed.

Looking for advice on one-log vs. many-logs, strategies for logging, helpful modules, any advice

thanks for any ideas

water, water, everywhere....

Replies are listed 'Best First'.
Re: Logging best practices
by exussum0 (Vicar) on May 23, 2004 at 12:52 UTC
    My first suggestion is to use somethign like log4perl.

    Look at your code and look at the log levels.

    • If you die, you should probably fatal before hand.
    • If you warn, you should prolly replace that with an error or warn.
    • If someone is doing something potentially bad, definitely use warn.
    • If you do something that's very important, or against the user's expectations, you can use info.
    • If it's "important" debug wise, use debug.
    After knowing what to log, it's a matter of preference from tere on out. Anything that isn't debugging information can usually be logged somewhere permanently, as they shouldn't happen too often. But then again, it depends on hwo you use it. Log4perl provides nice facilities to shoot log messages anywhere. And if you have a real time conifguration option, you can then tweak your app as its running, in case something goes awry.

    good luck.

    Humma la beeba la seeba la booba la
    Humma la beeba la seeba la bop
[reply]
Re: Logging best practices
by saintmike (Vicar) on May 23, 2004 at 16:31 UTC
    Log::Log4perl provides log levels and log categories to accomplish exactly the kind of behaviour you want.

    To configure your application in order to log messages of different log levels to different files, take a look at this particular FAQ.

    As for having chatter logs and error logs, that's pretty common. However, typically, applications put both debug and error messages into the chatty log files (and errors-only into the error log files) because errors don't use much additional disk space but provide valuable contextual info in the chatty log files. But that's up to you, Log::Log4perl allows for both ways.

    For a general overview on Log::Log4perl, check out this article or the documentation.

[reply]
Re: Logging best practices
by pg (Canon) on May 24, 2004 at 00:15 UTC

    As others have already suggested, you can use log4perl.

    The next thing, which is probably more important, is what to log. Base on my experiences, those are the three most important types of information that will definitly help you to debug your code, and to understand potential problems:

    • Entering and exiting a sub;
    • The pameters passed to a sub call and the parameters a parameter received (log both, don't assume that what you passed in is what being received);
    • Information help you determine which logical branch is actually executed.

    For multi-threading programs, have a thread id attached to each thread, so logs are lucid.

[reply]
Re: Logging best practices
by zakzebrowski (Curate) on May 24, 2004 at 00:17 UTC
    A different approach, if you are in a closed / trusted environment, is to send mail from the application or cron job directly to the user who caused the problem... This is allbeit not as full fledged nor scalable solution as Log4Perl provides, but has less of a learning curve, and may be perferable depending on how much time you wish to devote to getting everyone to agree on a standard method of logging. You could also send critical error messages to a mail list of people... Perl modules such as Mail::Sendmail are lightweight and allows for quick integration. Cheers.


    ----
    Zak - the office
[reply]

      This is definitely a good suggestion, but should not replace the log itself.

      What I usually do is to have all the details go to log, but when serious problem happens, send a piece of email to the programmer or suport personel, so thet are notified to check the log. You obviously do not want to put too much details in email. Email is more like sort of alert.

      You don't usually send email to user, instead error or warning message should pop up right in front of him/her. You don't expect user care too much about non-business related emails.

[reply]
Re: Logging best practices
by petdance (Parson) on May 24, 2004 at 01:39 UTC
[reply]
      Log::Log4perl uses Log::Dispatch internally to accomplish writing messages to various output channels (files, screen, email etc.) when it's time to write them. Log::Dispatch provides what Log::Log4perl calls appenders, sinks for output.

      However, the question was how to write error messages into one file and debug messages into another. How would you do that without a framework around Log::Dispatch?

[reply]

Back to Seekers of Perl Wisdom