Yeah,
I am currently using exported resources.
} default: {
$nagios_cfgdir = "/usr/local/nagios/etc/objects/default/hosts"
@@file {
"$nagios_cfgdir/${name}.cfg":
ignore => ".svn",
ensure => present,
content => template( "nagios/default_host.cfg" ),
mode => 644, owner => nagios, group => nagios,
tag => 'nagios',
notify => Service[nagios],
recurse => true,
replace => true,
However, I needed finer control of my services for each host so I do this
filtering in a template for each hostgroup. So many exceptions in my
currently environment.
<% if scope.lookupvar('::fqdn') !~ /stg/ %>
define service{
use remote-service ; Name of service
template to use
host_name <%= scope.lookupvar('::fqdn') %>
service_description NRPE CHECK JAMES
check_command check_nrpe!check_james
}
<% end %>
file { "$nrpedir/nrpe.cfg":
mode => "644",
owner => "104",
group => "106",
content => template("nagios/nrpe.cfg"),
ignore => ".svn",
require => Package[$nrpepackage],
}
I don't do auto puppet runs for nagios. I use mcollective to do my work
after testing;).
file { "/usr/lib/nagios/.mcollective/etc/facts.yaml":
mode => "0644",
owner => "104",
group => "106",
loglevel => debug,
content => inline_template("<%= scope.to_hash.reject { |k,v| k.to_s =~
/(uptime_seconds|timestamp|free)/ }.to_yaml %>")
}
On Wed, Apr 11, 2012 at 10:21 AM, Todd Zullinger <t...@pobox.com> wrote:
> 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.
>>
>
> 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<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)
>
>
>
> ------------------------------------------------------------------------------
> 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
>
>
--
David Garvey
------------------------------------------------------------------------------
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
