Native plugins (was Re: [Nagiosplug-devel] Java Plugins)
Jos Visser
josv at osp.nl
Fri Nov 19 04:37:04 CET 2004
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...
More information about the Devel
mailing list