[Nagios-devel] RFC/RFP Service sets

[Matt Simmons]

Hi,

On first glance, I liked the nested config example, but after thinking
about it for a little while, I'm starting to lean toward specifying
the service_sets per service. In cases where multiple groups
contribute to the Nagios configuration of an entity, doing this will
allow each group to "subscribe" their services, and file permissions
on the individual cfg files can be maintained, whereas storing things
in the nested service_set object requires everyone to be able to write
to that (plus it adds some additional complexity).

For what it's worth, I'm one of those people who are using host groups
to assign services to machines because I like being able to minimize
my work and maximize my results, and that's the shortest cut I've seen
so far. This replaces that functionality nicely, I think.

--Matt


On Tue, May 17, 2011 at 8:27 AM, 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.
>
>
> --%<--%<--%<--%<--%<--
> # 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-devel mailing list
> Nagios-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/nagios-devel
>



-- 
LITTLE GIRL: But which cookie will you eat FIRST?
COOKIE MONSTER: Me think you have misconception of cookie-eating process.

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