Hi,
Thanks for this thread, it seems interesting :)
On Mon, Jan 31, 2011 at 11:42 PM, Hartmut Goebel <h.goe...@goebel-consult.de
> wrote:
> Am 31.01.2011 23:20, schrieb Gerhard Lausser:
> > a single format for both python-based checks and traditional plugins
> > requires converting the output and exitcode of the latter. This probably
> > adds a lot more cycles.
> While you are right here at the moment, this may change over time.
>
> The current interface is simple but non performing. While the check
> builds a string, some backend tools needs to parse it again. If shinken
> get more mature, there may be more backend-tools being able to handle
> Python objects and gain performance.
>
I don't think we should parse/manage perf data. It's not Shinken core job.
Perfdata are here to be exported, by a broker module or a reactionner call
(event handler or module). So instead of adding job to the scheduler, let
keep the string as now, and let the cpu cycle be taken when it's very very
easy to scale, in the reactionners :)
(and it ask less code for us :p )
In a more general manner, let avoid the cycle discussion. Optimize too early
is not good. Optimization is for refactoring pass, not for conception one
because it can complexify the code a lot and the first goal is to have
something working, and in the most simple way possible. Then if it's not
quick enough, we can optimize. But optimize a working code is possible,
simplify a optimize one is not :)
>
> BTW: IMHO it does not matter if the check converts some intelligent data
> type into a string or shinken core does in the backend. Well,
> tranporting the string via network *may* be a bit faster.
> > In order to be usable with Nagios there must be something like
> > if __name__ == '__main__':
> > # runs as standalone python program
> > plugin = Class...
> > print plugin.output + '|' + plugin.perfdata
> > exit plugin.exitcode
> >
> > so the file can be "imported" and cached by a Shinken poller and executed
> by
> > a Nagios. (similar to ePN)
> I missed describing this. This is exactly, what the test()-Method is
> meant for.
>
Why a test? If we have a wrapper script that import/call, we just need a
standard Execute function?
> >> * The performance data will be a dict. Keys are strings, values are
> >> either integer, float or string (percent), or a list/tuple thereof.
> > What about min/max/thresholds?
> I thought, simple lists of values are enough. Am I missing something?
>
If we do not parse perfdata, it's solved :)
One thing is for the format. I think it should be like the broker modules.
The main thing is how we call them. I think a good way is :
* load the "module" in the poller object. The module got a module_type, like
"nrpe"
* for the command call, we can "call" this module. So it will be a standard
Check with just an additionnal property.
define command {
command_name SpeedNrpe
command_line check_nrpe -h $HOSTADRESS$ -u -t 9 -c $ARG1$
module nrpe
}
So in the Arbiter we do not even need to know about the 'nrpe' code/module.
It's a code for the poller, not for the arbiter nor the scheduler (that's it
that will create the Check objects).
When it reaches the poller, this one already got the modules (nrpe,
othersupermodule, etc), and the main poller process read the module (can be
None, so it's the standard fork that take it). I don't know if we should
make worker by module, or each worker can load all modules. The current fork
workers work in asynchronous mode. They get all jobs, they launch them, and
then they loop on the pool calls of all the processes they launched. I don't
know if it will be as easy for a connect call for example.
So dedicated workers should be better here (I don't want a fork waiting a
connect). For a AS400 module for example, it can keep the connexion with the
server (mainframe sorry :) ) because this part is very long during it's
living time. It will be far more hard for a current worker with different
modules to do so.
Then for the Check, it will call the module and "Execute" it with the Check.
This module then know what to do with the command_line or maybe others
parameters. Of course a helper function in the Module code from Grégory will
help. I think adding another dependency for this is not so good, at least
for the common code. If the module want to parse the parameters with its own
module, it can (and so the module will need an additional module, but it's a
module it's not a problem).
The other point in using the Check object is that the scheduler do not need
to know how to parse it if it's not the good module. It already have all it
need for it (exit code, output, long output and timeout info). The interface
is already managed.
Jean
>
> --
> Schönen Gruß - Regards
> Hartmut Goebel
> Dipl.-Informatiker (univ.), CISSP, CSSLP
>
> Goebel Consult
> Spezialist für IT-Sicherheit in komplexen Umgebungen
> http://www.goebel-consult.de
>
> Monatliche Kolumne: http://www.cissp-gefluester.de/
> Goebel Consult mit Mitglied bei http://www.7-it.de
>
>
>
>
> ------------------------------------------------------------------------------
> Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
> Finally, a world-class log management solution at an even better
> price-free!
> Download using promo code Free_Logger_4_Dev2Dev. Offer expires
> February 28th, so secure your free ArcSight Logger TODAY!
> http://p.sf.net/sfu/arcsight-sfd2d
> _______________________________________________
> Shinken-devel mailing list
> Shinken-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/shinken-devel
>
>
------------------------------------------------------------------------------
Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
Finally, a world-class log management solution at an even better price-free!
Download using promo code Free_Logger_4_Dev2Dev. Offer expires
February 28th, so secure your free ArcSight Logger TODAY!
http://p.sf.net/sfu/arcsight-sfd2d
_______________________________________________
Shinken-devel mailing list
Shinken-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shinken-devel
