Nagios external commands (2)

Andreas Ericsson ae at op5.se
Tue Sep 25 09:17:48 CEST 2007


Tobias Mucke wrote:
> Hi Andreas,
> 
> thanks for your reply.
> 
> What I want to achieve is to write a program which is able to write
> External Commands into the Nagios External Command Interface. Is there
> such a program yet? I did not found one.
> But I don't want to hardcode all the External Commands and the needed
> options, escpecially if there are new External Commands from time to
> time or existing ones are changing, I don't want to change my code.
> So my first step is to describe all external commands in a XML
> structure. Second step will be to write code using this XML file to
> understand which commands are possible and which options are needed,
> so it can check the input from the user and write the correct command
> into the pipe.
> 

Well, there are easier ways to do that than putting all of it in XML,
although I applaud any effort that there's even the slightest chance
that anyone will use.

> Working with the External Commands documentation at nagios.org I got
> the impression that it is written manually and stored in some kind of
> content management system.

True. This must be so, or the docs might not match the reality in the
code.

> With a XML file describing the Nagios
> External Command Interface you could generate the documentation e.g.
> by XSLT.
> Why should you do that? Because it would be possible to send patches
> for the documentation in a program understandable diff format.
> 

But it already is. The program creating such program understandable diffs
is called (surprise, surprise) "diff". The program that understands those
diffs is called "patch". ;-)

Seriously though, like I said above, the docs need to be maintained along
with the code, or the doc-to-code relation might get broken for a certain
revision of either.

> Future use, e.g. for XML-RPC or some other sort of interface:
> 
> Thinking of a distributed monitoring environment you need a central
> console for it. We have such a setup here and it works fine. We are
> using the webinterface of the central monitoring system right now.
> This system also does notifications and escalations.
> Actually we are going to work on a concept for an even more
> distributed environment. Right now all distributed monitoring systems
> are located at one datacenter location. But we want to roll out Nagios
> to other datacenters at remote locations too. The idea is to give the
> remote datacenter as much as autonomy as possible e.g. keep
> notifications local at each location.

Sounds like a good idea. I'd use a NEB to propagate the commands if I
were you, or a separate program altogether.

> Nethertheless we want just one central console to control the Nagios
> infrastructure, for example to enable / disable notifications. So you
> have to control Nagios by an interface you can send commands to from a
> central system. These commands should be checked if they are correct
> before they are passed into the pipe.
> 

Why? They must still be checked for correctness inside Nagios. Adding
another point of failure might mean you get bitrot in the xml-doc, so
your commands (which nagios would understand perfectly) don't go through.
Otoh, if you update the xml-doc prematurely, you would get "OK" from the
XML validation thingie and then Nagios wouldn't grok it anyways.

> Other projects, e.g. Xen, are solving this by a XML-RPC interface
> which is easy to implement.
> Actually I don't know the NEB and its possibilities but I thought the
> PIPE will vanish into thin air in Nagios 3.0. So this is not a
> bottleneck anymore.
> 

"pipe" is not an acronym, so no need to capitalise it.

The FIFO stays. It'll no longer be used for child processes to pass service
results to the grand-parent, but it'll still be used for external commands.

However, assuming your implementation doesn't touch the nagios core, it won't
be a problem since you can then convert the XML-command into a format that
nagios groks, after having stripped the XML overhead.

-- 
Andreas Ericsson                   andreas.ericsson at op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/




More information about the Developers mailing list