RFC/RFP Service sets

[Rune "TheFlyingCorpse" Darrud]

On Tue, 17 May 2011 14:27:17 +0200, Andreas Ericsson <ae at op5.se> wrote:

> 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.

I highly suggest that this concept gets tried out. Nesting WILL be usable  
elsewhere too and this makes it very readable (like a version of JSON) YES  
there might be some people complaining but it is in my eyes needed to  
advance and take nagios into the next decade.

How are you thinking in terms of expanding this ?
I've started to make a mind map of how it could work.

I think it would be really cool if we could use service-set as a  
combination of a group and a template, by this I mean that you can set  
"any" attribute in the service-set that the subservice inherits, unless  
the service is populated with extra data, using : to not fill in a parent,  
but rather force a non-inheritance without any values inserted in its  
place, would also be usefull where you dont want it to inherit, without  
anything better to put there, like a parent of status on the RDP port,  
when you use the NSClient for other checks to the host.


define service_set {
	name     windows-services
	use      windows-service-template
	contact_groups  windows-admins
	parents         NSClient
	check_period 16x7
	max_check_attempts 5
	define service {
		description    NSClient ; parent of all the others
		check_period 24x7 ; This attribute replaces inheritance of the group  
check_period of 24x7, so its easier to mass update a group and give for  
just one across a set/group.
		max_check_attempts 2 ; This
		...
	}
	define service {
		description Disk usage C
		check_command  check_nsclient!C!80!90
		...
	}

	define service {
		description World Wide Web Service
		check_command  check_nsclient!CheckServiceState!World Wide Web Service
		...
	}

	define service {
		description HTTP Company Site
		check_command check_http!-u http://company-site-in-NLB.se
		parents	World Wide Web Service  ; This replaces inheritance, to a  
difference service (which is a child of the one(s) set by the service-set.
		...
	}

	define service {
		description RDP
		check_command check_tcp!3389
		:parents ; Dont inherit from parent, because this doesnt depend on  
NSClient.
		...
	}
}


> --%<--%<--%<--%<--%<--
> # 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.

Not only is it harder to separate and such, its harder to read and  
understand, without a tool. Large setups with 10k+ checks, I believe dont  
use tools for the entire config, because it might be too complex. It wont  
get easier with this concept, making the leap to use it harder without a  
(few) good tool(s).

>
> 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.
>


-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/


------------------------------------------------------------------------------
EditLive Enterprise is the world's most technically advanced content
authoring tool. Experience the power of Track Changes, Inline Image
Editing and ensure content is compliant with Accessibility Checking.
http://p.sf.net/sfu/ephox-dev2dev