mirror of https://github.com/Icinga/icinga2.git
105 lines
4.0 KiB
Markdown
105 lines
4.0 KiB
Markdown
## <a id="downtimes"></a> Downtimes
|
|
|
|
Downtimes can be scheduled for planned server maintenance or
|
|
any other targetted service outage you are aware of in advance.
|
|
|
|
Downtimes will suppress any notifications, and may trigger other
|
|
downtimes too. If the downtime was set by accident, or the duration
|
|
exceeds the maintenance, you can manually cancel the downtime.
|
|
Planned downtimes will also be taken into account for SLA reporting
|
|
tools calculating the SLAs based on the state and downtime history.
|
|
|
|
> **Note**
|
|
>
|
|
> Downtimes may overlap with their start and end times. If there
|
|
> are multiple downtimes triggered for one object, the overall downtime depth
|
|
> will be more than `1`. This is useful when you want to extend
|
|
> your maintenance window taking longer than expected.
|
|
|
|
### <a id="fixed-flexible-downtimes"></a> Fixed and Flexible Downtimes
|
|
|
|
A `fixed` downtime will be activated at the defined start time, and
|
|
removed at the end time. During this time window the service state
|
|
will change to `NOT-OK` and then actually trigger the downtime.
|
|
Notifications are suppressed and the downtime depth is incremented.
|
|
|
|
Common scenarios are a planned distribution upgrade on your linux
|
|
servers, or database updates in your warehouse. The customer knows
|
|
about a fixed downtime window between 23:00 and 24:00. After 24:00
|
|
all problems should be alerted again. Solution is simple -
|
|
schedule a `fixed` downtime starting at 23:00 and ending at 24:00.
|
|
|
|
Unlike a `fixed` downtime, a `flexible` downtime end does not necessarily
|
|
happen at the provided end time. Instead the downtime will be triggered
|
|
by the state change in the time span defined by start and end time, but
|
|
then last a defined duration in minutes.
|
|
|
|
Imagine the following scenario: Your service is frequently polled
|
|
by users trying to grab free deleted domains for immediate registration.
|
|
Between 07:30 and 08:00 the impact will hit for 15 minutes and generate
|
|
a network outage visible to the monitoring. The service is still alive,
|
|
but answering too slow to Icinga 2 service checks.
|
|
For that reason, you may want to schedule a downtime between 07:30 and
|
|
08:00 with a duration of 15 minutes. The downtime will then last from
|
|
its trigger time until the duration is over. After that, the downtime
|
|
is removed (may happen before or after the actual end time!).
|
|
|
|
### <a id="scheduling-downtime"></a> Scheduling a downtime
|
|
|
|
This can either happen through a web interface (Icinga 1.x Classic UI or Web)
|
|
or by using the external command pipe provided by the `ExternalCommandListener`
|
|
configuration.
|
|
|
|
Fixed downtimes require a start and end time (a duration will be ignored).
|
|
Flexible downtimes need a start and end time for the time span, and a duration
|
|
independent from that time span.
|
|
|
|
> **Note**
|
|
>
|
|
> Modern web interfaces treat services in a downtime as `handled`.
|
|
|
|
### <a id="triggered-downtimes"></a> Triggered Downtimes
|
|
|
|
This is optional when scheduling a downtime. If there is already a downtime
|
|
scheduled for a future maintenance, the current downtime can be triggered by
|
|
that downtime. This renders useful if you have scheduled a host downtime and
|
|
are now scheduling a child host's downtime getting triggered by the parent
|
|
downtime on NOT-OK state change.
|
|
|
|
### <a id="recurring-downtimes"></a> Recurring Downtimes
|
|
|
|
[ScheduledDowntime objects](#objecttype-scheduleddowntime) can be used to set up
|
|
recurring downtimes for services.
|
|
|
|
Example:
|
|
|
|
template ScheduledDowntime "backup-downtime" {
|
|
author = "icingaadmin",
|
|
comment = "Scheduled downtime for backup",
|
|
|
|
ranges = {
|
|
monday = "02:00-03:00",
|
|
tuesday = "02:00-03:00",
|
|
wednesday = "02:00-03:00",
|
|
thursday = "02:00-03:00",
|
|
friday = "02:00-03:00",
|
|
saturday = "02:00-03:00",
|
|
sunday = "02:00-03:00"
|
|
}
|
|
}
|
|
|
|
object Host "localhost" {
|
|
import "generic-host",
|
|
|
|
...
|
|
services["load"] = {
|
|
templates = [ "generic-service" ],
|
|
|
|
check_command = "load",
|
|
|
|
scheduled_downtimes["backup"] = {
|
|
templates = [ "backup-downtime" ]
|
|
}
|
|
},
|
|
}
|