Re: [icinga-users] add and delete hosts for puppet

[Todd Zullinger]

Hi,

david.gar...@gmail.com wrote:

How do you delete a host or add a host? I am using templates and when a box gets moved into another network/vlan (re-provisioned) it triggers a delete on the puppet master. So I only use a single config file for each host.

Some snippets from the icinga::host module:

class icinga::host::config {
...
  # Ensure /etc/nagios exists, the puppet nagios_* types place generated files
  # there.  We'll point to these config files in icinga.cfg.
  file { '/etc/nagios':
    ensure => directory,
  }

  # Ensure the /etc/nagios/nagios_*.cfg files are present so icinga doesn't
  # complain.
  file { [
    '/etc/nagios/nagios_command.cfg',
    '/etc/nagios/nagios_contact.cfg',
    '/etc/nagios/nagios_contactgroup.cfg',
    '/etc/nagios/nagios_host.cfg',
    '/etc/nagios/nagios_hostgroup.cfg',
    '/etc/nagios/nagios_service.cfg',
    '/etc/nagios/nagios_servicegroup.cfg',
    '/etc/nagios/nagios_timeperiod.cfg',
  ]:
    ensure => present,
    owner  => 'root',
    group  => 'icinga',
    mode   => '0664',
    before => File['/etc/icinga/icinga.cfg'],
    notify => Class['icinga::host::service'],
  }
...
  # Collect nagios_* resources

  Nagios_command <<||>> { notify => Class['icinga::host::service'] }
  Nagios_contact <<||>> { notify => Class['icinga::host::service'] }
  Nagios_contactgroup <<||>> { notify => Class['icinga::host::service'] }
  Nagios_host <<||>> { notify => Class['icinga::host::service'] }
  Nagios_hostgroup <<||>> { notify => Class['icinga::host::service'] }
  Nagios_service <<||>> { notify => Class['icinga::host::service'] }
  Nagios_servicegroup <<||>> { notify => Class['icinga::host::service'] }
  Nagios_timeperiod <<||>> { notify => Class['icinga::host::service'] }

  # Purge nagios_* resources
  resources { [
    'nagios_command',
    'nagios_contact',
    'nagios_contactgroup',
    'nagios_host',
    'nagios_hostgroup',
    'nagios_service',
    'nagios_servicegroup',
    'nagios_timeperiod',
  ]:
    purge => true,
  }
}

Then each node include icinga::client which sets up the host resource:

class icinga::client {
...
  @@nagios_host { "$fqdn":
    # This could/should probably be set based on the $kernel fact
    use   => 'linux-server',
    alias => "$hostname",
  }
...
}

Individual services can add service checks like so:

class apache::icinga {
  @@nagios_service { "check_http_${fqdn}":
    check_command       => 'check_http!-w 0.5 -c 2.0',
    host_name           => "$fqdn",
    service_description => "http",
    use                 => 'generic-service',
    require             => Nagios_host["$fqdn"],
  }
}



¹ http://docs.puppetlabs.com/guides/exported_resources.html


Hope that helps,

--
Todd        OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The best leaders inspire by example. When that's not an option, brute
intimidation works pretty well, too.
    -- Demotivators (www.despair.com)

One option is using exported resources in puppet¹. Combined with resource purging, you can have icinga automatically pick up new hosts and services and remove them when a host is decommissioned. We've only got ~100 hosts and ~1800 services at the moment, but this is working fine with icinga running on a small VM (4 cpu/4G ram). Puppet runs do take about 10-15 minutes to complete. The icinga::host module sets up the base config and then collects hosts/commands/services/etc. from other nodes. This allows us to add services to the module where they belong and adding a new node with that module automatically causes it to be monitored. # (The icinga service could just subscribe to these resources too, # which might be a little easier to read.) If the apache class is dropped from a node, it disappears from icinga after puppet runs on the node and then on the icinga box. If a node is shutdown for decommissioning, then we use 'puppet node clean' (or /usr/share/puppet/puppetstoredconfigclean.rb² on puppet < 2.7) to clean its entries from the storeconfig database. That ensures any nagios entries associated with the node are cleaned up in icinga. ² In the Fedora/EPEL packages, other distros may not ship this or may install it elsewhere.

pgpZQaoDpzvnx.pgp
Description: PGP signature

------------------------------------------------------------------------------
Better than sec? Nothing is better than sec when it comes to
monitoring Big Data applications. Try Boundary one-second 
resolution app monitoring today. Free.
http://p.sf.net/sfu/Boundary-dev2dev
_______________________________________________
icinga-users mailing list
icinga-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/icinga-users