NRPE/NSCA replacement thoughts?

Michael Medin michael at medin.name
Thu Feb 18 19:25:33 CET 2010


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

Is a new protocol a good idea?

Should a new protocol be "flat text based" or structured?

Would webservices be the best way?

Should the protocol be extensible?

What features would a new protocol need to support?
  - message, performance data, configuration, multiple queries, control 
logic transfer, inventory, etc.

What plattforms would it need to support?

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

Master/slave scenarios?
In both NRPE and NSCA "nagios" is the master should the client be 
allowed to act as master?

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

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

Multiple streams?
ie  send to both Nagios and potentially other collectors (like rrd)

<<Feel free to add more thoughts and ideas here>>

// Michael Medin


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





More information about the Users mailing list