Concoct some scheme for monitoring mailin/mailout
Bug #386097 reported by
Paul Everitt
This bug affects 1 person
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
KARL3 |
Fix Released
|
Medium
|
LarsN |
Bug Description
HIstorically, email-in and email-out have been brittle, mysterious operations. When they fail, we're the last to know.
This task is purposely vague. Namely, implement some ways in which we know if things are wedged, or when things bounced, or when things succeeded. Suggestions:
- Provide a URL that shows the last N processed and bounced. Show some minimal forensics: time, from, to, subject, reason for bounce.
Changed in karl3: | |
assignee: | nobody → Chris Rossi (chris-archimedeanco) |
milestone: | m18 → m19 |
To post a comment you must log in.
I think this should be something compatible with whatever Six Feet Up uses to monitor. One idea would be to have a couple of WSGI apps that we wire in that check the status of mailin and mailout and return a simple text response ("Ok" or "Error") along with corresponding status code (200, 500). Six Feet Up can wire their monitoring app to poll the url's of these two apps.
As far as what the monitoring apps actually do, they can probably just watch for the accumulation of mail in the corresponding maildirs--if mail is starting to stack up, then signal a problem.