Hi, [email protected] 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.
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.
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
# (The icinga service could just subscribe to these resources too,
# which might be a little easier to read.)
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"],
}
}
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.
¹ http://docs.puppetlabs.com/guides/exported_resources.html² In the Fedora/EPEL packages, other distros may not ship this or may install it elsewhere.
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)
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 [email protected] https://lists.sourceforge.net/lists/listinfo/icinga-users
