Object oriented configuration

by Andreas Ericsson Email

Ok, so I've been having this idea for quite some time (close to 3 years), but for some reason it has never really interested me all that much; Partially because it's such a radical change, and partially because, at least for a transition period, one would have to support both the new and the old configuration style syntax (perhaps indefinitely).

Since objects in nagios inherit a lot of stuff implicitly in Nagios, it's quite hard to follow how that works.
Since the only *real* object in Nagios is the "host", it doesn't make sense to treat any other object as a *true* object.
I strongly feel that groupings are something that should belong to the user interface only. They should not be so overloaded as they are today ("Oh, you want to view all hosts in areaX together? Sure, make a hostgroup", "Oh, you want to add a service to all hosts of typeX? Sure, make a hostgroup", "Oh, you want to view all hosts of typeX? Sure, make a hostgroup").

Because of this, I hereby propose to create a new configuration file format for Nagios that will
a) Make it easy to assign several services to similar types of hosts.
b) Make it easy to find all hosts of a certain type and group them in (insert-ui-of-choice-here).
c) Save quite a lot on typing.
d) Be a lot clearer regarding its inheritance than the current template system.
e) Make it possible for the community to share host type configuration profiles.
f) Make it possible to add hosts without restarting Nagios.

"Ooh, this bugger sets his goals high", you might think, but the answer to all of the above are actually extremely simple: Object oriented configuration, with object inheritance.

So how would that work? Well, since I can't explain what a nose looks like without getting caught up in all sorts of weird stuff, I'll just show an example here instead.

define host {
  host_name    foo_host
  alias        This is the Foo Host
  address      foo_host.example.com
  type         win2k3-fileserver
}

define host_type {
  host_type_name   win2k3-fileserver
  extends = windows-server
  # this applies to both the host and the services
  contact_groups = fileserver-admins

  service_template {
    check_interval     15
    retry_interval      3
    max_check_attempts  5
  }

  services {
    define service {
      service_description  Disk E
      check_command        check_nt_disk!E
    }

    define service {
      service_description  Disk F
      check_command        check_nt_disk!F
  }
}

# Oops, this host has one disk that no other fileserver has,
# so we define it separately, but we use the service_template
# from that profile anyway
define service {
  use                 win2k3-fileserver::service_template
  host_name           foo_host
  service_description Disk G
  check_command       check_nt_disk!G
}

The best thing is that this could (potentially) be written as a module, although that would (currently) be exceedingly difficult, since the module would then have to take care of preventing core Nagios from detecting errors in the configuration (unless one forces some objects to pre-exist in the regular config files, I dunno). I'm sure it's doable, but it won't be pretty :-/

1 comment

Comment from: john brightman [Visitor] · http://www.whoismark.com
****-
HI
looks very interesting!
bookmarked your blog.
john brightman
05/25/09 @ 09:15

Leave a comment


Your email address will not be revealed on this site.

Your URL will be displayed.
PoorExcellent
(Line breaks become <br />)
(Name, email & website)
(Allow users to contact you through a message form (your email will not be revealed.)