mirror of https://github.com/Icinga/icinga2.git
85 lines
2.8 KiB
Markdown
85 lines
2.8 KiB
Markdown
|
## 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 together 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" {
|
||
|
|
services["ping4"] = {
|
||
|
|
check_command = "ping4"
|
||
|
|
},
|
||
|
|
|
||
|
|
services["http"] = {
|
||
|
|
check_command = "http_ip"
|
||
|
|
},
|
||
|
|
|
||
|
|
check = "ping4",
|
||
|
|
|
||
|
|
macros["address"] = "10.0.0.1"
|
||
|
|
}
|
||
|
|
|
||
|
The example host `my-server1` creates two services which belong to this host:
|
||
|
|
`ping4` and `http`.
|
||
|
|
|
||
|
|
It also specifies that the host should inherit its availability state from the
|
||
|
|
`ping4` service.
|
||
|
|
|
||
|
|
> **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.
|
||
|
|
|
||
|
|
The `address` macro is used by check commands to determine which network
|
||
|
|
address is associated with the host object.
|
||
|
|
|
||
|
|
### Host States
|
||
|
|
|
||
|
|
Hosts inherit their state from the host check service that is specified using
|
||
|
|
the `check` attribute.
|
||
|
|
|
||
|
|
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.
|
||
|
|
|
||
|
|
### 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.
|
||
|
|
|
||
|
|
### 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.
|