[checkmk-commits] Check_MK Git: check_mk: Tuned man-page of h3c_lanswitch_cpu

Module: check_mk Branch: master Commit: b2d60016b9f1d363de1044df501256df6811b2ed URL: http://git.mathias-kettner.de/git/?p=check_mk.git;a=commit;h=b2d60016b9f1d3… Author: Mathias Kettner <mk(a)mathias-kettner.de> Date: Fri Feb 25 12:49:26 2011 +0100 Tuned man-page of h3c_lanswitch_cpu --- README.writing_checks | 29 +++++++++++++------------ checkman/h3c_lanswitch_cpu | 49 +++++++++++++++++++++++-------------------- checks/h3c_lanswitch_cpu | 2 +- 3 files changed, 42 insertions(+), 38 deletions(-) diff --git a/README.writing_checks b/README.writing_checks index 687720b..6620511 100644 --- a/README.writing_checks +++ b/README.writing_checks @@ -121,9 +121,6 @@ Other issues: 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. -Manpages: -* - Performance data: * Only set perfdata flag when the check really produces performance data output. @@ -136,14 +133,18 @@ 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. -* Scan function: - -Agent based checks: - -* Put sample output snippets of the agent as comments into - the check source code. Add examples for all cases handled - by your check. -> That makes the code more easy to understand - and help not to break something if someone changes something - in the check's parser. - In an optimal case you include several code examples of different - states. +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) diff --git a/checkman/h3c_lanswitch_cpu b/checkman/h3c_lanswitch_cpu index 3c742c0..a852990 100644 --- a/checkman/h3c_lanswitch_cpu +++ b/checkman/h3c_lanswitch_cpu @@ -1,39 +1,42 @@ -title: Check CPU Utilization of 3COM and H3C switches. +title: Check CPU utilization of 3COM and H3C switches agents: snmp author: Florian Heigl <fh(a)mathias-kettner.de> license: GPL distribution: check_mk description: -This Check queries the CPU utilization for various LAN switches that are supporting the MIB for H3C lan switches. -These are: -Newer 3Com switches (Superstack 4 and later), H3C branded switches and now for example the HP "A-Series" Networking gear. The same switches from the original maker Huawei are not supporting the MIB. These also only support cpu stats, whereas the H3C Mib also gives Memory stats and Fabric status etc. -The check should correctly label the CPU in your switch / stack / core switch module slots. - -Note some of these switches don't handle snmp well and might generate up to 90% cpu load while queried. -To accomodate for this you should lower the frequency of SNMP based checks with them. -The CPU usage ratio returned by the check is the average load of the last 5 minutes. + This Check queries the CPU utilization of various LAN switches that are + supporting the MIB for H3C lan switches. These are: newer 3COM switches + (Superstack 4 and later), H3C branded switches and now for example the HP + "A-Series" Networking gear. The same switches from the original maker Huawei + are {not} supporting the MIB. The check tries to correctly label the CPU in + your switch / stack / core switch module slots. + The check goes WARN/CRIT if the average CPU usage of the last {five minutes} + exceeds configurable levels. + Note that some of these switches don't handle SNMP well and might generate + up to 90% cpu load while queried. To accomodate for this you should lower + the frequency of SNMP based checks with them. + Some devices have a high usage even in normal conditions (i.e. running full + BGP tables). In that case you might have to fine tune the check parameters + or even have to disable the check. inventory: - The check will add one service per Unit/CPU in a stack. + The check will create one separate service per CPU. -[parameters] -warning (int): the percentage of 1-minute average load at which the switch is considered too busy. +item: + A string describing the switch and unit number, for example {"Switch 2 CPU 0"} + or {"Switch 1 Slot 11"}. -critical (int): the percentage of 1-minute average load at which the switch is considered overloaded. +perfdata: + One value: the 5 minute average CPU usage in percent (from 0 to 100). +[parameters] +warning (int): the percentage of 5-minute average usage at which the check returns WARN. +critical (int): the percentage of 5-minute average usage at which the check goes critical. [configuration] -h3c_lanswitch_cpu_default_levels (int, int): the warn and critical levels for the check. - They are set to default to 50% for "WARN" and 75% for "CRIT". - If you expect heavy load (i.e. running full BGP tables) then you might want to adjust these. +switch_cpu_default_levels (int, int): the default warn and critical levels. + They are preset to {(50,75)} (meaning 50% for WARN and 75% for CRIT). - -item: - The CPU found by inventory (it's OID is a multiple of 65536 for stackable switches, or the slot Id it resides at for multicontroller switches and will be divided to come to a sane value). Later multicore CPU switches should be supported already. - - -perfdata: - It does generate performance data (the 5min average CPU load) diff --git a/checks/h3c_lanswitch_cpu b/checks/h3c_lanswitch_cpu index 227411e..fdadc26 100644 --- a/checks/h3c_lanswitch_cpu +++ b/checks/h3c_lanswitch_cpu @@ -73,7 +73,7 @@ def check_h3c_lanswitch_cpu(item, params, info): if h3c_lanswitch_cpu_genitem(line[0]) == item: util = int(line[1]) infotext = (" - average usage was %d%% over last 5 minutes." % util) - perfdata = [ ( "usage", util, warn, crit, 0) ] + perfdata = [ ( "usage", util, warn, crit, 0, 100) ] if util > crit: return (2, "CRIT" + infotext, perfdata)