granicus.if.org Git - icinga2/blob - doc/6.09-volatile-services.md

   1 ## <a id="volatile-services"></a> Volatile Services
   2
   3 By default all services remain in a non-volatile state. When a problem
   4 occurs, the `SOFT` state applies and once `max_check_attempts` attribute
   5 is reached with the check counter, a `HARD` state transition happens.
   6 Notifications are only triggered by `HARD` state changes and are then
   7 re-sent defined by the `interval` attribute.
   8
   9 It may be reasonable to have a volatile service which stays in a `HARD`
  10 state type if the service stays in a `NOT-OK` state. That way each
  11 service recheck will automatically trigger a notification unless the
  12 service is acknowledged or in a scheduled downtime.