.werks/8273

   1 Title: Recurring Scheduled Downtimes - adhoc via command and also via rule set
   2 Level: 3
   3 Edition: cee
   4 Component: cmc
   5 Version: 1.2.7i2
   6 Date: 1434094213
   7 Class: feature
   8
   9 Check_MK now supports <i>recurring scheduled downtimes</i> (or simply
  10 <i>recurring downtimes</i>).  Let's assume that you have a couple of servers
  11 that are rebooted once a week always at the same time.  You surely do not
  12 want any notifications about that, you also do not want to have these hosts
  13 displayed as "problems" in the problem views.
  14
  15 Up to now the only useful tool in such situations was the notification
  16 period. But that way you can just suppress notifications - not the problem
  17 display. Also setting up notification periods requires configuration
  18 permissions (WATO).
  19
  20 The new recurring downtimes create normal scheduled downtimes for you on
  21 a regular base. This is a direct enhancement of the downtimes that already
  22 exist. They now have a new field where you can specify an interval in which
  23 the downtime should be repeated. Everything is then handled by the monitoring
  24 core (CMC) and no external cron job is involved. This has a few advantages:
  25
  26 LI:No cron job is needed
  27 LI:The recurring downtimes are visible in the <i>Downtimes</i> view - even if they are currently not active
  28 LI:Recurring downtimes can be set and removed by using the existing downtime commands
  29
  30 You can create recurring downtimes in two ways:
  31
  32 H2:Using commands
  33
  34 The easiest way is to just use the same commands as for creating one-time
  35 downtimes. The command box now has a new option <i>Repeat this downtime
  36 on a regular base every ____</i>.  You can choose between <i>hourly</i>,
  37 <i>daily</i> and <i>weekly</i>. If you e.g.  create a downtime for 12:34 on
  38 Monday and select <i>weekly</i> then this downtime will be repeated on every
  39 Monday from now on. Changes in the daylight saving time are compensated,
  40 so the time of day (12:34) will be valid in and out of DST.
  41
  42 Such downtimes behave exactly like one-time downtimes - with the single
  43 difference that they are not being deleted when they end but shifted to the
  44 next interval instead.
  45
  46
  47 U2:Using rule sets
  48
  49 There is a second way to create recurring downtimes: two new WATO rule sets
  50 called <i>Recurring downtimes for hosts</i> and <i>Recurring downtimes for
  51 services</i>. Using these you can base the downtimes on WATO folders and host
  52 tags. While this could also by done by selecting host and services via the GUI
  53 and applying commands - it still has one advantage: You can specify downtimes
  54 for objects that <i>still do not exist</i>. If you create a recurring downtime
  55 for all servers with the tag <i>Windows</i> then also Windows hosts that
  56 will be added at a later time will automatically get that recurring downtime.
  57
  58 Recurring downtimes that have been created via a rule can not be deleted by
  59 the operator via a command, of course. All downtime views have a new column
  60 <i>Origin</i> that shows you wether a downtime exists due to a <i>command</i>
  61 or due to <i>configuration</i>.
  62