Introduction
Nagios vous permet de planifier des périodes d'arrêt pour les hôtes et les services que vous supervisez. Ceci est utile au cas où vous avez prévu d'arrêter un serveur pour maintenance, etc. Quand un hôte ou un service est dans une période d'arrêt planifié, les notifications pour cet hôte ou ce service ne sont pas envoyées.
Fichier des arrêts planifiés
Les arrêts planifiés des hôtes et services sont stockés dans le fichier des arrêts planifiés défini par une directive dans le fichier de configuration principal.
Mémorisation des arrêts planifiés
Les arrêts planifiés sont mémorisés, même si Nagios est relancé. Au démarrage, Nagios va lire le fichier des arrêts planifiés, supprimer toute entrée ancienne ou invalide, et planifier les arrêts pour les hôtes et services concernés.
Planifier l'arrêt
Vous pouvez planifier l'arrêt des hôtes et des services à travers le CGI d'informations complémentaires (en visualisant les informations soit d'un hôte soit d'un service). Cliquez le lien "Schedule downtime for this host/service" pour planifier l'arrêt.
Une fois l'arrêt d'un hôte ou d'un service planifié, Nagios ajoutera un commentaire à cet hôte/service indiquant que son arrêt est prévu durant la période que vous avez indiqué. Quand la période est passée, Nagios supprime automatiquement le commentaire ajouté. Pas mal, non ?
Arrêts planifiés fixes ou variables
Il y a deux types d'arrêts planifiés: les "fixes" et les "variables". Quand vous positionnez un arrêt à travers l'interface web, on vous demande s'il est fixe [fixed] ou variable [flexible]. Voici leur définition:
"Fixe" démarre et s'arrête à l'heure exacte programmée. Bon, celle-là était facile.
"Variable" est adapté à des arrêts dont vous savez qu'ils vont durer X minutes (ou heures), mais ne savez pas exactement quand cela va redémarrer. Quand vous choisissez "variable", Nagios va démarrer automatiquement au bon moment, quelque part entre l'heure de départ et l'heure de fin que vous avez spécifiées. L'arrêt durera aussi longtemps que la durée spécifiée. Ceci suppose que l'hôte ou service dont vous avez programmé l'arrêt s'arrête (ou devienne inaccessible) ou entre dans un état non-OK, quelque part entre votre heure de départ et d'arrêt.
L'heure à laquelle l'hôte ou le service aura un problème sera pour Nagios, l'heure de démarrage de l'arrêt planifié. Il durera ensuite aussi longtemps que vous l'avez spécifié, même si l'hôte ou le service revient dans un état normal avant la fin de l'arrêt planifié.
Ceci pour bonne raison : comme nous le savons tous, vous pouvez penser qu'un problème est résolu complètement (et redémarrer le serveur), au moins 10 fois avant qu'il ne se décide à vraiment marcher. Bien prévu n'est-ce pas ? :-)
Arrêts déclenchés sur évènement
Lorsque vous planifiez l'arrêt d'un hôte ou d'un service, vous
avez la possibilité de déclencher l'arrêt sur évènement.
L'arrêt planifié est alors déclenché lorsqu'un autre
service ou hôte démarre son arrêt planifié. Cette
fonctionnalité est extrêmement pratique lorsque l'arrêt planifié
d'un grand nombre de services ou d'hôtes dépend d'un hôte
ou d'un services particulier.
Par exemple, si vous planifiez un arrêt variable sur un hôte, vous
voudrez certainement déclencher l'arrêt planifié de tous
ses "fils".
Comment l'arrêt planifié affecte les notifications
Quand un hôte ou un service arrive dans la période d'arrêt planifié, Nagios n'autorisera pas l'émission des notifications pour cet hôte ou ce service. La suppression des notifications se fait par l'ajout d'un filtre à la logique de notification. Vous ne verrez pas d'icône dans les CGI indiquant la désactivation des notifications pour cet hôte/service. Quand la période d'arrêt planifié sera passée, Nagios autorisera l'émission des notifications pour cet hôte ou service comme il le ferait normalement.
Chevauchement d'arrêts planifiés
J'aime appeler ceci la loi de Murphy [NdT : "Si quelque chose ne doit pas fonctionner, il ne fonctionnera pas"]. Vous voyez de quoi je veux parler !! Vous arrêtez un serveur pour réaliser une mise à jour matérielle "de routine", pour réaliser plus tard que les drivers du S.E. ne fonctionnent pas, que le contrôleur RAID a fondu, ou que l'image disque a raté et rend vos disques originaux inutilisables. La morale de l'histoire est qu'une intervention de routine sur un serveur est susceptible de prendre trois ou quatre fois plus longtemps que ce que vous aviez prévu...
Prenons le scenario suivant :
Si vous planifiez des périodes d'arrêt qui se chevauchent pour un hôte ou un service (dans ce ca, les périodes étaient 19h30-21h30 et 21h20-1h30), Nagios attendra que la dernière période d'arrêt planifié soit écoulée avant d'autoriser l'émission des notifications pour cet hôte ou ce service. Dans cet exemple, les notifications seraient supprimées pour l'hôte A jusqu'à 1h30 mardi matin.