NRPE/NSCA replacement thoughts?

[Kevin Keane]

> -----Original Message-----
> From: Michael Medin [mailto:michael at medin.name]
> 
> On 2010-02-19 07:25, Kevin Keane wrote:
> >> Is a new protocol a good idea?
> >>
> > Maybe the answer to that question should come at the end instead of
> the beginning of the process?
> >
> Well, if everyone thinks this is a doomed sinking ship there is no
> point
> to venture forth so for me this is the most important question actually
> :)

OK, I see your point. Still, I think without understanding what the new protocol would improve, it's very hard to say even whether it's a doomed ship. The main concern, the main thing that could doom the ship, is compatibility. Many great ideas die because of it. You know the old joke how it was possible to create the world in seven days? He didn't have to worry about an installed base... And it's why we still have Fax machines.

BTW, I haven't followed icinga lately - maybe these guys have some things cooking on that end, too?

> > Generally, I believe that extending an existing protocol is usually a
> better idea than wholesale replacement, but sometimes one does have to
> clear-cut some junk.
> >
> The "protocol" part of NRPEand NSCA has far far to many flaws to merit
> extending them.

I'm not sure about that. It seems to work reasonably well for what it is supposed to do.

I am only aware of two issues with it: insufficient separation of protocol and transport, and an awkward mechanism for performance data. A third issue is that it's not documented very well, or at least not easy to find.

> >>> Should a new protocol be "flat text based" or structured?
> >>>
> > What is the design goal? I would advocate structured because of the
> flexibility, but if it means more bandwidth or using more processing
> power to parse the protocol, it may not be a great idea?
> >
> Thats exactly the question: whats more interesting, speed, simplicity
> or flexibility?

Interoperability is yet another one? We don't really want Yet Another Protocol unless there is some very clear value in it.

Quite honestly, I don't think that speed and simplicity are mutually exclusive with flexibility.

> Nagios has survived on its simplicity but lately has tried to "grow"
> into something more advanced.

Can you elaborate what you are thinking of, and how the NRPE/NSCA protocol is limiting it in that respect?

> >>> Master/slave scenarios?
> >>> In both NRPE and NSCA "nagios" is the master should the client be
> >>> allowed to act as master?
> >>>
> > Define "master" and "slave" in this context! If you are talking about
> the current model of multiple Nagios servers, it seems to me that this
> is more of a redesign of Nagios, rather than a protocol issue.
> >
> One pretty interesting idea I saw at the Nordic Nagios Meet last spring
> was a client (I don't recall the name now) that allowed you to define
> the checks and such on the clienht. This was then uploaded and
> incorporated into Nagios. This means nagios is no longer the master for
> configuration data instead the clients have become "masters".

My client does some of the same thing. My guess is that quite a few people have similar homegrown solutions already. You can probably find many ideas at the Monitoringexchange.org site.

What that means is a couple things: first of all, look what people are doing in terms of homegrown solutions. That's probably where the most interest is. If your protocol solves the same problem that 1000 people had to spend days scripting out before, you are likely to have a good starting point for a feature set.

> >>> Multiple streams?
> >>> ie  send to both Nagios and potentially other collectors (like rrd)
> >>>
> > No. Keep it simple, not a protocol to solve all the problems in the
> world. Nagios itself can forward to other collectors.
> >
> >
>  From what I have gathered this is pretty time and CPU consuming so
> another option would be to split off the data "outside" Nagios.

I think to do this cleanly, you would have to rearchitect Nagios itself. That might not be a bad idea, but probably a much bigger scope than you had in mind. It's not something that could be solved at the protocol level.

The issue I'm thinking of is that the "traditional" Nagios checks would bypass this mechanism, since you would "only" replace NRPE/NSCA. Similarly, NRPE/NSCA wouldn't go away for many years to come due to the large installed base.

So the best way to solve this would probably be to completely remove the command logic from the Nagios "kernel" and extract it into a separate component. The kernel would just handle the status processing. 


------------------------------------------------------------------------------
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