Re: Logging best practices

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

Comment on Re: Logging best practices

Replies are listed 'Best First'.
Re: Re: Logging best practices by pg (Canon) on May 24, 2004 at 06:14 UTC
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]

Replies are listed 'Best First'.

Re: Re: Logging best practices
by pg (Canon) on May 24, 2004 at 06:14 UTC

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]