> 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 [email protected]
OP5 AB www.op5.se
Tel: +46 8-230225
...[email truncated]...
This post was automatically imported from historical nagios-devel mailing list archives
Original poster: [email protected]