This is a cool feature of mcollective.

I can aggregate checks. Still not implemented in nagios however.

[root@nagios3 manifests]# /usr/local/nagios/libexec/check-mc-nrpe -F product_info=/SomeProduct/ check_load
check_load: OK: 17 WARNING: 0 CRITICAL: 0 UNKNOWN: 0|total=17 ok=17 warn=0 crit=0 unknown=0 checktime=0.274174
[root@nagios3 manifests]#

On Wed, Apr 11, 2012 at 11:30 AM, david.garvey@gmail.com <david.garvey@gmail.com> wrote:
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 <tmz@pobox.com> wrote:
Hi,


david.garvey@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
² 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



--
David Garvey