Re: [Nagios-devel] New project announce: NSCA2
Nagios network monitoring software is enterprise server monitoring
Brought to you by:
egalstad,
sawolf-nagios
From: Daniel E. F. <da...@da...> - 2009-08-26 14:32:01
|
What you say makes sense, however, I would consider the following thought: NSCA is currently on protocol revision 2. The packet itself indicates which protocol revision it is in, if I remember correctly. Why not simply create a revision 3, and patch send_nsca and nsca, including their corresponding nsca.cfg/send_nsca.cfg files to be capable of utilizing packet structure revision 3? On the NSCA side, you can make it compatible with both versions 2 and 3, and obviously on the send_nsca side you could do the same, just selecting which version to use in the send_nsca.cfg file. In this way, you would be making a lasting contribution to the existing code base (which, by the way is stable and is used all over the place), rather than creating a one-off in perl, which has some disadvantages when dealing with large configurations. I am not trying to dissuade you from your course, but rather make a case for another possible direction. Consider a setup that has 500 hosts all using passive service checks with NSCA. Would a Perl NSCA be capable of handling the load? By the way, I am not uninformed on this topic. In the past 2 years I have written an NSCA replacement (NSCAFE) [http://www.monitoringexchange.org/cgi-bin/page.cgi?g=Detailed%2F2349.html;d=1 ] in Java, and another extremely high-performance one in C as an event broker module (BRONX) [http://archive.groundworkopensource.com/groundwork-opensource/trunk/bronx/ ] Daniel. On Aug 25, 2009, at 3:36 PM, Jose Luis Martinez wrote: > D. Emmanuel Feinsmith escribió: >> Out of curiosity, based on the changes in your description, why not >> submit these changes as a patch? > > - Perl is my "native" language, and I can program faster than in C, > with less errors, and less restrictions. > > - The base class for the server is Net::Server that provides for > "free": > - configuration file management > - different process models: Forked, Preforked, Single, etc (that > right now nsca would have to handle by itself) > - Handling of SIGHUP to reload config > - just see: > http://search.cpan.org/~rhandom/Net-Server-0.97/lib/Net/Server.pod > - I hope Perl will let us prototype more functionalities with less > pain > > note: All of this is not because of Perl itself. I'm sure Python and > other languages can handle all of this as easily (I don't want to > start > a "best language" flame). > > - if you extend nsca, you have to be backwards compatible, and carry > some design decisions that would probably be hard to avoid or make the > code nasty: > - when an nsca client connects, the server sends an initial packet, > with the timestamp the client will send back and the IV to initialize > encription. This forces one round trip of communication, because the > client has to wait for the server. NSCA2 aviods this by: > - using the timestamp from the client > - initializing the IV at the client, and sending the result with > the IV to the server. > - the client just speaks to the server and closes the connection > - I consider that reengineering from time to time is not all that > bad :) > > Finally, I understand some of these features have been long awaited, > but > no one has developed them (the last changelog entries for NSCA are > from > 03/jul/2007, and the last feature is from 06/Apr/2006), so I've had to > scratch my own itch the way I deemed better, and thought that making > it > open to the community would be more productive ;) > > Cheers, > > Jose Luis Martinez > jlm...@ca... > > ------------------------------------------------------------------------------ > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 > 30-Day > trial. Simplify your report design, integration and deployment - and > focus on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > _______________________________________________ > Nagios-devel mailing list > Nag...@li... > https://lists.sourceforge.net/lists/listinfo/nagios-devel |