Centreon Engine 1.4 – La recharge à chaud de votre configuration

This post is also available in: Anglais

Après plusieurs mois de développement et de tests, nous sommes fiers de pouvoir annoncer la sortie de Centreon Engine 1.4. Vous allez pouvoir enfin tester une des fonctionnalités tant attendue ;) : le “re-chargement” à chaud de la configuration.

Simple en apparence (surtout quand nous regardons le panel de softwares que nous utilisons tous les jours), cette fonctionnalité pouvait être vraiment difficile à intégrer surtout lorsque le produit de base n’a pas été étudié pour.
En regardant bien l’écosystème “Nagios”, on constate rapidement que seul Centreon Engine le propose. Nagios, Icinga, Shinken, Naemon : aucun de ces produits ne l’a intégrée. Seul Naemon, dernier né des forks de Nagios annonce réfléchir à l’intégration de cette fonctionnalité.
Alors pourquoi est-ce si compliqué ?

1. L’historique de ces projets

La majorité des projets cités précédemment est issue de Nagios. Au tout début des années 2000, Nagios est parti d’un besoin qui était de superviser des petits périmètres techniques critiques. A l’époque, le nombre d’équipements supervisés n’était pas important. Un simple ordonnanceur de commande pour faire des “checks” était alors plus que parfait pour le besoin. Les systèmes ne changeaient pas tous les jours et le “bon” vieux fichier de configuration fait maison était alors amplement suffisant.

Au fil des années, la supervision a pris une place plus qu’importante dans la vie d’une DSI. Elle est devenue plus que du confort : une obligation. Les DSI sont maintenant des centres de services et gérant parfois plusieurs centaines d’équipements, ils doivent répondre à des SLA. De ce fait, faire des mesures chaque minute ou toutes les 5 minutes est devenu une pratique courante. Cependant, le fichier de configuration n’est plus adapté pour les environnements d’aujourd’hui : plusieurs personnes éditent ces fichiers; plusieurs changements de configuration ont lieu chaque jour car les SI sont perpétuellement en mutation afin d’améliorer leur fonctionnement et répondre aux nouveaux besoins…

Or dans ce contexte de l’histoire des produits “Nagios”, le produit n’avait pas été pensé pour intégrer cette fonctionnalité.
Nos développeurs ont été confrontés à cette difficulté lorsque nous avons démarré ce chantier :

Centreon Engine (2)

Pas moins de 135 jours de développement ont été nécessaires pour arriver à nos fins et nous n’intègrons pas dans ce chiffre toutes les batteries de tests que nous avons ensuite du mettre en place pour garantir une bonne stabilité; pas moins de 20 à 30 000 lignes de code modifiées et des tests unitaires mis en place qui permettent à la fois de valider le code en place et valider le code nouvellement implémenté. Pour un gain de qualité intéressant.

2. L’open source

Comme évoqué dans le point précédent, cette modification a coûté du temps à nos équipes.
Seul un produit tel que Centreon édité par une entreprise peut se permettre de faire ce genre d’investissement. Des deadlines et des suivis qualité sont alors possibles, ce qui est plus compliqué à mettre en place dans un projet communautaire pour lequel les développeurs ne sont pas à 100 % de leur temps sur le projet.
Imaginez si nous avions dû développer cette fonctionnalité uniquement sur le temps libre comme certains autres projets open source (soir, week-end, vacances, entre midi et 2), le développement ne serait probablement pas encore terminé. C’est aussi une des raisons pour laquelle cette fonctionnalité a mis 14 ans à arriver sur ce genre de solution (2000 -> 2014). Au final, était-ce prioritaire d’intégrer ce genre de fonctionnalité : jusqu’à maintenant non, mais depuis 2 ou 3 ans et surtout depuis que nous avions évoqué le fait de vouloir le mettre en place dans Centreon Engine lors de notre Fork, elle est devenue primordiale pour nos utilisateurs.

3. Les contraintes “Supervision”

Travailler avec des fichiers de configuration : en effet nous avons besoin d’avoir un haut niveau de stabilité et on le sait, le fichier de configuration est assez sûr : on l’écrit, on le teste et une fois validé, on le pousse à notre application. Tant qu’il n’est pas modifié, le comportement du moteur ne changera pas.

