home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / vmsnet / networks / tcpip / multinet / 2787 < prev    next >
Encoding:
Internet Message Format  |  1993-01-28  |  4.6 KB
  1. Path: sparky!uunet!stanford.edu!bu.edu!rpi!usc!howland.reston.ans.net!sol.ctr.columbia.edu!hamblin.math.byu.edu!arizona.edu!mvb.saic.com!info-multinet
  2. From: RAS@GV3.CACD.CR.ROCKWELL.COM (Robert A. Schneider II . 299/106-180 . 435-3863)
  3. Newsgroups: vmsnet.networks.tcp-ip.multinet
  4. Subject: RE: mail problem
  5. Message-ID: <930127074724.2200271a@GV3.CACD.CR.ROCKWELL.COM>
  6. Date: 27 Jan 93 13:47:24 GMT
  7. Organization: Info-Multinet<==>Vmsnet.Networks.Tcp-Ip.Multinet Gateway
  8. Lines: 70
  9. X-Gateway-Source-Info: Mailing List
  10.  
  11.  
  12. >> There are very few computer/network applications in our environment that 
  13. >> don't provide an immediate indication when an error occurs.  Unfortunately
  14. >> one of our most critical computer/network applications (e-mail) is an
  15. >> application that doesn't provide immediate notification.  Do any Multinet 
  16. >> sites have an automated alarm system to determine when e-mail is not being 
  17. >> delivered?  Waiting for user complaints is not appropriate in our business.
  18. >
  19. >This sort of system-level monitoring of the overall health of the email system
  20. >is quite a different problem than per-user-per-message reporting. Although
  21. >probe messages are a useful tool, it is usually more important to monitor
  22. >aggregrate statistics like message queue sizes, mean time to delivery, and so
  23. >on.
  24.  
  25. I agree that the aggregrate statistics are useful, especially for a system
  26. which functions as a central e-mail hub.  However, many of our users are on
  27. workstations that receive mail directly (POP and IMAP are rarely used).  
  28. Aggregrate statistics aren't really needed on the workstations, but a prompt
  29. indication that e-mail isn't going through is.
  30.  
  31. Very rarely does e-mail not deliver a message from a local user to a local
  32. user.  The local mail system is either up or down and it is very obvious to
  33. the user community if it is down.  E-mail delivery problems tend to occur 
  34. in delivering a message to a remote node.  It is these messages where 
  35. nondelivery notification is needed.  And it is these problems which are 
  36. often caught by the e-mail probes.
  37.  
  38. >The problem with monitoring and reporting on email is that email itself often
  39. >as not is the tool of choice for providing notification about application
  40. >errors. (For example, the print symbiont we use locally reports PostScript
  41. >errors via email.) But if there's a problem in the email system the last thing
  42. >you want to use to report it is email! I've seen email-reports-on-email setups
  43. >go into catastrophic overload and meltdown on more than one occasion; one such
  44. >mess took several days of staff time to clean up.
  45.  
  46. Very true.  However, realistically, what other method is available to deliver
  47. a message to a user who may or may not be logged in when the message is
  48. issued?  Sending messages to the user's terminal doesn't guarantee 100% 
  49. delivery (user may not be logged in).  Perhaps an error file could be written 
  50. in the user's home directory and the login process could display the file 
  51. contents at login, but many users only log in 2 or 3 times a day, so this 
  52. wouldn't be a timely mechanism.  But neither of these mechanism work well
  53. if the user is on a remote node.  E-mail seems to be the most appropriate
  54. method.
  55.  
  56. >The obvious tool to use for this sort of monitoring would be SNMP, of course.
  57. >(I won't bother to explain SNMP's characteristics that make it a good choice
  58. >here.) However, application monitoring with SNMP has received almost total
  59. >neglect in IETF circles -- I don't know why this is so, but it sure is!
  60.  
  61. If an SNMP station is not monitored 7 X 24, how do you propose to deliver 
  62. the SNMP messages to the cognizant people?  Often those individuals who 
  63. support the environment have multiple responsibilities.  Even when support 
  64. is distributed amongst several individuals, they may not invoke an application
  65. to check SNMP status indicators frequently enough to respond quickly to an
  66. alarm condition.  However, I can guarantee that any support person who is 
  67. logged in (or who has just logged in and is doing a quick scan of received 
  68. mail) will respond quickly to a mail message received from "ALARM@MONITOR."
  69.  
  70. Yes SNMP could gather statistics and signal alarm conditions.  But, 
  71. realistically speaking, I believe most sites will want to use e-mail to 
  72. deliver the alarms and statistics to the cognizant support staff.  
  73.  
  74. Now when client-server functionality truely becomes a commodity within the
  75. support community (i.e. the SNMP stations fully support X-windows and all 
  76. the support staff have X-window display capability on their desktop) this 
  77. may change.  Until then, rightly or wrongly, e-mail will the mechanism of 
  78. choice for most users and application developers.
  79.  
  80. Bob
  81.