Multiple instances of same service for a host

[Martin Melin]

On Thu, Mar 18, 2010 at 9:16 PM, mlrtime3 <mlrtime3 at gmail.com> wrote:

> I've been using Nagios for awhile (since netsaint).  I'm not sure if
> this is possible, so I'm asking here.  I hope this makes sense.
>
> I currently have a service that I run for every host in a hostgroup. The
> service is executed by pulling a macro from the host definition
> $_HOSTPARAM1$. This works well for instances where there is a 1 to 1
> relationship between the host and the service. Meaning I'm just calling
> one instance of the service for each host.
>
> What I need to do is have multiple instances of this same service for
> some of the hosts depending on the macros on the host.
>
> For example
>
> HOST1 - SERVICE ($PARAM1$)
>
> HOST2 - SERVICE ($PARAM1$)
>      - SERVICE ($PARAM2$)
>
> HOST3 - SERVICE ($PARAM1$)
>      - SERVICE ($PARAM2$)
>      - SERVICE ($PARAM3$)
>
>
> I know I can modify my service to take in multiple parameters, but then
> the whole service would be down if any of the parameters caused the
> service instance to be down. I also can't create multiple service copies
> because the number of "PARAMS" is dynamic per host.
>
> Any ideas on how to do something like this?
>

An ugly hack would be to have multiple sub-templates, one for each number of
services a host can have (assuming the max is a reasonable number).

However, I do not feel that the proper place for this logic is to somehow
hack it into Nagios' definitions. Nagios does not support dynamic
service/host definitions, other than modifying its configuration files and
sending a SIGHUP, and changing that behavior causes all kinds of interesting
issues that I'm not sure you want a program like Nagios handling.

A simple script should be enough to read your host definitions and generate
the appropiate number of service definitions for each host. I know people
who have their custom server management scripts output a Nagios config tree
every N minutes, then send a SIGHUP to Nagios to have it re-read the
configuration files. My opinion is that this would be the best way forward
for you, too.


>
> Thanks for any suggestions.
>
>
> ------------------------------------------------------------------------------
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Nagios-users mailing list
> Nagios-users at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/nagios-users
> ::: Please include Nagios version, plugin version (-v) and OS when
> reporting any issue.
> ::: Messages without supporting info will risk being sent to /dev/null
>



-- 
Martin Melin

May your delusions be benign and your compulsions have utility
____________________________
op5 AB
http://www.op5.com

http://www.op5.org/
http://www.op5.com/op5/products/network-monitor/nagios/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.monitoring-lists.org/archive/users/attachments/20100319/ac0e6cc0/attachment.html>
-------------- next part --------------
------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
-------------- next part --------------
_______________________________________________
Nagios-users mailing list
Nagios-users at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nagios-users
::: Please include Nagios version, plugin version (-v) and OS when reporting any issue. 
::: Messages without supporting info will risk being sent to /dev/null