Introduction
Shinken allows you to schedule periods of planned downtime for hosts and check that you're monitoring. This is useful in the event that you actually know you're going to be taking a server down for an upgrade, etc.
Scheduling Downtime
You can schedule downtime with your favorite UI or as an external command in cli.
Once you schedule downtime for a host or check, Shinken will add a comment to that host/check indicating that it is scheduled for downtime during the period of time you indicated. When that period of downtime passes, Shinken will automatically delete the comment that it added. Nice, huh?
How Scheduled Downtime Affects Notifications
When a host or check is in a period of scheduled downtime, Shinken will not allow normal notifications to be sent out for the host or check. However, a "DOWNTIMESTART" notification will get sent out for the host or check, which will serve to put any admins on notice that they won't receive upcoming problem alerts.
When the scheduled downtime is over, Shinken will allow normal notifications to be sent out for the host or check again. A "DOWNTIMEEND" notification will get sent out notifying admins that the scheduled downtime is over, and they will start receiving normal alerts again.
If the scheduled downtime is cancelled prematurely (before it expires), a "DOWNTIMECANCELLED" notification will get sent out to the appropriate admins.
Overlapping Scheduled Downtime
I like to refer to this as the "Oh crap, its not working" syndrome. You know what I'm talking about. You take a server down to perform a "routine" hardware upgrade, only to later realize that the OS drivers aren't working, the RAID array blew up, or the drive imaging failed and left your original disks useless to the world. Moral of the story is that any routine work on a server is quite likely to take three or four times as long as you had originally planned...
Let's take the following scenario:
- You schedule downtime for host A from 7:30pm-9:30pm on a Monday
- You bring the server down about 7:45pm Monday evening to start a hard drive upgrade
- After wasting an hour and a half battling with SCSI errors and driver incompatibilities, you finally get the machine to boot up
- At 9:15 you realize that one of your partitions is either hosed or doesn't seem to exist anywhere on the drive
- Knowing you're in for a long night, you go back and schedule additional downtime for host A from 9:20pm Monday evening to 1:30am Tuesday Morning.
Enterprise permet de définir la planification de périodes de mise sous maintenance des hôtes et checks que vous supervisez.
Planifier une maintenance
Vous pouvez le faire soit dans l'UI du portail soit en ligne de commande en CLI.
Dès qu'une maintenance est planifiée, un commentaire sera visible sur l'hôte ou le check. Celui-ci sera automatiquement supprimé dès que la période sera passée.
Comment les maintenances planifiées affectent les notifications
Quand un hôte ou un check est en période de maintenance, l'envoi normal de notifications est bloqué. Cependant, une notification de début de période sera envoyée afin d'alerter l'administrateur qu'il ne sera pas notifié pendant cette période.
Lorsque cette période est passée, les notifications retrouvent leur mode de gestion normal. Une notification sera d'ailleurs envoyée à l'administrateur pour l'avertir qu'il va de nouveau être notifié normalement.
Si la maintenance est annulée avant la fin de période planifiée, les notifications retrouvent également leur mode de gestion normal.
Enchainement de périodes de maintenance
Prenons le scénario suivant :
- Vous planifiez une maintenance sur un hôte de 19:30 à 21:30 le lundi
- Vous stoppez le serveur vers 19:45 le lundi soir pour upgrader un disque
- Après avoir bataillé pendant 1 heure et demi avec des erreurs SCSI et des incompatibilités de driver, vous arrivez finalement à redémarrer le serveur
- A 21:15, vous réalisez qu'une partition a disparu
- Sachant que ça risque de durer longtemps...vous décidez de replanifier une période de maintenance de 21:20 le lundi soir à 1:30 le mardi.
Si vous enchaînez des périodes de maintenance sur un hôte ou un check (dans ce cas les périodes étaient 19:40 -21:30 et 21:20 -1:30), Shinken Enterprise va attendre la fin de la dernière période avant de rétablir le mode de gestion normal des notifications. Dans ce cas, elle sera établie seulement à partir de 1:30 mardi If you schedule overlapping periods of downtime for a host or check (in this case the periods were 7:40pm-9:30pm and 9:20pm-1:30am), Shinken will wait until the last period of scheduled downtime is over before it allows notifications to be sent out for that host or check. In this example notifications would be suppressed for host A until 1:30am Tuesday morning .