NRPE/NSCA replacement thoughts?

[Kevin Keane]

> -----Original Message-----
> From: Morris, Patrick [mailto:patrick.morris at hp.com]
> Sent: Thursday, February 18, 2010 8:23 PM
> To: Michael Medin
> Cc: nagios-users
> Subject: Re: [Nagios-users] NRPE/NSCA replacement thoughts?
> 
> Michael Medin wrote:
> > Hello
> >
> > Since I am pondering a replacement for the NSCA and NRPE protocol I
> > thought I would get some thoughts from the community?
> > So this is pretty much an "open floor" kind of thing to get some sense
> > of what people actually need and would want (if anything at all).

I have actually written a minimal "replacement" to resolve a shortcoming in my own situation. Actually, it is the standard NSCA protocol wrapped in SSL or (optionally) SSH

> > But to get some general idea I'll give you a few questions to start
> it off:
> >
> > 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?

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.

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

> > Would webservices be the best way?

Separate the structure of the protocol from the underlying transport mechanism. In my mind, a lack of that separation is actually the greatest weakness of the current protocol.

Web services are an excellent choice of transport for many situations, and quite likely will be the the dominant one for the foreseeable future. Another potential transport is SSH, yet another could be RFC 1149/RFC 2549 avian carriers or whatever else somebody comes up with.

Some advantages of Web services:

Advantages:
- built-in firewall compatibility
- built-in encryption and authentication (via SSL)

Drawbacks:
- needs to be integrated with Web servers, potentially adding to complexity and performance issues.

> > Should the protocol be extensible?

Yes, within reason. One of the beauties of Nagios is in its simplicity, so if you add too much extensibility you might actually lose more than you gain.

But on the other hand, some extensibility is important - otherwise, people will come up with their own extensions that don't really fit with the model. For instance, today's performance data is such an enhancement.

> > What plattforms would it need to support?

ASCII and Unicode. Other than that, is must be platform neutral, or you lose too much.

> > Whats polling scheme(s): active, passive, active/passive, proxy, etc?

Both have its place. Most people seem to love active polling, but firewalls may sometimes require passive polling.

> > 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 thing I would definitely like to see in this context is automatically adding services to Nagios when passive check results arrive. Keeping the list of services in sync between master and slave servers is one of the things that makes such a setup complicated.

> > What kind of security mechanisms do you need (host, password,
> > encryption, certificates, etc)?

That should be left to the underlying transport. Why reinvent the wheel and have to keep chasing security holes if there are already plenty of good solutions available?

> > Client side "checks" or client side data gathering with server side checks?
> > (ie. check_nrpe get "ok" back, another option would be to get the
> > "value" and let the server decide if it is good or bad.)

Definitely client-side checks. Otherwise, you'd be looking at effectively re-inventing RPC. What if the "value" being checked is some huge binary blob, or the result of multiple interdependent system calls?

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


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