NRPE/NSCA replacement thoughts?

[Michael Medin]

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 :)
> 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.
>>> 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?
Nagios has survived on its simplicity but lately has tried to "grow" 
into something more advanced.
>
>>> 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.
>    
>
>>> 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".
>>> 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.
>
>    
 From what I have gathered this is pretty time and CPU consuming so 
another option would be to split off the data "outside" Nagios.

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