checkman/ps

   1 title: State and Count of Processes
   2 agents: linux, windows, aix, solaris, openvms
   3 catalog: os/ps
   4 license: GPL
   5 distribution: check_mk
   6 description:
   7  This check looks into the list of then current running processes for
   8  those matching a certain name or regular expression and optionally
   9  being owned by a certain user. The number of
  10  matching processes is matched against warning and critical levels.
  11
  12 item:
  13  A user definable service description for Nagios.
  14  That description must be unique within each host.
  15  Changing the description will make Nagios think that
  16  it is another service.
  17
  18 inventory:
  19  As of version 1.1.1, {ps} supports inventory. Since Check_MK cannot
  20  know which processes are of relevance to you, some configuration is
  21  needed. The configuration is done via {inventory_processes}. The structure
  22  of that variable is a list of seven-tuples. It is similar but not
  23  completely the same as the configuration of manual checks. The seven
  24  components of each entry are: {(1)} a service description, {(2)} a pattern
  25  (just as the first parameter of the check), {(3)} a
  26  user specification and {(4)} - {(7)} the warning and critical levels
  27  for the number of processes.
  28
  29  During inventory Check_MK tries to match all entries on each
  30  process found on the target host. If an entry matches, a new check will
  31  be created according to the entry (if it's not already existing).
  32
  33  The {service description} may contain one or more occurances of {%s}.
  34  If you do this, then the pattern must be a regular expression and
  35  be prefixed with {~}. For each {%s} in the description, the expression has to contain
  36  one "group". A group is a subexpression enclosed in brackets, for example
  37  {(.*)} or {([a-zA-Z]+)} or {(...)}. When the inventory finds a process
  38  matching the pattern, it will substitute all such groups with the
  39  {actual values} when creating the check. That way one rule can create
  40  several checks on a host.
  41
  42  If the pattern contains more groups then occurrances of {%s} in
  43  the service description then only the first matching subexpressions
  44  are used for the service descriptions. The matched substrings corresponding
  45  to the remaining groups are copied into the regular expression, nevertheless.
  46
  47  New in version 1.2.2: As an alternative to {%s} you may also use {%1}, {%2},
  48  etc. These will be replaced by the first, second, ... matching group. This
  49  allows you to reorder things.
  50
  51  Wildcards not enclosed by brackets are simply copied verbatim to the created
  52  checks. Please refer to the examples for more details.
  53
  54  The {user specification} can either be a user name (string). The inventory
  55  will then trigger only if that user matches the user the process is running as
  56  and the resulting check will require that user.  Alternatively you can specify
  57  {ANY_USER} or {GRAB_USER}.  If you specify {ANY_USER} then the user field
  58  will simply be ignored.  The created check will not check for a specific user.
  59
  60  Specifying {GRAB_USER} makes the created check expect the process to run
  61  as the same user as during inventory: the user name will be hardcoded into
  62  the check. In that case if you put {%u} into the service description,
  63  that will be replaced by the actual user name during inventory. You need
  64  that if your rule might match for more than one user - your would create
  65  duplicate services with the same description otherwise.
  66
  67  The {warning and critical levels} are simply copied to the created
  68  checks.
  69
  70  As of version {1.1.7i1} ps inventory allows optional host specification.
  71  You can prepend a list of host names or a list of tag names and {ALL_HOSTS}
  72  to some of all rules of the inventory specification. That way you can
  73  make the inventory apply some rules only to certain hosts.
  74