Nagios Logo
Debian, Linux, Nagios

Tips for Configuring Nagios3 Efficiently – part 1

Leave a comment

Back when I started using Nagios (I think ~1.2 or earlier) I don’t remember many options for being all that efficient in terms of “lines of config written” – certainly, any options for being efficient that there may have been ended up being overlooked in the rush to get it up and running, and I’ve been largely been using the same configuration files (and style) ever since – though I did start using host and service templates as soon as I became aware of them some time back in the 2.x branch days.

In the spirit of self-improvement, I’ve been revisiting the Nagios configuration syntax as part of rolling out a fresh monitoring host based on Nagios3, and have significantly reduced the number of lines of config my Nagios installation depends on as a result.

One of the biggest boons of using anything on Debian these days is the drive towards preconfigured conf.d style of configuration – gone are the giant monolithic config files of old in favour of a series of small targeted config files automatically included at start time. If you’re not using Nagios3 on Debian Wheezy (or newer), I highly recommend making sure you’re using cfg_dir in your nagios configuration to specify a directory you can then drop config snippets in (the creation/deletion of these snippets can then of course trivially be driven by your business logic, provisioning scripts, etc)

So you’ve got Nagios installed and you’re ready to start monitoring every server and router you own. If you’re anything like me when it comes to Nagios. you don’t use (or don’t want to use) any web-based front end for configuring Nagios hosts and/or services (typically these involve a set of database-backed scripts that then spit out a new nagios config file when prudent) and prefer to “roll your own” – so let’s be as smart about this as Nagios lets us.

Host & Service Templates

Learn them. Love them. Fortunately, on the learning front, if you can configure a host, you can configure a host template; a host template is identical in nearly every way to a regular host definition:

define host{
        name                            important
        notifications_enabled           1       
        event_handler_enabled           1       
        flap_detection_enabled          1       
        process_perf_data               1       
        retain_status_information       1       
        retain_nonstatus_information    1       
        contact_groups                  root-admins
        check_command                   check-host-alive
        max_check_attempts              10
        check_period                    24x7
        notification_interval           120
        notification_period             24x7
        notification_options            d,u,r
        register                        0 ; Don't register - this is a template
        }

The magic’s all in the last configuration option – “register 0” which prevents Nagios from processing the host definition normally.

When you later want to use the template, simply specify the template name, or template names, that you want it to use, and your host  definition will inherit everything configured in your template(s):

define host{
        use                     important ; use our new template
        host_name               my-server
        address                 my-server.domain.co.uk
        }

Obviously, the host template I’ve used is specific to our needs, but it’s pretty safe to say that most of you installing Nagios will use a similar sort of configuration – which means you just saved 13 lines of config for every host you configure.

Better still, you can do the same with service templates – which work in exactly the same way. Define template services with register set to 0, and “use” them in your real service definitions. The savings here are potentially far greater – my service template contains 31 lines of configuration I no longer have to specify in service configurations.

If you need to override something on a per-host or per-service basis, just specify the option(s) in that host or service definition and the templates will be overridden.

Configure Services for Hostgroups Rather than Hosts

Hostgroups – not just for grouping hosts in the web interface. Save yourself another chunk of configuration overhead by defining services on a hostgroup rather than host basis:

define hostgroup{
        hostgroup_name          cpanel-servers
        alias                   Hosts running cPanel
        members                 cpanel0,cpanel1
}

define service{
        use                     important-service ; using a template
        hostgroup_name          cpanel-servers    ; applied to a hostgroup
        service_description     FTP
        check_command           check_ftp
        contact_groups          root-admins
}

All of the hosts configured in the hostgroup (and added in future) will now automatically gain an FTP service check. In my case, I have around 10 checks for a standard cPanel server with the nagios NRPE agent deployed on it – but to add a new cPanel server all I have to do is create a host definition and add the host to the hostgroup – easy, fast and consistent configuration.

Configure Services for Multiple Hosts

Sometimes hostgroups aren’t going to work for you – but you’ll probably still have multiple hosts which require common service check configuration – this is a doddle too.

define service{
        use                     important-service
        host_name               server-a,server-b ; comma-delimited list of hosts
        service_description     SSH
        check_command           check_ssh
        contact_groups          root-admins
}

That’s probably enough to get you started. In the coming weeks I’ll write a post with more tips, including info on how to configure parent hosts, as well as service and host dependencies in a smart fashion to avoid unnecessary alert-floods from causing you annoyance.

Leave a Reply