Plusieurs personnes se sont montrées volontaires pour changer la donne dans le monde Nagios. Il y a quelques années, certains avaient créé des patchs ou des modules Nagios pour que la configuration de la supervision soit stockée en partie dans une arborescence LDAP.
Pratique : dès qu’un host est ajouté dans l’arbre, la supervision reçoit l’information et la modification est appliquée immédiatement.
Mais pourquoi n’est-ce pas dans le core de Nagios ?
Réponse des développeurs : si le LDAP tombe, plus de supervision. Et officiellement, Nagios est là pour superviser le LDAP… C’est le serpent qui se mord la queue.
Autre tentative sur la Mailing list de Nagios : stocker dans du MySQL… Même réponse… Seul le fichier de conf édité par VI (ou emacs pour les vrais) est plébiscité.

On comprend alors que les développeurs de Nagios désirent avoir le moins de briques techniques possible pour assurer la stabilité de Nagios. MySQL ou LDAP dans ces cas serait des SPOF et cela représente un trop grand risque. Officiellement, nous ne recensons pas de fichiers de conf qui auraient “crashé” en plein fonctionnement de Nagios :). Les seules fois où ces problèmes peuvent être évoqués sont les fautes de frappe ou d’inattention. On va dire que pour le coup, nous ne pouvons rien y faire.

4. Comment ça marche donc dans Centreon Engine ?

C’est très simple : avec des fichiers de configuration.
Vous allez me dire : qu’est ce qu’apporte cette version 1.4 donc ?

Le “re-chargement” à chaud se fait à la reception d’un signal SIGHUP. Engine détecte à la réception de ce signal que sa configuration a été modifiée et décide donc de lire de nouveau sa configuration pour effectuer un “diff” avec la configuration qu’il a en mémoire. Le parcours mémoire étant assez rapide, cela permet alors de prendre en compte rapidement les modifications / ajouts / suppressions. Pendant ce traitement, la supervision est mise en pause temporairement. La plupart du temps, cela prend 1 à 2 secondes. C’est beaucoup moins pénalisant qu’un reload ou un restart standard qui pouvait prendre au temps de Nagios et NDO 1.x peut-etre 20 à 25 min sur des configurations assez importantes.

Ce n’est bien sûr pas à vous d’envoyer le signal : le signal sera envoyé par le script d’init (/etc/init.d/centengine reload) ou par l’interface Centreon qui émettra ce signal suite à changement de configuration (sera disponible dans Centreon 3.x).

5. Qu’est ce que l’on gagne vraiment au final ?

Lors du “re-chargement” à chaud, les gains sont assez importants.

  1. Fini les arrêts complets de Centreon Engine
    1. plus de coupures de la supervision
    2. plus d’arrêts de réception des données passives (coupures du centengine.cmd)
    3. plus de décalages des events en queue durant la période d’arrêt du moteur de supervision)
  2. Terminés les arrêts complets du moteur qui permettent alors de ne plus avoir à recalculer toute la queue d’ordonnancement à chaque restart.
  3. Finis les envois globaux de toutes les infos en mémoire dans Centreon Engine via le broker au central, car seules les données modifiées sont envoyées (si un seuil a changé)
  4. Finis les envois des logs “initial_state” à chaque redémarrage ce qui pouvait faire “gonfler” les logs en cas de changement et de redémarrages nombreux certains jours.
  5. Plus de clignotement de l’interface : vous ne verrez plus l’interface de supervision se vider durant la prise en compte. Les pilotes d’exploitations seront alors plus tranquilles pour prendre en compte les incidents sans voir disparaîtres leurs alarmes au moment du “clic” :)

Cette version sera disponible très prochainement en téléchargement sur notre site ou directement dans votre repository yum de centreon. Nous espérons que vous apprécierez l’effort ainsi que le gain que cela apportera quotidiennement aux utilisateurs de Centreon.

Enjoy !

4 réflexions au sujet de « Centreon Engine 1.4 – La recharge à chaud de votre configuration »

  1. Y’a une configuration particulière à mettre en place ?
    J’ai ma CES entièrement à jour (yum update de centreon 2.5.1 + engine 1.4.4 + cbd, etc) et lorsque j’ajoute un service à un template d’hôte et que je demande à recréer les services associés à un hôte, je dois toujours redémarrer le moteur pour qu’il soit pris en compte.

    • Bonjour,

      Il y a toujours le besoin de re-générer la conf et ensuite d’envoyer une demande de reload par l’interface. Mais la prise en compte est plus rapide.

Leave a Reply