Added by Brian DeShong, last edited by Brian DeShong on Feb 01, 2008  (view change) show comment

Labels

 
(None)

Zend Framework: Zend_Log_Writer_Mail Component Proposal

Proposed Component Name Zend_Log_Writer_Mail
Developer Notes http://framework.zend.com/wiki/display/ZFDEV/Zend_Log_Writer_Mail
Proposers Brian DeShong
Revision 1.0 - 26 January 2008 - Initial creation (wiki revision: 18)

Table of Contents

1. Overview

Zend_Log_Writer_Mail is a Zend_Log writer for sending log entries to recipient(s) via email.

Proposal of this class is motivated by use in a batch script environment, where logs need to be kept, but developers also need to be notified via email of any notices, warnings, errors, etc.; will be illustrated below in "Use Cases."

2. References

3. Component Requirements, Constraints, and Acceptance Criteria

  • This component will attempt to deliver appropriate log entries to given recipient(s)
  • This component will adhere to standard Zend_Log_Writer formatting and filtering conventions
  • This component will not open connections to the Zend_Mail transport until a message is ready to be sent

4. Dependencies on Other Framework Components

  • Zend_Mail
  • Zend_Log_Writer_Abstract

5. Theory of Operation

User instantiates a Zend_Mail object and populates it with data for recipients that should be notified of any log entries. Zend_Mail object is then passed to constructor for Zend_Log_Writer_Mail object.

Zend_Log_Writer_Mail::_write() builds up an array of log entry lines to use as the body of the email message to the recipients.

Email should not be sent upon the call of Zend_Log_Writer_Mail::_write(); the email should be sent upon the call to shutdown() if there are log entry lines to use in the body.

Once email has been sent to recipients, reference to Zend_Mail object is NOT removed as the user may want to continue using it.

6. Milestones / Tasks

  • Milestone 1: [DONE] Initial class code is drafted for proposal
  • Milestone 2: [DONE] Proposal finalized and readied for review
  • Milestone 3: Working prototype checked in to incubator for community review
  • Milestone 3: Unit tests are created with 90%+ code coverage (assume that we can't test the actual receiving of email?)
  • Milestone 4: Initial documentation completed

7. Class Index

  • Zend_Log_Writer_Mail

8. Use Cases

UC-01

UC-02
UC-03

9. Class Skeletons

Whats happening in a case when you got more than one message of one type. Do you get a Mail per message, or do you collect messages of one type and sending all messages in one mail?

You only get one email with all of the log messages in it, regardless of what their log level is.

Note how write() builds up an array of the log entries, while shutdown() actually sends the email to the recipient(s).

Does that make it a bit more clear?

HI

Yes thanks. Thats good. I think this log writer is a good enhancement.
But, as Lars said already - Sometimes this behavior is wanted but generaly it can be a great danger to send logs via mail on every request.
Perhaps it would be better to have two options for this writer. First Option ,lets say a Collector, which collects the logs in a serialized form in a file and sends it on a defined time or in an defined interval.
And the other option right this way you proposed it already.

Tom

But as far as I understand, you get one mail per request? Logging straightly per mail is considered a bad practice as it increased the danger of getting dossed by accident. If error XYZ (the one, where you send the mail) occurs it will likely occur more often and therefore the application might bring down the mail server too. So I'm not sure if it is a good idea to include such a component in general.

In this case, the developer could implement Zend_Log_Filter_Interface when determining if the log entry should be accepted. The mechanics of this would be something along the lines of storing recently-sent log entries in persistent storage (a temp file, for example) and checking if that entry has been sent within the past X minutes.

My personal argument is that if, say, you're writing a file with a batch process, but have run out of disk space, the developer(s) should be notified so they can work to correct that problem ASAP. In an event such as this, receiving a regular email goes a long way to getting someone notified of the problem and having it dealt with in a timely manner.

Point being: some cases need frequent sending of these emails, while you may want to be more forgiving with others. You leave this choice up to the developer by allowing them to use a filter.

What do you think?

I agree that the developer should decide if it's ok to use this.

+1

I'm using this implementation in a new project and it seems to work fine. I'm filtering the log messages to mail at a very low level (Zend_Log::CRIT). The rest is logged into a database.

A nice other tric I did, was to initially set the level for the mail writer to Zend_Log::WARN, and when the database connection is succesful I alter the filter level to Zend_Log::CRIT (subclassed Zend_Log_Filter_Priority with a setPriority() function)

Hey Vincent,

Wow, that's great news! You're the first I've heard of anyone (other than myself) actually using this. Feel free to post any additional questions or comments here. Maybe we can get the class into the incubator soon.

I'm using it without problems