Nouveauté de Centreon 2.3 : downtime récurrent

Centreon 2.3 est disponible depuis le 17/10. Cette version apporte des nouveautés dans l’interface de supervision, dans l’interface de configuration et dans les fonctionnalités globales. Je vous propose une série d’articles sur les nouveautés de Centreon 2.3. La première nouveauté mise en avant dans cet article est l’apparition de « Downtime récurrent ».

Rappel : qu’est ce qu’un downtime

Un downtime est « un arrêt de service » ou « une maintenance » ou « un arrêt prévu de production ». Un downtime est généralement ajouté sur un équipement supervisé, dans l’interface de supervision, pour déclarer : « un administrateur va arrêter temporairement l’équipement ou l’application afin de réaliser une action ». L’action est soit une mise à jour, soit une re-configuration, soit un changement de disque dur, soit un transfert sur un serveur plus puissant, … L’idée du downtime est de prévenir tout le monde que l’élément sera arrêté, pendant une certaine durée et qu’il ne faut pas s’alerter de cet arrêt. L’avantage des downtimes est que:

  • l’élément est continuellement supervisé : ce n’est pas un arrêt de la supervision mais un arrêt de notification
  • par conséquent, les graphiques continuent de se remplir, même durant le downtime
  • les notifications ne sont pas faites : aucun mail ne sera envoyé lorsque l’équipement sera considéré comme « en panne » dans Centreon
  • l’élément « en panne » ne sera pas visible dans les « problèmes en cours » dans l’interface Centreon
  • tout le monde voit que l’élément est « en panne » mais que cette panne est un « arrêt prévu de production », non une véritable panne qu’il faut traiter

Configuration d’un downtime dans Centreon <= 2.2

Dans les anciennes versions Centreon, mettre un downtime sur un élément supervisé est « une action de supervision » (en opposition à l' »action de configuration de la supervision »). Cela signifie que c’est dans l’interface de supervision que l’action doit être faite. Pour cela, il faut cliquer sur l’équipement supervisé (soit le « host », soit le « service ») puis dans le menu de droite « service commands » (ou « host commands »), choisir « Schedule a downtime ».

Saisir un downtime simple (Centreon 2.x)

Les paramètres à saisir sont:

  • le nom du host impacté par le downtime
  • le nom du service impacté par le downtime, le cas échéant
  • si c’est un downtime fixe
  • la date de début de downtime
  • la date de fin du downtime
  • un commentaire

Remarque : ce comportement est bien entendu conservé dans la version 2.3 de Centreon.

Downtime fixe contre downtime flexible

Un downtime fixe débute à une heure précise et se termine à une heure précise. Par exemple, je définis que j’arrête mon équipement entre 21h et 23h ce soir. Dès lors, le downtime défini est un downtime fixe.

Le downtime flexible a une heure de début, une heure de fin et une durée. Le downtime est flexible car il ne va pas commencer précisément à l’heure de début mais est susceptible de commencer dès l’heure de début. Une fois commencé, le downtime durera autant que la durée définie. Par exemple, je définis qu’un downtime débute ce soir entre 21h et 23h avec une durée de 5 heures. Cela signifie que mon downtime débutera entre 21h et 23h. Une fois commencée, le downtime aura une durée de 5 heures, à partir du moment où il a commencé. S’il commence à 22h30, il se terminera à 3h30. Ce qui fait commencer le downtime est la panne détectée par Nagios. Cela permet de répondre au cas suivant: je sais combien de temps dure l’intervention mais je ne sais pas quand elle va commencer précisément car j’attends le « GO! » d’une autre équipe par exemple.

Downtime récurrent : cas d’utilisation

Le downtime récurrent permet de répondre aux cas suivants:

  • mon serveur est arrêté toutes les nuits pour être sauvegardé, cet arrêt dure (par exemple) 1 heure, cependant je ne sais pas quand précisément il sera arrêté : l’heure précise de son arrêt dépend du programme de sauvegarde. C’est un ordonnanceur de sauvegarde, les heures de sauvegarde dépendent des sauvegardes précédentes. Si l’une a été plus longue que prévue, la sauvegarde de mon équipement sera décalée dans le temps. Ce cas pouvait être géré avec les périodes de notification : on arrête les notifications pendant une plage suffisamment longue la nuit pour éviter d’être notifier d’une « panne ». Le problème est qu’alors l’élément est détecté comme « en panne ». Ce qui fausse les statistiques de disponibilité.
  • un autre cas : mon application est re-démarrée tous les premiers dimanche du mois. Ceci n’est pas gérable avec les notifications.

Configuration d’un downtime récurrent

Pour configurer un downtime récurrent, il faut se rendre dans la configuration d’un hôte ou d’un service (selon le cas) puis cliquer dans le menu gauche sur « Downtime ». Le chemin est donc : « Configuration ==> host ==> downtime ==> add ».

Ajout d'un downtime récurrent : accueil

 

De là, on peut ajouter une période de downtime. Dans l’exemple ci-dessous, j’ai ajouté un downtime flexible tous les dimanche et mercredi d’une durée de 2 heures, entre 2h et 4h.

Downtime récurrent flexible de deux heures

Il est possible d’ajouter une seconde période pour le downtime en cliquant sur le bouton + à côté de l’onglet « Period 1 ». Dès lors, une union des périodes de downtime est faite : c’est à dire que l’équipement est en downtime dès qu’il rentre dans une des périodes définies. Je peux ajouter autant de période que je le souhaite. Je peux choisir: de définir un downtime par jour de semaine en fonction du mois comme ci-dessous où mon downtime aura lieu « le premier dimanche du mois entre 2 heures et 4 heures »

Downtime récurrent : tous les 1ers dimanches du mois

Un autre cas d’utilisation est possible en sélectionnant le type « Monthly basis ». Enfin, pour terminer, je met en relation le downtime avec les équipements supervisés dans l’onglet « Relation »:

Downtime récurrent : relation

Je peux relier le downtime à un hôte, un service précis, un groupe d’hôte ou un groupe de service. Que se passe-t’il si j’associe un downtime à un host? Est ce que les services sont eux aussi en downtime? En fait, la réponse précise est : « cela dépend de votre configuration globale ». Dans le menu « Administration ==> Option ==> Centreon ==> Monitoring », des options permettent de définir le comportement du downtime:

Downtime récurrent : options globales

Je vous conseille de cocher la case « Set downtimes on services attached to hosts » 🙂

 

2 thoughts on “Nouveauté de Centreon 2.3 : downtime récurrent”

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *