Mailbag: Can I monitor the Cerb4 parser for problems?
Community, Mailbag, Tips & Tricks November 22nd, 2008
posted by Jeff StandenIs there any way for us to monitor if the parser is encountering errors on incoming e-mail?
-a Cerb4 user
Hey there!
The main reason we added the ?loglevel=3 parameter to the /cron URLs is so it will suppress any unnecessary output when running the scheduler. It should only print errors to the screen (where something like ?loglevel=6 would print more debug/trace information). Traditionally, cronjobs will e-mail any resulting output to an administrator.
In the past we had people redirect output to /dev/null since the cronjob was noisy. We no longer suggest that since it does make sense to be notified if there were any problems parsing (which should be really rare, we audit the parser heavily).
As for a monitoring solution like Cacti or Nagios, we don’t capture every PHP error in Cerb4 since a lot of that could happen before our code has a chance to run or exit cleanly. I suppose you could have something like Nagios tail the PHP error_log, but you’d probably get a lot of pointless notifications. The most dependable notification would likely be the e-mail from the cronjob returning any output. When all goes well it should be silent on ?loglevel=3.
-Jeff@WGM
3 Comments to “Mailbag: Can I monitor the Cerb4 parser for problems?”
Leave a Comment
You must be logged in to post a comment.
What exactly are you classifying as a parser error? I.e. does this include stuff like the potential mail loop arising from same sender/recipient address? If so I think the point is somewhat missed – the error is that Cerberus doesn’t provide a way to recover such mails?
Maybe there’s a need for “dodgy” emails which the parser didn’t like something about to go into some kind of holding queue available only to cerberus admin (with email notification that there’s something there to check on!) and that way we can still see that a customer tried to email us and the contents of that email so that we can respond accordingly – log a new replacement message into the system manually for instance, or call them up etc.
@Damien
Currently the parser does put failed mail into the /cerb4/storage/mail/fail directory. Really, it moves each message into that folder before parsing and cleans up afterwards. If anything halts parsing (ungracefully) then the message is always preserved.
In Cerb3 we did something similar and allowed the GUI to view the messages on the disk. It’s even easier now than then to have a visual interface for retrying any failed mail. I’ll make sure this gets into the project roadmap.
Thanks for writing!
Added a new feature request to JIRA per Jeff’s request. You can track any progress at the following issue.
[Interface] View messaes on disk that failed the parser through the Helpdesk GUI
http://www.wgmdev.com/jira/browse/CHD-957