1. Un début de projet à l'histoire atypique

Avant de nous lancer tête baissée dans notre étude de Shinken et de son architecture, prenons quelques instants pour voir pourquoi et comment il a vu le jour.

1.1. Nagios : un projet au ralenti

L'histoire de Shinken ne peut se comprendre qu'en revenant sur celle de Nagios au cours de ces dernières années. Ce dernier a commencé sa grande aventure il y a 10 ans sous le nom Netsaint. Sa modularité lui apporte au fil du temps une forte renommée dans le monde open source. Après un renommage en Nagios pour cause de nom déjà déposé, il continue son développement et cristallise autour de lui une très forte communauté qui lui confère un statut de star de la supervision qui commence à dépasser le cadre des seuls logiciels libres.

Cependant, depuis plus de deux ans, le développement s'est fortement ralenti. L'auteur de Nagios n'étant presque plus présent sur la mailing list du projet, les apports de la communauté sur le cœur du projet se sont faits de moins en moins nombreux. Cette absence s'explique facilement : après de nombreuses années à gérer ce logiciel open source, l'auteur de Nagios, Ethan Galstad, a légitimement créé une société de services pour vivre de ce grand projet. Son absence prolongée a irrité une partie de la communauté qui a lancé un fork il y a plus d'un an : Icinga.

Ce dernier n'a pas réussi à s'attirer une grande part de la communauté restée fidèle à Nagios car les motivations des forkers semblaient troubles : une part importante de ses membres est employée par une société directement concurrente de celle de l'auteur de Nagios. Les craintes d'un fork plus commercial qu'autre chose ont effrayé beaucoup d'éventuels contributeurs. De plus, les apports du fork se sont révélés limités sur le cœur de l'application, se limitant à une nouvelle interface et un export en base Oracle.

1.2. Un proof of concept innovant

1.2.1. Une identification des améliorations

Dans ce contexte agité, la communauté n'est pas restée inerte. Au sein de celle-ci, et après avoir écrit un ouvrage sur Nagios, votre serviteur a identifié les principaux problèmes de Nagios : si la gestion de configuration de Nagios est très puissante pour gérer les grands environnements, les performances et les possibilités d'architectures distribuées et hautement disponibles sont en retrait. Un serveur Nagios standard peut gérer environ 1000 hôtes en comptant 10 services par hôte. Si ses performances sont bonnes, il est relativement facile d'atteindre pour un grand environnement une telle configuration. Si la mise en place d'architectures distribuées est possible, elle n'est pas aisée, encore moins si l'on souhaite avoir en plus de la haute disponibilité, même en utilisant des outils tiers comme Centreon.

1.2.2. Les problèmes de performances

Le problème de performances est dû au mécanisme qu'utilise Nagios pour obtenir ses informations : il se forke afin que son fils lance lui-même une sonde (un simple script shell ou un exécutable) qui réalise la vérification. Le processus fils lit la sortie standard de la sonde et son code retour pour obtenir l'état de l'élément surveillé. Ce fils écrit ces résultats dans un fichier plat, qui sera lu et parsé par le démon principal. Une fois le fichier écrit, le fils meurt.

Dans ces deux dernières phrases réside le cœur du problème de performances de Nagios :

• Le parsage de fichiers plats est une opération extrêmement coûteuse.
• Pourquoi tuer le processus fils après son travail si c'est pour le relancer à la prochaine sonde ? Un fork est une opération coûteuse.

Le premier point se règle avec un export des données du processus fils vers une socket du processus maître. La communication étant directement en mémoire, et sans traitement de chaîne de caractères, le gain est substantiel.

Le second est conceptuellement simple également : le démon possède un pool de processus qui écoutent ses ordres. Le nombre de forks est ainsi divisé de moitié.

1.2.3. Les problèmes des environnements distribués

Le problème des environnements distribués est bien plus complexe : Nagios dispose nativement d'une méthode pour mettre en place des environnements distribués hautement disponibles, mais elle a un impact très important sur les performances. Des solutions comme Centreon existent, mais ne gèrent que la partie distribuée, pas nécessairement la haute disponibilité.

Si les problèmes de performances sont dus à l'implémentation, ici c'est un problème d'architecture globale qui pose souci, c'est-à-dire un problème de conception, pas si simple à régler.

1.2.4. Le choix d'un nouveau langage

Les premières propositions d'améliorations n'ayant pas reçu de la part des développeurs principaux de Nagios un accueil chaleureux, votre cher serviteur se lance dans l'écriture d'un proof of concept. Le démon étant écrit en C, la mise en place de ses idées n'est pas aisée, même non fignolées. Les idées de base de Nagios sont quant à elles simples à implémenter. C'est pourquoi le proof of concept a été implémenté dans un langage plus souple : Python. Réimplémenter le cœur Nagios en Python et y ajouter de nouvelles idées était plus simple que de partir directement dans le code actuel, qui est constitué de gros fichiers .c avec des fonctions très longues. Le but initial était de tester les idées en Python puis les réimplémenter par la suite en C.

Python permet également une portabilité très aisée. Nagios fonctionne très bien pour les environnements de taille moyenne, c'est-à-dire entre 100 et 1000 serveurs. Ses performances et ses problèmes d'architectures sont un frein pour les environnements plus importants. Les petites entreprises ont un peu du mal à avoir un vrai service informatique, et notre cher système libre bien aimé n'est pas encore très répandu en leur sein. Une compatibilité avec le système de Redmond serait donc un plus non négligeable pour Nagios, ce qui est chose faite avec un proof of concept en Python.

Cette première étape s'est faite très rapidement : l'application des méthodes de data driven a permis d'obtenir un " cœur Nagios " en un nombre de lignes très faible, le tout en ayant une souplesse de développement très agréable.

Viennent ensuite les phases proprement dites d'étude et mise en place des pools de processus et l'architecture distribuée hautement disponible. C'est ce que nous allons voir de suite en commençant par la partie la plus structurante : l'architecture globale.

2. Un Nagios coupé en pièces : " The Unix way "

Afin de mieux comprendre l'architecture globale, suivons un peu le raisonnement qui lui a permis de voir le jour.

2.1. Les rôles de Nagios

Faisons un rapide rappel sur la vie d'un démon Nagios : il lit la configuration de l'administrateur dans un fichier plat, il ordonnance et lance régulièrement des sondes qui effectuent les vérifications. En cas de souci, il lance une commande pour notifier les utilisateurs de problèmes, le tout en exportant toutes ces données par un mécanisme de modules. Ces derniers remplissant le plus souvent une base de données accédée par la suite par une application web.