Service Template Inheritance

Ken Netzorg knetzorg at gmail.com
Mon Mar 23 16:59:35 CET 2009


I am working on setting up Nagios for the first time and am trying to search
different forums to find my answers, but it appears forums.meulie.net has
been down for several days (or I can't seem to get there from my network)
and SF is giving me Search Server timeout errors when I try and search this
forum.
This is a long way of apologizing up front if this question is therefore
redundant to topics already covered at length in the past.

I am struggling with getting service template inheritance to work properly
as it relates to placing the check_command in an inherited "template"

I did see a brief post about this from around 2003, but I wasn't able to
fully follow the chain.

Having read the documentation and doing some pondering, I am looking to
break my service monitoring into two notification trees: Production and
Development. That way, I am not bothered by development services alerting
off hours and only get production notifications off hours. (If there is a
better way to set this up, I'm open to suggestions.) Additionally, when I am
working with one platform, I can define the one command centrally and not
have to worry about changing it in several places if I choose to go a
different route.

Therefore, I am setting up my services as follows:

define service {
     name global_service      # All the settings found in the global-service
example in the quickstart setup
     ....
     register 0
}

define service {     name  windows_service
     use  global_service
     servicegroups windows_services  # This will group all windows services
together
     register  0
}


# Define the central definition of Client Version
define service {
     name w_client_version   # Windows Service, get Client Version of
NSClient++
     use  windows_service
     service_description     NSClient Version
     check_command     check_nt!CLIENTVERSION
     register 0         # Don't register this yet as it will be referenced
later!
}

# No inheritance here, begin the production shell of notification periods to
override any global settings
define service {
     name    production_service
     notification_period  24x7        # Set 24x7 notification and other
intervals/options
     .....
     register 0
}

## Now for putting the command and the service level together such that it
is production and will notify based on the production_service entry when the
w_client_version command is executed:
define service {
     name     production_client_version
     use      production_service,w_client_version          # Merge the
Production definition with the service command
}

I keep getting an error when validating the configuration (nagios -v
nagios.cfg) that the w_client_version is a duplicate within the config files
and I have searched for it only finding it in one location.

Can the check_command only be defined at the lowest level? Is this a valid
configuration or are there better examples of separating development alerts
from production alerts?

(I'm using Nagios v 3.0.6)

Thanks,
Ken
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.monitoring-lists.org/archive/users/attachments/20090323/382f0914/attachment.html>
-------------- next part --------------
------------------------------------------------------------------------------
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
-------------- next part --------------
_______________________________________________
Nagios-users mailing list
Nagios-users at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nagios-users
::: Please include Nagios version, plugin version (-v) and OS when reporting any issue. 
::: Messages without supporting info will risk being sent to /dev/null


More information about the Users mailing list