checkman/ucs_bladecenter_if

   1 title: UCS Bladecenter fibrechannel, ethernet and interconnect interfaces
   2 agents: agent_ucs_bladecenter
   3 catalog: hw/server/cisco
   4 license: GPL
   5 distribution: check_mk
   6 description:
   7  This check monitors the operational status, link speed, traffic, packet
   8  counts, discards and errors of network interfaces
   9
  10  Depending on the check parameters this check can go WARN or CRIT when the
  11  port status changes (i.e. is down), when the link speed changes (e.g. a
  12  port expected to be set to 1GBit/s operates only at 100MBit/s), when the
  13  absolute or procentual traffic of a port exceeds certain levels or if the
  14  rate of errors or discards exceeds configurable limits.
  15
  16  This check supports averaging the in- and  outgoing traffic over
  17  a configurable range of time by using an exponentially weighted moving
  18  average - just as Linux does for the CPU load averages.
  19  The averaging can be configured on a per host and per port base. This is
  20  done by adding a key {"average"} to the parameter dictionary with the number
  21  of minutes that the average should cover as its key. Port with averaging
  22  turned on output two additional performance values: the averaged traffic
  23  in bytes. If you have configured traffic levels, then those levels are
  24  applied to the averaged values.
  25
  26  This check monitores three types of interfaces. Ethernet, fibrechannel and
  27  interconnects. Each of this interfaces can be grouped in portchannels.
  28  If an interface is grouped in a portchannel a grouped interface service
  29  will be automatically created and the single interface is not displayed.
  30
  31  It is highly recommended to set the option if_inventory_uses_description
  32  because the interface index is quite useless for identifying the correct port.
  33
  34 item:
  35  The interface description, e.g. Interconnect-Group 1025
  36
  37 inventory:
  38  Per default the check autodetects portchannels and group the interfaces
  39  accordingly. Automatically grouped interfaces don't show up as single interface.
  40
  41  Furthermore you can manually configure additional groups with the following options
  42
  43  {Grouping:} In some situations you do not want to monitor a single
  44  interface but a group of interfaces that together form a pool.
  45  You can specifiy the members of a group by their port type and the item name(s) of
  46  the single interfaces. The data of all members is accumulated and put together
  47  in a single grouped interface service.
  48
  49  You can specify the groups with the ruleset {if_groups}.
  50  Groups are defined as list of dictionaries.
  51
  52  The keys are:
  53
  54   {"name"}:   String. Name of the group within the service description
  55
  56   {"iftype"}: Integer. Interface port type as integer
  57
  58   {"include_items"}: List of Strings. Interface item name. This name depends
  59   on further settings like if_inventory_uses_alias or if_inventory_uses_description
  60
  61   {"single"}(optional): Bool. Interfaces in this group do not show up
  62   as single service if "single" is set to True (Default: False)
  63
  64   For example: if_groups = ([{"name" : "Group WLAN", "iftype" : 6, "single" : True}], ["lan"], ALL_HOSTS )
  65