icinga2/doc/3.01-hosts-and-services.md

## <a id="hosts-services"></a> Hosts and Services

Icinga 2 can be used to monitor the availability of hosts and services. Services
can be virtually anything which can be checked in some way:

* Network services (HTTP, SMTP, SNMP, SSH, etc.)
* Printers
* Switches / Routers
* Temperature Sensors
* Other local or network-accessible services

Host objects provide a mechanism to group services that are running
on the same physical device.

Here is an example of a host object which defines two child services:

    object Host "my-server1" {
      address = "10.0.0.1"
      check_command = "hostalive"
    }

    object Service "ping4" {
      host_name = "localhost"
      check_command = "ping4"
    }

    object Service "http" {
      host_name = "localhost"
      check_command = "http_ip"
    }

The example creates two services `ping4` and `http` which belong to the
host `my-server1`.

It also specifies that the host should perform its own check using the `hostalive`
check command.

The `address` custom attribute is used by check commands to determine which network
address is associated with the host object.

### <a id="host-states"></a> Host States

Hosts can be in any of the following states:

Hosts can be in any of the following states:

  Name        | Description
  ------------|--------------
  UP          | The host is available.
  DOWN        | The host is unavailable.

### <a id="service-states"></a> Service States

Services can be in any of the following states:

  Name        | Description
  ------------|--------------
  OK          | The service is working properly.
  WARNING     | The service is experiencing some problems but is still considered to be in working condition.
  CRITICAL    | The service is in a critical state.
  UNKNOWN     | The check could not determine the service's state.

### <a id="hard-soft-states"></a> Hard and Soft States

When detecting a problem with a service Icinga re-checks the service a number of
times (based on the `max_check_attempts` and `retry_interval` settings) before sending
notifications. This ensures that no unnecessary notifications are sent for
transient failures. During this time the service is in a `SOFT` state.

After all re-checks have been executed and the service is still in a non-OK
state the service switches to a `HARD` state and notifications are sent.

  Name        | Description
  ------------|--------------
  HARD        | The host/service's state hasn't recently changed.
  SOFT        | The host/service has recently changed state and is being re-checked.