Bugs in servicedependency/notifications 2.0b4+CVS - servicedependency request
John P. Rouillard
rouilj at cs.umb.edu
Fri Sep 30 17:23:27 CEST 2005
Hi all:
Not sure if 2.0 was supposed to be supported on the main nagios list
or not, and since this deals with bugs and development ideas, I figured
here would be better.
One bug is preventing clear notifications when using
servicedependencies.
Also there are a couple of doc bugs.
Also as a feature, I would loke a way to set up dependencies between
two services running on the same machine using specifying multiple
host/hostgroups.
First for the bugs major to minor:
I am not geting a proper clear notification when using
servicedependencies.
I have four services each depending on the other.
Using my check_test plugin I set up the following:
define service{
use generic-service
host_name web_server1
service_description web_service2
is_volatile 0
check_period 24x7
max_check_attempts 3
normal_check_interval 1
retry_check_interval 1
contact_groups admins
notification_interval 15
notification_period 24x7
notification_options w,u,c,r
check_command check_web1
}
which is duplicated for every service (except for a different check
command).
define servicedependency {
name dependency_template
execution_failure_criteria n
notification_failure_criteria w,u,c
register 0
}
define servicedependency {
use dependency_template
dependent_host_name web_server1
dependent_service_description web_service2
host_name web_server1
service_description web_service1
inherits_parent 1
}
define servicedependency {
use dependency_template
dependent_host_name web_server1
dependent_service_description web_service2.1
host_name web_server1
service_description web_service2
inherits_parent 1
}
define servicedependency {
use dependency_template
dependent_host_name web_server1
dependent_service_description web_service2.1.1
host_name web_server1
service_description web_service2.1
inherits_parent 1
}
define servicedependency {
use dependency_template
dependent_host_name web_server1
dependent_service_description web_service3
host_name web_server1
service_description web_service2
inherits_parent 1
}
If I set three services to critical:
service2.1.1 which depends on service2.1 which depends on
service2
I correctly get critical notification only for service 2.
Now if I put service1 (which is depended on by service2) in critical
mode and let that notification go through, and then bring service2 up
(ok), I get the service down notification for service1, but I never
get a service up notification for service2.
Service2 is displayed as OK in the web interface.
When I set service1 to ok, I get the notification of ok status for
service1 as expected, but I don't get a delayed or other notification
for service2 in the OK state.
Also I get the service critical alert for service2.1 as expected.
I think that the notification for service2 should be sent since a
critical alert went out for it. This is needed when a different group
of people respond to the service2 event as compared to the service1
event. If the down notification for service2 never went out I wouldn't
be concerned. I could also agree (but somewhat less strongly) with
sending the OK status for service2 out after service1 goes to an OK
status.
BUG2
The use of hostgroups in the service dependency definition:
/nagios/docs/xodtemplate.html isn't documented.
BUG3
If you set up a service dependency and use the "inherit_parent" parent
directive and set it to "yes" rather then 1, nagios doesn't give you
an error, it treats it as a 0. It should probably complain.
FEATURE REQUEST
A way to set up dependencies between two services running on the same
machine using specifying multiple host/hostgroups. When you have a farm
of machines, it is useful to be able to specify the dependencies
between services running on a given host using a hostgroup to supply
the names of all the hosts. I suggest making the dependent_host (or
hostgroup) optional. So that the example from:
nagios/docs/templatetricks.html:
define servicedependency{
hostgroup_name HOSTGROUP1,HOSTGROUP2
service_description SERVICE1
dependent_hostgroup_name HOSTGROUP3,HOSTGROUP4
dependent_service_description SERVICE2
other dependency directives ...
}
That sets up a dependency between each host in groups 3 and 4 on ALL
of the hosts in groups 1 and 2 have a variant like:
define servicedependency{
hostgroup_name HOSTGROUP1,HOSTGROUP2
service_description SERVICE1
dependent_service_description SERVICE2
other dependency directives ...
}
that would make SERVICE1 on every host in group 1 and 2 depend on
SERVICE2 on the same host. I.E. it would be like specifying:
define servicedependency{
host_name HOSTGROUP1_host1
service_description SERVICE1
dependent_host_name HOSTGROUP1_host1
dependent_service_description SERVICE2
other dependency directives ...
}
define servicedependency{
host_name HOSTGROUP1_host2
service_description SERVICE1
dependent_host_name HOSTGROUP1_host2
dependent_service_description SERVICE2
other dependency directives ...
}
etc. This would mean that the dependent_host* keywords are optional,
but I suppose the special host SELF could be used as in:
define servicedependency{
hostgroup_name HOSTGROUP1,HOSTGROUP2
service_description SERVICE1
dependent_hostgroup_name SELF
dependent_service_description SERVICE2
other dependency directives ...
}
Specifying this inter-service dependency for the same host is really a
pain. Even when using a preprocessor such as filepp to generate the
configs, its annoying. For just one host I have 20 of these
dependencies on the master service ssh and the dependent services that
use check_by_ssh.
This leads to the very compact and easy to read:
define servicedependency{
hostgroup_name HOSTGROUP1,HOSTGROUP2
service_description sshd
dependent_hostgroup_name SELF
dependent_servicegroup_name check_by_ssh_services,ssh_login_services
other dependency directives ...
}
Quips, comments suggestions or answers?
-- rouilj
John Rouillard
===========================================================================
My employers don't acknowledge my existence much less my opinions.
-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
More information about the Developers
mailing list