RFC/RFP Service sets

[Andreas Ericsson]

Ahoy (again).

One of the ideas that surfaced on the Nagios developer meeting in
Bolzano was a concept dubbed "service sets". Consider them basically
"partial host service profiles" and you'll have roughly the right
idea.

The benefits of adding service sets is that users can share config
settings for various types of hosts rather than some particular check,
and also that the question "does Nagios support monitoring X?" is
quite easily answerable on a higher level than "no, but you can add
checks for this and that, and this too, so it sort of does anyway",
which tends to leave people who have no idea of how Nagios works
quite baffled.

There are two implementation suggestions so far, perhaps best explained
in sample configuration:

--%<--%<--%<--%<--%<--
# compound-in-compound style (aka, "extended template style"):
define service_set {
	name     windows-services
	use      windows-service-template
	contact_groups  windows-admins
	parents         NSClient

	define service {
		description    NSClient ; parent of all the others
		...
	}
	define service {
		description Disk usage C
		check_command  check_nsclient!C!80!90
		....
	}
}

define service_set {
	use database-service-template
	name psql-services
	contact_groups db-admins
	parents PSQL Listener

	define service {
		description PSQL Listener; parent of the other ones
		....
	}
	define service {
		description Cache hit ratio
		...
	}
	define service {
		description Slow queries
		...
	}
}

define host {
	host_name         win-psql1
	service_sets      windows-services,psql-services
}
--%<--%<--%<--%<--%<--
Pros:
* Less typing.
* Config is more normalized with less redundant information.
* Service sets can also double as templates for the services
  they contain.
* A service-set is obviously safe-contained and quite easy to
  share under whatever name the recipient wishes to set for it.
* Rules can be set so that the 'parents' directive inside a
  service_set has to refer to a service inside the service_set,
  for which the parents directive is then ignored.
* The service set object will always be created when we're adding
  services to it, so we needn't stash them separately for adding
  later (ie, much easier to parse).

Cons:
* The config style used means current config parsers have to be
  modified to grok multi-level compounds in order to understand
  service-sets.


--%<--%<--%<--%<--%<--
# regular object-by-object style
define service {
	use windows-service-template
	description      Disk usage C
	service_sets     windows-services
	parents          NSClient
	...
}

define service {
	use windows-service-template
	description      NSClient
	service_sets     windows-services
	...
}

define service {
	use database-service-template
	description     PSQL Listener
	service_sets    psql-services
	...
}

define service {
	use database-service-template
	description     Cache hit ratio
	parents         PSQL Listener
	service_sets    psql-services
	...
}

define service {
	use database-service-template
	parents PSQL Listener
	description Slow queries
	service_sets psql-services
	...
}

define host {
	host_name         win-psql1
	service_sets      windows-services,psql-services
}
--%<--%<--%<--%<--%<--
Pros:
* Can be used very nearly seamlessly with the current configuration
  parser.
* Current config parsers need very little modification to work.
* A single service can belong to many service sets without requiring
  duplication.

Cons:
* Harder to separate and isolate service sets for sharing.
* Services get overloaded so they have to belong to either a host,
  a hostgroup or a service_set, which leads to more complex logic.
* Service sets will require lookups and they can't be parsed as
  efficiently as the compound-in-compound method.


Please note that the current way of specifying services will still
continue to work, although I'd quite like to deprecate adding
services to hostgroups sometime in the near future, as I feel we're
overloading group objects quite enough as it is. A conversion tool
to create service sets out of the hostgroup-enslaved services would
have to be written before the deprecation and before the end of the
support for such configs though.

Comments, patches and conversion tools are very welcome.

Authors of configuration UI's should take plan to ignore both the
service_sets variable in objects and the service_set object type
sometime soon, so they will continue to work before the format is
set in stone but after we've started implementing this.

-- 
Andreas Ericsson                   andreas.ericsson at op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Considering the successes of the wars on alcohol, poverty, drugs and
terror, I think we should give some serious thought to declaring war
on peace.

------------------------------------------------------------------------------
Achieve unprecedented app performance and reliability
What every C/C++ and Fortran developer should know.
Learn how Intel has extended the reach of its next-generation tools
to help boost performance applications - inlcuding clusters.
http://p.sf.net/sfu/intel-dev2devmay
_______________________________________________
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