Arrêt planifié

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 scénario suivant :

  1. Vous planifiez un arrêt de l'hôte A de 19h30 à 21h30 le lundi
  2. Vous arrêtez le serveur vers 19h45 lundi soir pour une mise à jour des disques durs
  3. Après avoir perdu une heure et demie à vous battre avec des erreurs SCSI et des incompatibilités de drivers, vous arrivez finalement à booter la machine
  4. A 21h15 vous vous apercevez qu'une de vos partitions a été cachée ou semble n'exister nulle part sur le disque
  5. Sachant que la nuit va être longue, vous retournez planifier un arrêt supplémentaire pour l'hôte A de 21h20 lundi à 1h30 mardi matin.

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.