Re: Changing monitor action behaviour

Peter Polkinghorne (Peter.Polkinghorne@brunel.ac.uk)
Tue, 22 Apr 1997 09:30:22 +0100

> Hi,
>
> I'd like to add email, logging, and paging to my list of actions.
> Before I do that, though, I'd like to make a change such that only one
> email or page or log entry will be made when a device goes down.

Ed,
I have done this - with MoJoChAction for changes - only a variant of
ip_monitor.tcl at present. There is a bug (which I mean to fix), that the
colour change does not go back if more than error condition occurs (ie stays
red). Here is my original announcement:

Peter.Polkinghorne@brunel.ac.uk said:
> I have produced a variation on the ip_monitor.tcl that came with
> scotty-2.1.4 (for some reason I have not yet installed 2.1.5):
>
> ftp://ftp.brunel.ac.uk/cc/peter/bru_ip_monitor.tcl.gz
>
> The changes are as follows:
>
> a) add a MoJoChAction() procedure - that can optionally:
> i) change color
> ii) write to log window
> iii) syslog
>
> b) change "Check Reachability" to take advantage of the
> MoJoChAction() procedure. Also eliminated some redundant code - in
> particular the color change and flash items.
>
> c) add "Check DNS Reachability" - this uses DNS to expand a hostname
> (name attribute) to list of addresses of interfaces and checks
> reachability of all of these.
>
> The rationale for these were to enable checking of all interfaces and
> to do the logging in a delta fashion, rather than say every
> interation X is down.

Here also are some further notes about the changes I made:

Peter.Polkinghorne@brunel.ac.uk said:
> If the MoJoChAction() is acceptable, it and a few associatiated
> routines that were changed could be folded back into library.tcl,
> though taking advantage of MoJoChAction() requires recoding of other
> monitoring procedures.
>
> This did also raise further questions (some for my variation) and
> some for Juergen:
>
> a) The color change item is unpleasant, in that you need to save
> previous color and work out when to change back - when all
> interfaces OK again? how do you handle jobs being killed and
> started? Currently goes red for 1..n start of alarm condition and
> goes back to original for first end of alarm.
>
> b) The MoJo code seems to assume one monitor job per object - since
> saves some state as Monitor:ThresholdAction attribute.
>
> c) I had to create a "none" attribute to prevent the defaults (
> default(Monitor.ThresholdAction) ) I set up from affecting the
> monitor jobs.
>
> d) Where should the state information for monitor jobs go? Some is in
> global arrays and some is in node attributes?
>
> Anyhow I hope these modifications may be of use ... do let me know
> what changes etc are needed.

-- 
-----------------------------------------------------------------------------
| Peter Polkinghorne, Computer Centre, Brunel University, Uxbridge, UB8 3PH,|
| Peter.Polkinghorne@brunel.ac.uk   +44 1895 274000 x2561       UK          |
-----------------------------------------------------------------------------

--
!! This message is brought to you via the `tkined & scotty' mailing list.
!! Please do not reply to this message to unsubscribe. To subscribe or
!! unsubscribe, send a mail message to <tkined-request@ibr.cs.tu-bs.de>.
!! See http://wwwsnmp.cs.utwente.nl/~schoenw/scotty/ for more information.