home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / vmsnet / networks / tcpip / multinet / 2786 < prev    next >
Encoding:
Internet Message Format  |  1993-01-28  |  3.3 KB
  1. Path: sparky!uunet!stanford.edu!bu.edu!lll-winken!uwm.edu!spool.mu.edu!howland.reston.ans.net!usc!news.service.uci.edu!unogate!mvb.saic.com!info-multinet
  2. From: NED@SIGURD.INNOSOFT.COM (Ned Freed)
  3. Newsgroups: vmsnet.networks.tcp-ip.multinet
  4. Subject: RE: mail problem
  5. Message-ID: <01GTZNGPT3T68Y4XEH@SIGURD.INNOSOFT.COM>
  6. Date: 27 Jan 93 04:21:44 GMT
  7. Organization: Info-Multinet<==>Vmsnet.Networks.Tcp-Ip.Multinet Gateway
  8. Lines: 50
  9. X-Gateway-Source-Info: Mailing List
  10.  
  11. > There are very few computer/network applications in our environment that 
  12. > don't provide an immediate indication when an error occurs.  Unfortunately
  13. > one of our most critical computer/network applications (e-mail) is an
  14. > application that doesn't provide immediate notification.  Do any Multinet 
  15. > sites have an automated alarm system to determine when e-mail is not being 
  16. > delivered?  Waiting for user complaints is not appropriate in our business.
  17.  
  18. This sort of system-level monitoring of the overall health of the email system
  19. is quite a different problem than per-user-per-message reporting. Although
  20. probe messages are a useful tool, it is usually more important to monitor
  21. aggregrate statistics like message queue sizes, mean time to delivery, and so
  22. on.
  23.  
  24. The problem with monitoring and reporting on email is that email itself often
  25. as not is the tool of choice for providing notification about application
  26. errors. (For example, the print symbiont we use locally reports PostScript
  27. errors via email.) But if there's a problem in the email system the last thing
  28. you want to use to report it is email! I've seen email-reports-on-email setups
  29. go into catastrophic overload and meltdown on more than one occasion; one such
  30. mess took several days of staff time to clean up.
  31.  
  32. The obvious tool to use for this sort of monitoring would be SNMP, of course.
  33. (I won't bother to explain SNMP's characteristics that make it a good choice
  34. here.) However, application monitoring with SNMP has received almost total
  35. neglect in IETF circles -- I don't know why this is so, but it sure is!
  36.  
  37. There is a very rudimentary Applications MIB that provides facilities for
  38. monitoring mail systems and directory services. However, in my opinion
  39. it is not suitable at present for serious production use.
  40.  
  41. But there is some hope -- there's a new IETF working group called MADMAN (Mail
  42. And Directory Management) whose task is to put together a pair of MIBs for
  43. monitoring mail and directory systems. The group is off to a slow start but I
  44. am hopeful that things will begin to move in the near future.
  45.  
  46. > >The only thing that's unreliable about nondelivery notices is the inconsistency
  47. > >of their generation. However, users adapt amazingly quickly to the nature of
  48. > >the systems they use, so they usually take these differences in stride.
  49.  
  50. > And the amount of time that must pass before they are generated.  The default
  51. > value on systems here ranges from 7 days to a few hours.  The user community
  52. > prefers a standard delay (preferably single digit hours), but that is hard
  53. > to implement when some vendors hardcode this value.
  54.  
  55. Not only must this be settable to a wide range of values, it also must
  56. vary from one service to the next. User expectations of email, FAX, and pagers,
  57. for example, are quite different. PMDF, for example, provides per-hour
  58. or per-day units that can be set on a per-channel basis.
  59.  
  60.                 Ned
  61.