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.gar...@gmail.com <
david.gar...@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 <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
>
--
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
