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