Native plugins (was Re: [Nagiosplug-devel] Java Plugins)

[Jos Visser]

I beg to differ on a number of your arguments. However, since it was
only a brainwave on my part and also because I am not actually planning 
to write the code involved we can easily leave it at that...

++Jos.es

On Fri, Nov 19, 2004 at 10:03:28AM +0100 it came to pass that Andreas Ericsson wrote:
> Jos Visser wrote:
> >With respect to the embedded Perl and embedded Java stuff: Wouldn't is
> >be a good idea to extend Nagios with a generic "native plugin" feature
> >that would take the form of a shared library conforming to a defined
> >interface. Through some extensions to the command language the native
> >plugin could be loaded and integrate itself. Then through extension
> >keywords we could get the plugin to do stuff (very much like the Apache
> >plugin module interface). The entire discussion of embedded Perl,
> >embedded Java, embedded Lisp or whatever could then be short circuited
> >to native plugin development...
> >
> 
> The idea is a bit flawed for a number of reasons.
> 1. Plugins are highly flexible. They can usually perform many checks 
> with a just a little argument tweaking (check_http springs to mind).
> 
> 2. Plugin development is highly flexible. A plugin can be written in any 
> language. A shared library would only get C plugins (and not until 
> they're incorporated), so that still leaves a fair number out.
> 
> 3. Plugins already written in C impose a very minor additional load to 
> the system, while retaining the flexibility and "debugability" of a 
> separate program (check_http --help springs once again to mind).
> 
> 4. Internal code to do checks would seriously increase Nagios' code 
> volume and make it infinitely less stable.
> 
> 5. Some plugins needs to use additional environmental variables or run 
> as a different user (plugins that need raw sockets, for instance). While 
> this can be solved, it requires non-trivial code (temporary privilege 
> elevation within the core) and can possibly present a security risk.
> 
> 
> >++Jos.es
> >
> >On Fri, Nov 19, 2004 at 09:10:01AM +0100 it came to pass that Andreas 
> >Ericsson wrote:
> >
> >>Jos Visser wrote:
> >>
> >>>Plugins in Java are possible, and so is calling Java from Perl. The
> >>>performance will probably suck because it takes a long time to
> >>>initialize the entire Java runtime environment (JVM, libraries)
> >>>
> >>
> >>Indeed. Java is a hog, which should be loaded once and once only on 
> >>every machine where it is to run.
> >>
> >>
> >>>It would probably be better to:
> >>>
> >>>- Run the check as a daemon and:
> >>>- control that daemon from, or
> >>>- use the whats-its-name protocol to communicate status directly to
> >>>  Nagios
> >>>
> >>
> >>I'd say the best you can do is have a small webapplet running on the 
> >>weblogic server which you can fetch some info from and parse in a perl, 
> >>C or shell-script. That way you get the info on-demand, but keep from 
> >>loading java each time the check is run.
> >>
> >>
> >>>If you are really brave you could extend Nagios with native Java plug-in
> >>>support. This would entail linking libjvm.sl into Nagios and hacking
> >>>some code to call Java methods directly as check_command's... This would
> >>>also mean that you don't need to build up the JVM every time...
> >>>
> >>
> >>I daresay this hack would never make it into the official nagios core 
> >>though, especially considering the embedded perl support which nowadays 
> >>require completely bewildered solutions to work properly.
> >>
> >>
> >>>++Jos.es
> >>>
> >>>On Thu, Nov 18, 2004 at 02:28:16PM -0700 it came to pass that David 
> >>>Robinson wrote:
> >>>
> >>>
> >>>>I have written Nagios Perl plugins that invoke the weblogic.Admin java 
> >>>>class
> >>>>to monitor runtime information of my WebLogic Servers.  The 
> >>>>weblogic.Admin
> >>>>class executes JMX requests to a given WebLogic Server process.  It 
> >>>>looks
> >>>>like:
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>Nagios Process --> Perl Process --> Java Process -->  JMX call across 
> >>>>the
> >>>>network  --> Remote WebLogic Server Process
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>These plugins do not seem to perform very well.  Does anyone have any
> >>>>suggestions on improving the performance of plugins for monitoring 
> >>>>WebLogic
> >>>>Server?  
> >>>>
> >>>>
> >>>>
> >>>>I also tried writing a plugin directly in Java, but I'm not sure if 
> >>>>this is
> >>>>supported.  Nagios did not receive any output from my Java plugins even
> >>>>though I was exiting with the proper error codes.  Has anyone created
> >>>>plugins in Java?
> >>>>
> >>>>
> >>>>
> >>>>Thanks for your assistance,
> >>>>
> >>>>Dave
> >>>>
> >>>
> >>>
> >>-- 
> >>Andreas Ericsson                   andreas.ericsson at op5.se
> >>OP5 AB                             www.op5.se
> >>Lead Developer
> >>
> >>
> >>-------------------------------------------------------
> >>This SF.Net email is sponsored by: InterSystems CACHE
> >>FREE OODBMS DOWNLOAD - A multidimensional database that combines
> >>robust object and relational technologies, making it a perfect match
> >>for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8
> >>_______________________________________________
> >>Nagiosplug-devel mailing list
> >>Nagiosplug-devel at lists.sourceforge.net
> >>https://lists.sourceforge.net/lists/listinfo/nagiosplug-devel
> >>::: Please include plugins version (-v) and OS when reporting any issue. 
> >>::: Messages without supporting info will risk being sent to /dev/null
> >
> >
> 
> -- 
> Andreas Ericsson                   andreas.ericsson at op5.se
> OP5 AB                             www.op5.se
> Lead Developer
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: InterSystems CACHE
> FREE OODBMS DOWNLOAD - A multidimensional database that combines
> robust object and relational technologies, making it a perfect match
> for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8
> _______________________________________________
> Nagiosplug-devel mailing list
> Nagiosplug-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/nagiosplug-devel
> ::: Please include plugins version (-v) and OS when reporting any issue. 
> ::: Messages without supporting info will risk being sent to /dev/null

-- 
What's worth reacting to, is worth overreacting to...