[checkmk-commits] Check_MK Git: check_mk: Cleaned up source tree

Module: check_mk Branch: master Commit: 8a2abb4e20ed874cfdd6a98e6568832f03b256c1 URL: http://git.mathias-kettner.de/git/?p=check_mk.git;a=commit;h=8a2abb4e20ed87… Author: Mathias Kettner <mk(a)mathias-kettner.de> Date: Tue Mar 22 08:25:30 2011 +0100 Cleaned up source tree --- README.writing_checks | 167 ------------------------------------------------- 1 files changed, 0 insertions(+), 167 deletions(-) diff --git a/README.writing_checks b/README.writing_checks deleted file mode 100644 index 7fd1df0..0000000 --- a/README.writing_checks +++ /dev/null @@ -1,167 +0,0 @@ -This file will help you to write *good* checks for Check_MK. - -Naming - -* Check file names should be named short and unique. They must consist - only of lower case characters, digits and underscores and begin - with a lower case character. - - Vendor specific checks must be prefixed with a vendor specific unique - abbreviation (which you think of). Example: fsc_ for Fujitsu Siemens Computers. - - Product specific checks must be prefixed with a product abbreviation, for - example "steelhead_status" for a Steelhead appliance of Riverbed. - -* SNMP based checks: if the check makes use of a standardized MIB which - is or might be implemented by more than one vendor, then the check should - not be named after the vendor but after the MIB. An example are the - hr_* checks. - -* The service description of different check types that essentially - do the same must be identical (e.g. if/if64/ifoperstatus). Reason: - this makes rules in main.mk simpler for the user! - - -Coding style - -* If the check is contributed by a third party (like you), you must - add your name and your email address. - -* Avoid long lines. In an optimal case your lines don't exceed 80 chars. - 100 chars. - -* Use four spaces for intending your code. Just don't use tab chars. - And if you really can't life without tabs set the tab width to 8 spaces. - -* For parts part of the official Check_MK the file header with the - copyright information must be present. This will be automatically - created if you call 'make headers' in the main source directory - -* TCP-Agent based checks *must* put an output example of the - agent in comments into the check file right after the header - and before the implementation. If the agent output can have - different formats or output style then put an example for each - kind of style the check supports (e.g.: the output of multipath -l - has changed its layout between SLES 10 and SLES 11). - - For SNMP based checks put examples if the kind of output is - in some respect remarkable. - - The example output is very helpful for understanding how the - check parser works. - -* Configuration variable for main.mk should be named after - the check, if they are only used by this check. This does - not hold for variables, that are used by several checks - (e.g. filesystem_levels is used by df, hr_fs, df_netapp, ...) - -* If a check does not use check parameter, then the inventory function - must return None as parameter and the check function must name - the parameter argument _no_params. - -* The name of the inventory and check function must be - prefixed with the name of the check type, for example - inventory_h3c_lanswitch_cpu for 'h3c_lanswitch' - -* Order of implementation: - - 1. fileheader with GPL - 2. example output from agent - 3. default settings of configuration variables - 4. helper functions and variable, if any needed - 5. inventory function - 6. check function - 7. check_info[] definition - 8. snmp_info[] definition - 9. snmp_scan_functions[] definition - -* Configuration variables for main.mk - -* Variable naming. Use lower case variable names where the keywords are splitted by _ signs. - -* Creating nagios state strings: There is a dictionary named 'nagios_state_names'. - You can use it to get nagios state string from nagios return codes. e.g.: - nagios_state_names[0] gives you 'OK'. - -SNMP Scan function: - -* Every SNMP check *must* have an SNMP scan function. That function - should as *minimal* as possible: It should only fire at those devices - that really can support the check. Reason: unneccessary SNMP walks - on devices not supporting that check must be avoied. - The scan function must on the other hand not be so strict that it - rules out devices where the check would work. If in conflict between - these two issues than rather make the scan function not too strict. - The scan function should avoid fetching non-standard-OIDs by any - means. It should rather try to use the basic SMIv2 OIDs as these will - already have been fetched and cached by the scan functions of other checks! - All scan functions of all checks together should fetch as few OIDs as - possible! - -Other issues: - -* Default values for check parameters (e.g. switch_cpu_default_levels) must be - chosen in a way that they make sense for *everybody*, not just for your special - case. In case you are not sure then rather choose too loose than too tight levels. - This helps avoid false alarms. - -* If the same configuration variable is used in multiple checks, *all* of them - must set a default value and all those values must be identical! - -* Your check should assume that the agent is always producing valid data. It - should *not* try to handle cases where the agent output is broken. This is - handled by Check_MK via Python exceptions. Otherwise you would make the code - uglier and also disable the debug handler. - -* int() vs. saveint(), float vs. savefloat(): int(s) will throw an exception if - if is not a valid number string (or empty). Then Check_MK will catch the exception - and make the check result "UNKNOWN" with an according error message. saveint(s) will - assume 0, if s is not valid. Important: use saveint() in all places, where you know - or suspect that some device does not supply valid data *but* the check can work - with the rest of the data and produce useful results. use int() in all other cases, - e.g. if the check does not make any sense if you have no valid data. - -Performance data: -* Only set perfdata flag when the check really produces performance data - output. - -* Each check that outputs performance data *must* have a dedicated PNP - graph definition in pnp-templates. If the check has warning and critical - levels then the graph must display those levels as yellow and red - lines. - -* Each check that outputs performance data must also have an RRA definition - the specifies which of MAX, MIN and AVERAGE is needed to display the - graph in its current (and maybe future) forms. Those are in pnp-rraconf. - Use a symlink here. - -* Each check that outputs performance data should have a perf-o-meter. - For checks part of Check_MK this must be done in web/plugins/perfometer/check_mk.py. - For third party checks this should be done in a separate file in web/plugins/perfometer. - -SNMP based checks: -* Only use numeric OIDs in your checks. Name based OIDs rely on MIB files - and the check won't work when the MIB files are not in place. -* The used numeric OIDs MUST be given with a leading dot. - -Forbidden things: -* Neither the check- nor the inventory function may use the print command - or otherwise output any data to stdout or stderr nor otherwise communicate - with the outside. An rare exception to this are checks that need a dedicated - data storage (such as logwatch: it keeps unread log messages in files). - -Manpages - -* Each check *must* have a man page. This should be: - - complete - - precise - - terse - - helpful!! - -* Information that must be contained in the description: - - What does the check exactly? - - Under which circumstances goes the check to WARN/CRIT? - - Which devices are supported by the check? - - Does the check require some configuration of the agent or - some separate plugin? (example: The logwatch check requires - the agent plugin mk_logwatch to be installed)