--------------48879504A58FA472C4B86AC1
Content-Type: text/plain;
charset=us-ascii
Content-Transfer-Encoding: 7bit
ok
the only way to find that out would be to set up a dummy check like you
are trying to explain,
and assign a depency of a to b to c
make c fail,
then make a fail,
there is your answer.
IE:
service A messages file check
service B volume check
service C message file check
in this instance B would never really go down, but you could make C go
down and also A
and then you would have your answer,
BUT:::
how could A not depend on C? can you give me an example of what you are
saying? B is dependent on C therefore logically A should be dependent on
C also.
by defining B as dependent on C you assign A as dependent on C also. I
would think, the only way not to make A dependent on C would be to break
the dependency of C and B
should we check A if C is down? why would you want to? A is dependent on
B, but B cant do anything cause C aint working,
realworld context
A is a volume we are checking and alerted on
b is a machine we are pinging that has that volume
c is the router
if C is down i cant get to B, so regardless if A is working or not, C
needs to be fixed before i can get to A
do i want to check A ? how can i check A ? A is not dependent on C but
in reality i cant get to A because i cant get to B until i can get to
B, there is no need to check A,
this would work with Dependencies of A:a B:b and C:c as well and
actually just adds confusion to the mix rather than clarity.
even if you use my little test, as you can see, A and C are the same
test, B is a test that would never fail, but we have made an
association of C to B to C a logical path of, check A if B is ok And
Check B if C is ok,
C is not ok, therefore we cant check B because we cant check B A
shouldnt be checked, no matter how you look at it, A must depend on C
cause we told it to depend on B.
hope this helps
Kenneth Ray
[I sent this to nagios-users, but got no response. Maybe some people
here
know?
Sorry for the crossposty behavior - Karl]
Hello everybody,
I have a question regarding service dependencies when there is a chain
of
them. Let's say we have a set of dependencies such as this:
A:a -> B:b -> C:c
So service a on host A depends on service b on host B which depends on
service c on host C.
Let's say that A:a does NOT depend on C:c via a servicedependency
object.
My question is: if C:c goes down, causing B:b not to execute or send
notices
(due to the criteria set), what happens to A:a and its checks? I know
Nagios does not recursively follow the dependencies. I believe,
according
to how I read the documentation, that the last "known" HARD (or SOFT, if
you
have it defined) state on B:b is used in the logic. Does anybody know
if
this is correct? So if B:b stops executing due to the
execution_failure_criteria setting, is the last known state the one used
until it executes next time?
My second question is regarding the efficiencies of the service
dependency
code. Say I have a configurator which can intelligently follow
recursive
dependencies. (I do) Is there any sort of major performance penalty in
defining many service dependencies? It seems as though it shoudl be
fairly
efficient, but I wanted to make sure. This would affect whether I would
be
aggressive or conservative in defining recursive dependencies. There is
certainly a great amount of fudge factor thrown in due to timing checks,
but
there might be some situations where following a dependency chain makes
sense.
While on this subject, a feature that might be nice for the future: an
option to set the state a service is in should a dependency fail. I.e.,
if
A:a depends on B:b, and B:b fails, we should be able to set A:a to
"critical" rather than it having to execute a check. Otherwise, if I
don't
want A:a checked while B:b is failed, then it'll be "OK" potentially, or
have to continue to be checked.. Sound useful? Something like
"failed_state CRITICAL" in servicedependency object which sets the
service
state and the "blurb" to "Failed dependency". Am I mis
...[email truncated]...
This post was automatically imported from historical nagios-devel mailing list archives
Original poster: kray1@travelersla.com