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)