Object oriented configuration
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
looks very interesting!
bookmarked your blog.
john brightman
10/07/08 11:53:08 am, 