RFC/RFP Service sets

[Rune "TheFlyingCorpse" Darrud]

On Thu, 09 Jun 2011 22:10:19 +0200, Rune "TheFlyingCorpse" Darrud  
<theflyingcorpse at gmail.com> wrote:

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

Looking at the code, there are possibly a few ways to Rome to achieve this:
A)
- Copy the existing hostgroup way of giving out sets of services to hosts.
- Add the new attributes which can then be inherited.
-++

B)
- Write a new function to allocate services to hosts.
-- 1) Assigning each service to its host after expanding service sets.
-- 2) Assign the service set directly to host, less complex startup, but  
requires expansion afterwards, which can break compatability with a lot of  
NEB modules.

C)
- Write a new function to allocate services to hosts, create a new service  
definition used internally in service sets, for easier and less complex  
changes. Downside is codebase will grow much more than B)
-- 1) Assigning each service to its host after expanding service sets.
-- 2) Assign the service set directly to host, less complex startup, but  
requires expansion afterwards, which can break compatability with a lot of  
NEB modules.


There should also be some discussions around what linking between service  
sets are allowed/permitted, for different reasons of coding complexity.
- Do one only allow services to be defined in a set, inside the sets  
brackets, and not from outside it? Example
define serviceset{
	name	serviceset-uberset
	use	serviceset-template
	parents	MySQL
	define service{
		description	MySQL
	}
	define service{
		description	MySQL Query Cache Hitrate
		.....
	}

	define service{
		description	MySQL Connection Time
		.....
	}
}

OR should the code also allow:

define serviceset{
	name	serviceset-uberset
	use	serviceset-template
	parents	MySQL
	define service{
		description	MySQL
	}
	define service{
		description	MySQL Query Cache Hitrate
		.....
	}

	define service{
		description	MySQL Connection Time
		.....
	}
}

define service{
	description	MySQL Index Usage
	servicesets	serviceset-uberset
	...
}

The deciding factor between these 2 options will help to say how the code  
should be implemented.
I've written up some changes in the core that reads a sample  
serviceset(without sub-services, working on that atm)

What about service-set overlapping of service definitions? Spit out a  
warning where duplicate found?
What about a service set containing a parent, not defined inside the  
service set, but in a different one, thats also applied to the host? (If  
its not applied to the host, config error, should be inheritable!)


Input welcome!


Regards,
Rune "TheFlyingCorpse" Darrud


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