[Mon-commit] mon/doc mon.8,1.1.1.1.2.4,1.1.1.1.2.5

[Jim T. <tr...@us...>]

Update of /cvsroot/mon/mon/doc
In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv28354/doc

Modified Files:
      Tag: mon-1-0-0pre1
	mon.8 
Log Message:
updated to explain alertevery strict| ignore_summary | observe_detail

Index: mon.8
===================================================================
RCS file: /cvsroot/mon/mon/doc/mon.8,v
retrieving revision 1.1.1.1.2.4
retrieving revision 1.1.1.1.2.5
diff -C2 -d -r1.1.1.1.2.4 -r1.1.1.1.2.5
*** mon.8	13 Aug 2004 04:15:17 -0000	1.1.1.1.2.4
--- mon.8	19 Nov 2004 18:26:22 -0000	1.1.1.1.2.5
***************
*** 41,46 ****
  was designed to be open in the sense that it supports arbitrary
  monitoring facilities and alert methods via a common interface, which
! are easily implemented through programs (in C, Perl, shell, etc.), 
! SNMP traps, and special Mon (UDP packet) traps.
  
  .SH OPTIONS
--- 41,46 ----
  was designed to be open in the sense that it supports arbitrary
  monitoring facilities and alert methods via a common interface, which
! are easily implemented through programs (in C, Perl, shell, etc.)
! and special Mon (UDP packet) traps.
  
  .SH OPTIONS
***************
*** 194,198 ****
  resource which is provided by a group. Services are usually modeled after
  things such as an SMTP server, ICMP echo capability, server disk space
! availability, or SNMP events.
  .TP
  .BI watch
--- 194,198 ----
  resource which is provided by a group. Services are usually modeled after
  things such as an SMTP server, ICMP echo capability, server disk space
! availability, or SNMP queries.
  .TP
  .BI watch
***************
*** 368,375 ****
  If an alert was already sent within the last
  .B alertevery
! interval, do not send another alert,
! .I unless
! the summary output from the current monitor program differs from the last
! monitor process.
  Otherwise, send an alert using each alert program
  listed for that period. The
--- 368,375 ----
  If an alert was already sent within the last
  .B alertevery
! interval and the monitor has continued to report a nonzero exit
! status for a time period
! less than that interval, do not send another alert,
! unless the summary output from the most recent monitor process differs from the previous.
  Otherwise, send an alert using each alert program
  listed for that period. The
***************
*** 385,392 ****
  The reasoning is that if the summary output changes, then
  a significant event occurred and the user should be alerted.
! The "strict" argument to alertevery will suppress both
! comparing the output from the previous monitor run to the current
! and prevent a successful return value of the monitor from
! resetting the alertevery timer. For example, "alertevery 24h strict"
  will only send out an alert once every 24 hours, regardless of
  whether the monitor output changes, or if the service stops and then
--- 385,397 ----
  The reasoning is that if the summary output changes, then
  a significant event occurred and the user should be alerted.
! The "ignore_summary" option will suppress all successive
! alerts while the service continues to fail, even if the
! summary output changes.
! If the "strict"
! alertevery option is
! used, then behave the same as if "ignore_summary" was
! set, but do not reset the alertevery timer when
! the monitor exits with a zero status.
! For example, "alertevery 24h strict"
  will only send out an alert once every 24 hours, regardless of
  whether the monitor output changes, or if the service stops and then
***************
*** 1145,1151 ****
  variable, and limits the number of times an alert
  is sent when the service continues to fail.
! For example, if the interval is "1h", then only
  the alerts in the period section will only
! be triggered once every hour. If the
  .B alertevery
  keyword is
--- 1150,1159 ----
  variable, and limits the number of times an alert
  is sent when the service continues to fail.
! For example, if the interval is "1h", then
  the alerts in the period section will only
! be triggered once every hour as the service continues to fail.
! The alertevery interval timer will be reset if the monitor
! stops exiting with a nonzero exit status (i.e. it reports a success).
! If the
  .B alertevery
  keyword is