checkman/services

   1 title: Windows Services
   2 agents: windows
   3 catalog: os/ps
   4 license: GPL
   5 distribution: check_mk
   6 description:
   7  Check the current state of a Windows service.  Each service is either {running} or {stopped}
   8  or in a transitional state like {starting} or {stopping}.  This check becomes critical if the
   9  service in question is not in the state {running}. It is getting UNKNOWN if the service is missing
  10  on the system at all.
  11
  12  If you have just a small number of Windows hosts to monitor,
  13  manual check configuration with {checks +=} will probably do.
  14  With a larger number of hosts we propose using {inventory_services}.
  15  This allows auto-detection of services according to their names,
  16  current states and start types. The auto-detection can also make use
  17  of host tags in order to use different rules on different sets of
  18  hosts (for example for monitoring certain services only on production
  19  servers). Inventory and manual checks can be used in parallel.
  20  Since version 1.2.1i2 there is a new option {inventory_services_rules}
  21  available, which is used to configure same options as the {inventory_services}
  22  option but in a standardized format which is configurable via WATO.
  23
  24 item:
  25  The name of the service as string. Please note, that the agent replaces
  26  spaces in the service names with underscores. If you are unsure
  27  about the correct spelling of the name then please look at the
  28  output of the agent (cmk -d HOSTNAME). The service names are in the first column
  29  of the section {<<<services>>>}. Please do not mix up the service
  30  names with the display names of the services. Those are just being displayed
  31  as a further information.
  32
  33 inventory:
  34  The inventory function of this check helps you to auto-detect then services
  35  that should be monitored on your hosts. Because Check_MK cannot know, which
  36  services are important for you, you have to configure some rules.
  37
  38  As of version 1.1.10i2 it is very flexible, while still being compatible
  39  with the old simple-style format.
  40  In the variable {inventory_services} you specify a list of inventory
  41  declarations. In the easiest form, such a declaration is simply
  42  a string: the name of a service. On every host that service is found
  43  {running}, a check for that service will be created during inventory.
  44
  45  If you prefix the name with a tilde {~}, then the string is interpreted
  46  as a regular expression matching the {beginning} of the service name.
  47  So the declaration {"~Audio"} will mach {AudioSrv}, and {".*Mobile"}
  48  will match all services containing the work {Mobile}. All patterns
  49  are case sensitive. Please note: the check being created will
  50  {not} contain the regular expression but the precise spelling of the
  51  service. One rule with a regular expression can create several checks.
  52
  53  It is also possible to depend on the current state and/or the start
  54  type of the service when deciding whether to create a check. States
  55  and start types are appended and separated by a space. For example
  56  {"LanmanServer auto"} will match all services with the name {LanmanServer}
  57  which have the start type {auto}. Other possible start types are
  58  {boot}, {demand}, {disabled} and {system}. Please look at the agent output
  59  if you want to know, which kind of start types exist in your
  60  environment. The declaration {"Browser running"} means the same as
  61  just ommitting { running}, since that is the default. If you want
  62  to combine a state and start type, do this like the agent does,
  63  by using a slash: {"LmHosts running/auto"} will create a check for
  64  the service {LmHosts}, if that service if found running {and} has
  65  the start type auto.
  66
  67  If you need your inventory rules to depend on properties of the host
  68  or just apply on some selected hosts, you can use "tuple"-entries
  69  instead of strings. Such an entries consist of an optional list of
  70  host tags, the keyword {ALL_HOSTS} or an explicit list of hosts and
  71  a {list} of service declarations like the one discussed above. Please
  72  consult the examples for details.
  73
  74  Since version 1.2.1i2 there is a new option {inventory_services_rules}
  75  available, which is used to configure same options as the {inventory_services}
  76  option but in a standardized format. The option holds a list of rules
  77  where each rule contains one entry matching a list of service matching
  78  strings (regexes) state/start mode.
  79