Nagios Support Forum

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.



...[email truncated]...


This post was automatically imported from historical nagios-devel mailing list archives
Original poster: [email protected]