The reason of commands.cfg.

Furnish, Trever G TGFurnish at herffjones.com
Thu Oct 8 17:30:17 CEST 2009



> -----Original Message-----
> From: Marc Powell [mailto:marc at ena.com]
> Sent: Wednesday, October 07, 2009 4:13 PM
> To: nagios List
> Subject: Re: [Nagios-users] The reason of commands.cfg.
> 
> 
> On Oct 7, 2009, at 12:35 PM, Albert Shih wrote:
> 
> > Le 05/10/2009 à 13:34:30-0400, Noel Platzke a écrit
> > Thanks for you answer.
> >
> >
> >> Say we have a bunch of servers that need multiple checks that do an
> >> HTTP GET on
> >> different URIs and look for a specific string in the response.
> >> Isn't it easier
> >> to maintain a single command that takes a few arguments than having
> >> to
> >> constantly define a new command that does basically the same thing
> >> for each
> >> service check? And if down the road someday HTTP becomes HTTPS you
> >> only need to
> >> edit one configuration.
> >
> > You mean they are no other reason like perfomance (register like
> > object) ?
> > or security reason ?
> 
> 
> While there may be arguments for both, the flexibility available just
> due to the implementation of command definitions is more than enough
> reason for their existence. Nagios 1.x and Netsaint had support for
> specifying raw command lines in the host and service definitions but
> it was dropped after those versions.
> 
> --
> Marc

And besides, there's nothing stopping you from doing what you want.  I regularly set up generic commands for each plugin.  Then I default to using those generics, and I don't make more specific commands unless I notice a bunch of repetition in my usage.

For example, here's a generic check_http:

define command{
        command_name    generic_check_http
        command_line    /usr/lib/nagios/plugins/check_http $ARG1$ $ARG2$ $ARG3$ $ARG4$ $ARG5$ $ARG6$ $ARG7$ $ARG8$ $ARG9$
        }


Then just pretend generic_check_http is actually check_http, and use it as you would on the command-line.

I do kind of wish a generic command for each plugin would simply be included in the default Nagios config files.

Even better would be if there were a /usr/lib/Nagios/plugins/plugin_commands.d/ directory, and each plugin could drop its own set of default commands in there, so that the whole directory could just be included in nagios.cfg.  Each plugin could define a command with its own name:

cat /usr/lib/Nagios/plugins/plugin_commands.d/check_http.cfg
define command{
        command_name    check_http
        command_line    /usr/lib/nagios/plugins/check_http $ARG1$ $ARG2$ $ARG3$ $ARG4$ $ARG5$ $ARG6$ $ARG7$ $ARG8$ $ARG9$
        }



------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
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





More information about the Users mailing list