On 06/04/16 00:22, Mario wrote:
Hi JC,
Thanks for your comments.
Using non-numerical names for hosts produced the same results.
10.0.0.139 batman # http://paq depends=(http:superman/conn) testip route:superman 10.0.0.137 superman # http://far testip
Results on your suggestion:
1)batman/http (Down) and superman/conn (Up) --> batman/http (red) (with or without route:superman gives the same result)
This is expected.... you are saying batman relies on superman, so if superman is up, then the status of batman is evaluated purely on it's own merits.
2)batman/http (Down) and batman/conn (down) and superman/conn (Up) --> batman/http (clear) and batman/conn (red)
This is expected.... you are saying batman relies on superman, so if superman is up, then the status of batman is evaluated purely on it's own merits. However, xymon assumes that if conn is down, then all other network tests are "expected" to fail. I'm not sure if xymon will actually still test them, but if it does, and they work, then they should be green, it will just prevent them from going red.
Another variation:
10.0.0.139 batman # http://paq depends=(conn:superman/http) testip route:superman 10.0.0.137 superman # http://far testip
1)batman/conn (Down) and superman/conn (Up) and superman/http (Up)--> batman/conn (red)
Expected, you said batman won't work unless you can ping superman (route:superman) AND http on superman is working. You then said superman conn is up and http is up, so the same as above, batman will simply be evaluated on it's own merits.
My current challenge is because of the implementation of a network solution called Ipanema:
From the site to the data center we have two alternative routes: one through the MPLS network and one through a DMVPN. The Ipanema box decides based on rules which path the traffic takes, and that is on host, port, time of the day, load on the link etc. For ICMP traffic the network team have configured this in such a way that only one of the two paths can be used. If that is down then all ICMP traffic is blocked, even if there is an alternative path still available. That mean, if the path used for ICMP is down, we won’t be able to reach the server using ICMP anymore, but UDP and TCP packages will be rerouted using the one available link.
My challenge is to have Xymon to test the availability of a server combining ICMP and TCP (maybe using depends). We could discard the use of ICMP test and start to use only TCP or maybe SNMP for availability. But not use ICMP is something that I wouldn´t like to do.
My idea is that the conn test will alert only if we have a failure in two tests: ICMP test + TCP test.
For example: • Server A is UP, icmp path is down. The result will be ICMP red AND TCP green = conn test green. • Server A is DOWN, icmp path is down . The result will be ICMP red AND TCP red = conn test red. • Server A is DOWN, icmp path is up. The result will be ICMP red AND TCP red = conn test red. • Server A is UP, icmp path is up. The result will be ICMP green AND TCP green = conn test green.
It sounds like you should stop messing with depends and route etc, allow any test/service to go red as some or all of the infrastructure fails. Try taking a look at combo tests, I forget the details of what it needs to work, but it should allow you to combine multiple test results into a new test result. Simply set alerting to none for all the individual tests, and setup alerting on the various combo tests.
Of course, the other option might be to test the router with a conn test, and then various other tests could rely on this (using route) but I don't think that will work out, since you actually expect TCP to work even when icmp is not working, and route and depends are both designed for the opposite of that (eg prevent things that are expected to fail from turning red when something else fails).
PS, I remember trying to use combo tests for non-network and it wasn't working (in my old version), but I'm pretty sure it works well with network tests.
I hope that helps a little.
Regards, Adam
-- Adam Goryachev Website Managers www.websitemanagers.com.au