Problem: Users want instant notification without notification flooding.
Examples: Send a text message when an unhandled exception is thrown, but only 1 per day. When a new loan request form is submitted send an email, unless an email was sent in the past hour.
Solution: Store the datetime of the last sent notification and check it before sending a new notification.
This simple solution is often forgotten and replaced by a service that polls solution. I like Notification without Flood much more because you can use the existing application without requiring creation of a service.
If you are concerned about volume of email notifications, then I'd say either your app is flakey, or your logging things as errors that shouldn't be errors (see something I wrote earlier which helps me focus on where exceptions should and shouldn't be logged). Bottom line: people consistently forget that logging is a user interface, and should be developed as such. As a developer you wouldn't dream of sticking a combo box on a screen unless the user/customer wanted it - the same rigor should be applied to logging.
ReplyDeleteIf you are in a situation where hundreds of error messages are the norm then consider a centralised logging system capable of sending out different types of notifications based on rules - this is easy to achieve using log4j's socket appender, or by rolling your own HttpAppender. Even better, ditch email for the non-fatal stuff and use RSS...
I wasn't suggesting this solution as an alternative to logging. However, it can be a great addition to logging.
ReplyDeleteAdditionally, this solution shouldn't be viewed as simply another way of error reporting.
The solution solves the problem of sending notifications without sending too many. In examples the second example shown is an actual requirement from a previous project.