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

[Jos Visser]

Indeed; a servlet/EJB or whatever in WebLogic that can be controlled
remotely by a Perl script would be very much the appropriate way forward
right now.

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

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

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