Hi, well, I did not had enough time at the weekend to write a base-class for Python-bases checks, but I has some time to think about the design.
Here are my thoughts, comments are welcome.
* checks have to return a 4-tuple:
- return code (exit status): integer
- message (status output): unicode-string, one line only
- perf-data: dict (see below)
- long status message: either a list/tuple of unicode-strings (one
line each) or a single unicode-string with several lines
separated by \n
Missing elements have to be None.
Rational: Nagios send strings which need to be build by the sender
and parsed be the receiver. Since shinken components talk to each
other using Pyro, Python objects can be passed around and some
overhead can be saved.
Defining a single format of passing results simplifies handling
and saves some cycle.
Question: should message and long status message be split al all? Or
should it be one element, a list, where the first line is the
message and the remaining lines are the long status message?
* When running the check, these return values are not checked by the
poller for having the correct format. This forces developers to but
more care into correct code and saves some cycle.
The base-class will have a "test(..)" method, which checks the
result types. So developers are not left alone when testing the
plugin carefully.
Downside: cryptic error messages at the receiver, far away from the
origin of the error.
* The base-class will have a method "as_string()" to convert the
result tuple into a Nagios-compatible string. Thus each check can be
used for Nagios. This string will be printed by the "test()" method,
too.
* The performance data will be a dict. Keys are strings, values are
either integer, float or string (percent), or a list/tuple thereof.
Question: Do we need float results?
Rational for using a dict instead of a n-tuple: a) Accessing values
is easier for both generating and analysing b) n-tuples of
2-tuples (key, value) are a bit harder to understand for
developers c)
Rational for not using string as values: Vales have to be parsed be
the receiver anyway. So save one there-and-back conversion.
Rational for not using strings for lists of values: dito.
* Errors (exceptions) within the check are caught at the place, where
the check is run. There is no need for the check to implement
exception handling.
Rational: This simplifies development of checks and unifies how
exceptional messages are passed onto the receiver. This even
offers the option to pass the whole exception onto the receiver,
if we decide to do so some when.
* Classes for checks will be instantiates when the config is read. This
includes setting up the option parser, parsing the command string
into pieces only once (macros will be expanded on each call, though).
Drawback: if the code of the check needs to be changed, the
Open questions:
* Should we use optparse or argparse? optparse is standard since Python
2.3 (AFAIR). argparse is standard staring with Python 2.7, but is
available for 2.4, too (AFAIK). argparse has a much cleaner interface.
--
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/blog/gleich-zwei-artikel-im-ix-special-sicher-im-netz
Monatliche Kolumne: http://www.cissp-gefluester.de/
Goebel Consult mit Mitglied bei http://www.7-it.de
smime.p7s
Description: S/MIME Cryptographic Signature
------------------------------------------------------------------------------ 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
