[hobbit] logic dependencies and combined to alerts
brandste at hebis.de
brandste at hebis.de
Fri Jan 13 14:24:28 CET 2006
Hi Craig,
thanks for the fast answer.
"route" is a tag which follows "ip name # service"
out of that and the "man explanation" i could form
chains starting with SPF?
1.1.1.1 SPF #
1.1.2.1 Switch1 # route:SPF
1.1.3.1 Switch2 # route:SPF
1.1.3.2 Switch2.1 # route:SPF,Switch2
1.1.3.3 Switch2.2 # route:SPF,Switch2
1.1.3.4 Switch2.2.1 # route:SPF,Switch2,Switch2.2
1.1.4.1 Switch3 # route:SPF
Will this work?
In the man page is qouted that the
--ping
option has to be used somewhere...
is --ping the default or do i need do recompile?
This would be a possible workaround...but not a real
satisfying state, cause status is changed to yellow
and not "clear" on failingchains.
Best
Mathias
In message <40A2891842052B40BF0AD6E6A83A9FA002324AA0 at svr-gbn-exc-02.mgc.mentorg
.com>, "Whilding, Craig" writes:
> route:router1,router2,....
>
> This is an option you can add to switches in bb-hosts to do what you
> want. If a switch fails, all those below it will go yellow instead of
> red so you could just alert on red tests and so only get the SPF alert
> you want.=20
> (I use this here).
>
> Craig
>
> -----Original Message-----
> From: brandste at hebis.de [mailto:brandste at hebis.de]=20
> Sent: 13 January 2006 12:52
> To: hobbit at hswn.dk
> Cc: brandste at hebis.de
> Subject: [hobbit] logic dependencies and combined to alerts
>
>
> Hi all,
>
> maybe a stupid question answerd in the mailinglist many times...
> (but i was not able to find it in the archive or interpret
> the man)
>
> As a new convert from bb to hobbit, first Congrats! It's
> far less resource consuming then the former.
>
> We mainly use the tool for network observation, so the conn is
> our friend.
> We have a couple of network-devices located on different
> campi around our location. Each of the campi has a single
> point of failure (SPF) at the entry.=20
> There is only one hobbit (former bb) working.
>
> What i would like to do is, setting up alerts and colorchanges
> depending of the state of the SPF.
>
> Example:
>
> location-1
> SPF - Switch1
> - Switch2 - Switch 2.1
> - Switch 2.2 - Switch 2.2.1
> - Switch3
>
> If SPF fails i do not need to get messages from all the
> Switches behind.
> This i could handle with the tag PAGE in the alerts-cfg.
>
> PAGE=3Dlocation_1
> MAIL "NOC" SERVICE=3Dconn REPEAT=3D1h
> =09
> Using it that way, (if i understood it) the "NOC" receives=20
> one mail per hour if the state changes from location-1.
> Here i have no idea (and not tested) whether this includes Mails
> from all hosts or not.
>
> At this stage i only need a message concerning the incident involving
> SPF.
> If switch1 or switch3 fail, obviously a mail concerning this incident.
> But no mails from connected "sub"-switches...
>
> For receiving a message on a single incident
> Including:
> HOST=3Dswitch1
> MAIL "NOC" SERVICE=3Dconn REPEAT=3D1h
> in the alerts-cfg, generates a mail independent from the former
> PAGE=3D....
> or other settings?
>
> Has anybody found a solution for message dependencies like qouted?
>
>
> ***
>
> Next would be the color change.
>
> Concerning this i found the keyword "depends", but no
> sign that it will work in combination with the conn test....
>
> 1.2.3.4 foo #
> depends=3D(testA:host1/test1,host2/test2),(testB:host3/test3),[...]
>
> 1.1.1.1 SPF #=20
> 1.1.2.1 Switch1 # depends(conn:SPF/conn)
> 1.1.3.1 Switch2 # depends(conn:SPF/conn)
> 1.1.3.2 Switch2.1 # depends(conn:SPF/conn,conn:Switch2/conn)
> 1.1.3.3 Switch2.2 # depends(conn:SPF/conn,conn:Switch2/conn)
> 1.1.3.4 Switch2.2.1 #
> depends(conn:SPF/conn,conn:Switch2/conn,Switch2.2/conn)
> 1.1.4.1 Switch3 # depends(conn:SPF/conn)
>
> would this be the correct usage?
> So if SPF fails, all page behind should be "clear?".
>
>
> Is this possible with hobbit, or a future release?
>
>
> Thanks in advance.
>
> Best
> Mathias
>
> To unsubscribe from the hobbit list, send an e-mail to
> hobbit-unsubscribe at hswn.dk
>
>
>
> To unsubscribe from the hobbit list, send an e-mail to
hobbit-unsubscribe at hswn.dk
>
>
>
More information about the Xymon
mailing list