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

86 lines
2.9 KiB
Markdown
Raw Normal View History

## <a id="hosts-services"></a> Hosts and Services
2013-10-02 09:50:26 +02:00
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
2013-10-02 09:50:26 +02:00
on the same physical device.
Here is an example of a host object which defines two child services:
object Host "my-server1" {
2014-03-29 01:13:28 +01:00
macros.address = "10.0.0.1",
check = "ping4"
}
2013-10-02 09:50:26 +02:00
2014-03-29 01:13:28 +01:00
apply Service "ping4" {
check_command = "ping4"
assign where host.name == "my-server1"
}
2013-10-02 09:50:26 +02:00
2014-03-29 01:13:28 +01:00
apply Service "http" {
check_command = "http_ip"
assign where host.name == "my-server1"
2013-10-02 09:50:26 +02:00
}
2013-10-07 09:35:44 +02:00
The example host `my-server1` creates two services which belong to this host:
`ping4` and `http`.
2013-10-02 09:50:26 +02:00
It also specifies that the host should inherit its availability state from the
2013-10-07 09:35:44 +02:00
`ping4` service.
2013-10-02 09:50:26 +02:00
> **Note**
>
> In Icinga 1.x hosts had their own check command, check interval and
> notification settings. Instead, in Icinga 2 hosts inherit their state
> from one of its child services. No checks are performed for the host
> itself.
2013-10-07 09:35:44 +02:00
The `address` macro is used by check commands to determine which network
2013-10-02 09:50:26 +02:00
address is associated with the host object.
### <a id="host-states"></a> Host States
2013-10-02 09:50:26 +02:00
Hosts inherit their state from the host check service that is specified using
2013-10-07 09:35:44 +02:00
the `check` attribute.
2013-10-02 09:50:26 +02:00
Hosts can be in any of the following states:
Name | Description
------------|--------------
UP | The host is available.
DOWN | The host is unavailable.
UNREACHABLE | At least one of the host's dependencies (e.g. its upstream router) is unavailable causing the host to be unreachable.
### <a id="service-states"></a> Service States
2013-10-02 09:50:26 +02:00
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
2013-10-02 09:50:26 +02:00
When detecting a problem with a service Icinga re-checks the service a number of
2013-10-07 09:35:44 +02:00
times (based on the `max_check_attempts` and `retry_interval` settings) before sending
2013-10-02 09:50:26 +02:00
notifications. This ensures that no unnecessary notifications are sent for
2013-10-07 09:35:44 +02:00
transient failures. During this time the service is in a `SOFT` state.
2013-10-02 09:50:26 +02:00
After all re-checks have been executed and the service is still in a non-OK
2013-10-07 09:35:44 +02:00
state the service switches to a `HARD` state and notifications are sent.
2013-10-02 09:50:26 +02:00
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.