Dependency sytem in Hobbit

Marganne, Etienne emarganne at be.tiauto.com
Fri Jan 19 12:58:25 CET 2007


Hello all,

 

I am Etienne Marganne, a new comer in TI Automotive, a society which uses
Hobbit as a monitoring tool, I will be in charge of Hobbit tool. We would
like to enhance our monitoring tool in order to get more detailed
informations through it.

 

One of the first thing we would like to do is to create a dependency system
between monitored hosts across our network. For all the further discussion,
please keep in mind that we have a very large network and two Hobbit servers
where we would like to keep the same "hh-hosts" file. 

The idea of the dependency system is the following one: once we have a host
that fails on a network path in our network all the hosts further that one
will be very likely unreachable. This will cause a lot of alerts to be
triggered because of one failure. This is not interesting because our team
will be flooded by those alerts. Therefore it could be useful to create
dependencies so that those further devices on the same path will not trigger
alerts (basically turning red).

There is a specific tag that can be used to do such a work, the "route" tag.
In our case with two Hobbit servers, we would tune that with the
"route_BBLOCATION" tag. Knowing that there are Hobbit clients on all the
network nodes between the two endpoints, the simplest idea would be to list
all the nodes in the description of those tags. This could work even if it
would generate of job. A little bit further here, let's say that one node
fails on a path, it is very probable that if you know that the following
nodes are unreachable, you may not want to test them anymore (to forbid them
to turn red). 

 

Now think of a big network with a lot of redundancy, it is very probable
that there will be indeed a lot of network paths between a server and one
final host. If on one path one node fails, it does not mean that the final
client is not reachable. But with the "route" tag, that client would be
signal as unreachable since a member of the "route" has failed. This is not
comfortable at all. 

 

What we would like to know, or to get, if there is a way to get this
dependency system work: 

 

Hobbit Server A ---- 1 ---- 2 ---- 3 ---- 4 ---- Final Client

                  |                                         |

                  | --------- 5 ------------6 ----------- | 

 

There are two paths to reach the Final Client, one composed by 1, 2, 3, 4
and another one composed by 5, 6. 

With the current "route" tag we would have such a list of nodes:
route_HobbitServerA:1,2,3,4,5,6 then if 1 fails and the path 1-2-3-4 would
not work anymore but the 5-6 one would still. 

 

A good dependency system would to have such a thing: Final Client depends on
4, 4 depends on 3, 3 depends on 2, 2 depends on 1 but Final Clients also
depends on 6 which depends on 5. More over this would also solve that kind
of topology :

Hobbit Server A ---- 1 ---- 2 ---- 3 ---- 4 ---- Final Client

                  |                    |                    |

                  | --------- 5 ------------6 ----------- |          Where
there is a link between 2 and 5, 2 and 6, 5 and 3, 6 and 3.

 

Maybe that something could be set up with the "depends" tag, however I do
not know how the informations will propagate through the different
dependencies done that tag.

 

 

Even further on the topic, the "route" tag performs only ping tests which
does not seem enough to me. I would like to add cpu, disks, ... tests to the
whole dependency system.

 

 

Thank you for your help and answers,

 

Regards,

 

Etienne Marganne

TI Automotive.

 

 



The information contained in this transmission may contain privileged and confidential information.  It is intended only for the use of the person(s) named above. If you are not the intended recipient, you are hereby notified that any review, dissemination, distribution or duplication of this communication is strictly prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.xymon.com/pipermail/xymon/attachments/20070119/b92314f5/attachment.html>


More information about the Xymon mailing list