shinken_logo

Etude Shinken / Centreon

Dans le cadre d’une mission, j’ai souhaité mettre en avant un produit innovant afin de sortir du couple Nagios / Centreon. En effet, Out Of the Box, Les performances sur environnements virtualisés (VMWare) sont assez médiocres … (1500 checks / 5 min) avec une forte accumulation de maintenance.
J’ai donc déployé Shinken / Centreon avec les problèmes de compatibilité que cela allait supposer et qui étaient connus au moment de la décision.
Shinken est une ré-implémentation de Nagios en Python qui garde la rétro compatibilité avec Nagios, tout en introduisant un certain nombre de fonctionnalités, comme la découverte d’objets, des règles business, etc…

Avant le déploiement voici la liste des pour et des contre :

Les pour :

  • Équilibrage de charge
  • Haute disponibilité
  • Performant
  • Scalable
  • Rétro compatible Nagios
  • Fonctionne bien en environnement virtualisé
  • Codé en langage moderne (Python)

Les contre :

  • Compatibilité moyenne avec Centreon
  • Nécessite beaucoup de dépendances
  • Consomme de la mémoire

Maquette :

Le projet de migration d’un autre produit vers Shinken / Centreon (version 1.2.2) validé, j’ai entrepris de créer une maquette avec les cinq applications les plus importantes afin de me faire une idée concrète.
Globalement l’installation est simple et sans accroc grâce à un script complet qui installe l’ensemble des composants et des dépendances (très nombreuses et qui requièrent les droits root pour yum).
J’ai donc installé et configuré les serveurs suivants :

  • Centreon (8 Go de RAM) : Centreon ; Shinken- Arbiter ; Shinken-Scheduler ; Shinken-Broker ; Shinken-Receiver ; Shinken-Reactionner.
  • DB (8 Go de RAM): MySQL ; MongoDB (pour la rétention des états et la configuration de la WebUI de Shinken).
  • Poller1 (4 Go de RAM) : Shinken-Scheduler ; Shinken-Poller.
  • Poller2 (4 Go de RAM) : Shinken-Scheduler ; Shinken-Poller.

Premier point délicat, l’interfaçage avec Centreon. En effet, lorsque l’on vérifie la configuration, cela échoue car Shinken ne renvoie pas la bonne ligne à la fin de cette vérification. J’ai donc patché et mis en forme la sortie pour la rendre plus lisible.
Un second patch a été réalisé pour pouvoir utiliser les règles Business (autre avantage de Shinken) comme celles de Nagios BPA mais en plus évolué.

Montée en charge et problèmes rencontrés :

Au fur et à mesure de l’avancement du déploiement, je constate une forte montée en RAM due à une forte consommation de Shinken-Broker. Ce rôle étant primordial pour la visibilité (Logs, Livestatus, NDO, Gra- phiques, etc…), le fait que le processus soit tué par un manque de mémoire est relativement gênant.
De plus, deux versions bugfixes sont venues corriger des bugs importants (pour la génération de log et l’ordonnancement ainsi que pour les downtime) et en apporter d’autres.
Au niveau comportement des Pollers, l’utilisation d’agentless consomme beaucoup de ressources au niveau CPU et peu au niveau RAM.
La compatibilité entre Centreon et Shinken est aussi un facteur bloquant car il empêche de distribuer la charge sur plusieurs serveurs car dans la vision Centreon, un Poller représente les rôles d’Arbiter, Scheduler et Broker au minimum et comme ce dernier est le plus important pour dialoguer avec Centreon, il peut difficilement être séparé des autres.

Conclusion et direction prise :

La maquette a été réalisée sur un nombre peu important de services (env. 2300) et la consommation de mémoire était trop importante pour monter au delà. De plus, les deux versions bugfixes ont été sorties avec très peu de temps entre les deux car la 1.2.3 introduisait un bug critique.
Cette situation devenant plus que gênante, j’ai migré la maquette vers Nagios (avec sa RAM divisée par 2) et optimisé ma configuration et mon architecture pour supporter l’utilisation en environnement virtualisé avec les éléments suivants:

  • Utilisation de RAMDISKs.
  • Mettre en mémoire certaines tables NDO.
  • Utilisation de mod_gearman pour déléguer les exécutions des checks à des workers dédiés.

Au passage j’ai rajouté un Poller pour absorber la charge d’exécution et j’ai les indicateurs suivants:

  • Nombre d’hôtes: 630.
  • Nombre de services: 5069.
  • Latence: 0,4s.

Les serveurs Centreon et Nagios sont très peu chargés et avec des workers supplémentaires bien dimensionnés, il peuvent accueillir une charge bien plus grande.
G. LE BRIS

0 réponses

Répondre

Vous souhaitez vous joindre à la discussion ?
N'hésitez pas !

Laisser un commentaire

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