Options_hash parameter on nagios::service

[Fran Rodríguez]

Hi group,

Im trying to apply a new timeperiod for a several specific monitors, for that, ive made a timeperiod entry with a new template, a new define service with my own template and when i try to apply the changes, nothing happens ... :S:

    monitor::plugin { 'mysql_health_slave_sql_running':
      plugin       => 'check_mysql_health',
      options_hash => { use => 'replication-service' },
      tool         => ['puppi', 'nagios']
    }

I thought that it would be applied, like a monitor::plugin class said:

 nagios::service { $safe_name: 
   ensure => $ensure,
   options_hash => $options_hash, 
   template => $real_template, 
   check_command => $check_command, 
}

But when it instance the nagios::service class, notthing happend because i think the parameter "options_hash" doesnt use anywhere... ?¿ Maybe is something missing on class, i thought it would be applied on the template but it doesnt.

define service { 
  host_name <%= @host_name %> 
  service_description <%= @real_service_description %> 
  check_command <%= @real_check_command %> 
  use <%= @use %> 
} 

[Sean Alderman]

So, it sounds like the "replication-service" in your hash is a Nagios Service Template, not a puppet managed ERB template.  Is that correct?  Then you are attempting to change the Nagios Service parent from 'generic-service' to 'repllication-service' and that replication service has the desired time period defined.  Am I correct?

First, the nagios::service's service.erb is not looking for @use to be inside the @options_hash.  Secondly, it looks as though monitor::plugin does not override nagios::service's use param what-so-ever.

If I may offer a suggestion...  Configure the time periods as you desire, but instead of setting them up for a service through a Nagios Obect Template, instead create your own service.erb template to pass into monitor::plugin that utilizes the new time period.  I have templates that look like so:

# Load Average

define service {
    host_name           <%= @host_name %>

    service_description Load_Average
    check_command       check_nrpe!check_load!noarg
    use                 <%= @use %>
    servicegroups       load_average
    contact_groups      <%= @owner_name %>
<% if ( @environment =~ /development|test|default/i ) then -%>
    notification_interval 60
    notification_period   workhours
<% else -%>
    notification_interval 15
    notification_period   24x7
<% end -%>

}

This one lives in my base services template, but the idea can be moved into custom service.erb templates.  You would simply specify the new ERB template when you call monitor::plugin.

Please forgive me if I have misunderstood your aim here.  I hope this helps!

[Fran Rodríguez]

Hi Sean,

Thanks for the answer, you understand perfecly what i want to do, maybe my explications wasnt quite well... ;). About what you suggest, maybe it works, i havent tried yet, im going to use my own template passsing on monitor::plugin and see what happen. 

Cheers

--
You received this message because you are subscribed to a topic in the Google Groups "Example42 Puppet Modules" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/example42-puppet-modules/mL4DeVFxCeI/unsubscribe.
To unsubscribe from this group and all its topics, send an email to example42-puppet-m...@googlegroups.com.
To post to this group, send email to example42-pu...@googlegroups.com.
Visit this group at http://groups.google.com/group/example42-puppet-modules.
For more options, visit https://groups.google.com/d/optout.

--

Fran Rodríguez
escala NetLabel
http://escalared.com

[Fran Rodríguez]

Hi agains,

I tried what Sean said, and it works like he said, but i dont like too much the solution, indeed ive done my own template for service based on nagios/template/service.erb:

define service {
<%if @options_hash['host_name'] -%>
    host_name           <%= @options_hash['host_name'] %>
<% else -%>
    host_name           <%= @host_name %>
<% end -%>
<%if @options_hash['real_service_description'] -%>
    service_description <%= @options_hash['real_service_description'] %>
<% else -%>
    service_description <%= @real_service_description %>
<% end -%>
<%if @options_hash['real_check_command'] -%>
    check_command       <%= @options_hash['real_check_command'] %>
<% else -%>
    check_command       <%= @real_check_command %>
<% end -%>
<%if @options_hash['use'] -%>
    use                 <%= @options_hash['use'] %>
<% else -%>
    use                 <%= @use %>
<% end -%>
}

This is more general, and i would like to know what @alessandro thinks about it, because i would like to do a pull request.

Cheers

[Sean Alderman]

What part of it do you not like, if I may ask?

Do you have cases where you override the hostname and other standard data for the monitor?  Would something simpler like the following work?

From the manifest:

monitor::plugin { 'mysql_health_slave_sql_running':
  plugin       => 'check_mysql_health',
  options_hash => { use => 'replication-service' },
  tool         => ['puppi', 'nagios']

  template     => 'module/custom_service.erb',
}

And your custom_service.erb would look like:

define service {
  host_name <%= @host_name %>
  service_description <%= @real_service_description %>  
  check_command <%= @real_check_command %>

  use <%= @options_hash['use'] %>
}

I am not understanding why the template needs all those standard parameters from the options hash.  Its worth noting that the host who creates this monitor::plugin could create an orphan service object in the nagios config, which would make nagios fail to start.  Host A exports nagios resources like host, baseservices, and module driven services, then Host A exports this custom service plugin with a different hostname.  Host B runs Nagios, and collects those resources, creates the configs and the nagios service is notified, but fails to restart because there is no host object to be the parent of the custom service plugin.

[Fran Rodríguez]

Hi Sean,

You are right, maybe ive gone too far, you wouldnt need to overwrite the host_name in any situation either check_command as service_description. And now as i can see after understood how it works options_hash, the best way to use it, its with custom template which maintain simple nagios class.

Sean, thanks for the talk... ;)

Cheers

--
You received this message because you are subscribed to a topic in the Google Groups "Example42 Puppet Modules" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/example42-puppet-modules/mL4DeVFxCeI/unsubscribe.
To unsubscribe from this group and all its topics, send an email to example42-puppet-m...@googlegroups.com.
To post to this group, send email to example42-pu...@googlegroups.com.
Visit this group at http://groups.google.com/group/example42-puppet-modules.
For more options, visit https://groups.google.com/d/optout.

[Alessandro Franceschi]

Just would like to add my 2 cents to the discussion.

I'm not currently managing any Puppet setup with the current icinga and nagios example42 modules.

I found myself using icinga2 and I consider it much more Puppet friendly, in my setups I do this:
- Each node exports only a nagios host file, where I place as extra vars the role and env of the node

- Each node has nrpe configured with the exact parameters needed for it (widely configurable for each node) , this is needed because Icinga2 doesn't like to pass params to nrpe

- On the icinga2 server I collect the hosts file resources  and I configure the checks based on the role of the nodes.

The big advantage is that all the services checks are summarized and they don't need exported resources.

I'll eventully publish something about such an apporach

Best regards,

al

To unsubscribe from this group and all its topics, send an email to example42-puppet-modules+unsub...@googlegroups.com.
To post to this group, send email to example42-puppet-modules@googlegroups.com.

Visit this group at http://groups.google.com/group/example42-puppet-modules.
For more options, visit https://groups.google.com/d/optout.