Salut Jean et merci de nous consacrer un peu de ton temps pour répondre à mes questions et à celles des lecteurs du blog.

On commence tout de suite !

—

Peux tu présenter Shinken en quelques lignes ?

Shinken est un outil de supervision, une implémentation de Nagios en Python ‘from scratch’ qui a pour objectifs principaux de simplifier la vie des administrateurs de grands parcs et de coller au mieux à l’évolution de l’IT des dix dernières années, et si possible préparer les dix prochaines…

Pourquoi t’es tu lancé dans une t’elle aventure ? Quelles sont tes sources de motivation ?

En fait Shinken est un incident industriel !

Il commence sa vie sans nom et peu de temps après la fin de l’écriture de mon livre “Nagios 3” (editions Eyrolles). Pour ce dernier, j’avais passé une bonne part de mes recherches sur les chapitres de performances et d’environnements distribués. Ceci m’avait permis de voir les limites de Nagios dans le domaine. Pour simplifier, Nagios était parfaitement adapté à un parc de taille moyenne (200 serveurs) mais commençait à avoir du mal au dessus de par son architecture « mono daemon » et quelques défauts d’implémentations. Il ne faut pas lui lancer la pierre non plus, sa conception remonte à plus de 10 ans pour justement régler la supervision d’un tel parc, et n’a gère évolué depuis.

Je me suis donc lancé dans un « proof of concept » qui tentait de corriger dans un premier temps les problèmes de performances. Ceux-ci étaient plutôt simple à analyser au final :

• Nagios fork() des fils qui vont lancer des sondes. Puis les fils meurent. C’est dommage de les faire mourir si c’est pour en relancer 10ms après. Un système de pool de processus à la Apache devrait faire l’affaire ici (facile à dire, mais une horreur à implémenter).
• Pendant une notification, le lancement d’un script de réaction ou l’envoi d’une donnée en base, Nagios coupe la supervision. Mis bout à bout, ça positionne un plafond très bas sur le nombre de sondes que l’on peux lancer.

Je suis un grand fan de Python, principalement pour sa syntaxe claire et son état d’esprit (lire le “zen of Python” pour plus d’info là dessus, ceci résume très bien le “Python”). Il y avait justement une librairie pour avoir des pool de processus, je me suis dit qu’un petit script qui vérifie que le concept de pool n’était pas aberrant, et que ceci me prendrait bien moins de temps que la même chose dans le code de Nagios qui n’est pas d’une toute première fraîcheur en terme de lisibilité, même pour du C, sur cette partie.

A l’époque, ce proof of concept n’avait pas pour objectif d’être publié. Mais je me suis rapidement retrouvé confronté à une surprise que je n’attendais pas : j’obtenais des performances excellentes, bien meilleures que ce que produisait Nagios. Piqué dans ma curiosité, j’ai donc voulu valider cela en mettant un peu les deux à égalité : en mettant les algorithmes d’ordonnancement et par implication la lecture de la configuration. Deux points qui allaient se révéler être les deux choses les plus complexes à coder dans ce projet.

Je me suis rendu compte de bug dans Nagios dans l’ordonnancement à ce moment là d’ailleurs (et qui est toujours présent d’ailleurs dans Nagios et Icinga) ce qui ne m’étonne gère quand je vois la taille réduite du code de Nagios sur cette partie, et ce que ceci m’a demandé en Python (5 fois plus de lignes de codes Python environs, et 1 mois entiers de prise de tête sur des algorithmes de calculs de date…). Au final, là encore, les performances étaient au rendez-vous.

Je décide donc de prévenir les auteurs de Nagios. Je n’ai pas eu de réponse de l’auteur principal, mais une un peu évasive et peu convaincue d’un des coauteurs. Je décide donc de continuer et tenter de régler les soucis d’architectures distribuées. J’ai donc commencé à concevoir ce qu’était pour moi l’architecture idéale. J’ai donc “découpé” mon daemon en plusieurs morceaux au fil du temps, l’architecture n’étant pas arrivé en ce qu’elle est du jour au lendemain 🙂

L’un de ces découpage permet LA fonctionnalité de Shinken à l’époque : le découpage intelligent de configuration pour la disperser suivant les “ressources” de supervision. Ceci a aussi donné le nom au projet, un Shinken étant un katana utilisé dans la guerre car il est le plus coupant (puis le nom sonnait bien 🙂 ). Je propose d’ailleurs au passage cet algorithme de découpage à d’autres projets, mais il ne les intéresse pas.

Je publie de code pour demander des avis et j’ai ma première contribution d’un autre auteur de livre Nagios, un allemand nommé Gerhard Lausser , qui deviens co-leader naturel du projet de part sa forte implication. Là arrive un dilemme : notre outil fonctionne très bien, gère 90% du boulot de Nagios, est performant et codé de manière très modulaire. Mais backporter le code en C prendrait un temps monstrueux, surtout quand on regarde le peux de temps de développement alloué au core Nagios par ses auteurs déjà à l’époque. Je demande ainsi s’il serait envisageable d’avoir une branche “Nagios 4”” qui permettrait à notre code de mûrir et aux auteurs de prendre la main et faire en sorte d’une migration entre l’ancienne implémentation et la nouvelle se fasse e la manière la plus douce possible, même si elle doit prendre 2 ou 3 ans. Pas de réponses, donc je décide de monter d’un niveau et je fais la même proposition sur la mailing list Nagios-devel. Là, toujours pas de réponse de la part de l’auteur de Nagios, mais un échange avec un des co-auteur (le même que la première fois, qui est une personne bien plus ouverte que ses collègues au final) qui tourne malheureusement au troll sur les langages car il ne voyait pas à l’époque d’un bon oeil le Python, comme bon nombres d’autres codeurs C.

N’arrivant pas à obtenir une réponse de l’auteur principal (que j’attends toujours, enfin une vraie, pas un FUD sur la licence utilisée…), et n’arrivant pas à convaincre du bien fondé de cette branche et de ce code, je décide de monter le projet Shinken comme indépendant de son grand frère. Le drôle de fork est fait, un peu à contre coeur à l’époque.

Mes sources de motivations étaient au tout début l’amusement et les défis techniques (je suis particulièrement fier du calcul de la date de checks pour tous les cas de timeperiod par exemple 🙂 ). Puis quand c’est devenu plus sérieux et que ça pouvait régler mes soucis au travail (je suis admin d’un parc de 300 serveurs dispersés sur 50 filiales de par le monde environs) je me suis dit que ça pouvait intéresser d’autres personnes, ce qui fût réellement le cas :).

Désormais je crois plus que jamais à ce projet, et j’aimerai pourquoi pas qu’il prenne un part plus importante dans mon activité professionnelle, comme pour des activités de consulting ou de formations par exemple à moyen terme (étant un heureux papa de deux petits bouts je ne peux me permettre de me lancer à cours terme dans une telle activité).

Développes tu Shinken seul ? As tu des contributeurs réguliers ?

Je suis le responsable d’une majorité de lignes de codes, et donc de bugs en effet. Mais je ne suis pas seul heureusement. Côté codeurs, Gerhard qui fût l’un des premiers contributeurs externes est désormais co-leader du projet et code régulièrement. Il est même maître sur certains modules importants comme celui qui permet à Thruk ou PNP (métrologique) d’obtenir leurs informations. Nous avons également eu le soutient d’un autre codeur allemand qui papillonne d’un projet à un autre, mais qui nous a bien aidé à nettoyer le code à une époque, ainsi qu’un autre codeur qui est un spécialiste du refactoring/nettoyage et de la recherche de bugs (salut Greg) 🙂 Nous avons également l’aide ces derniers temps d’un codeur d’UI, nommé Andreas, qui nous aide grandement sur ce nouveau domaine auquel nous ne sommes pas trop habitués 🙂

Mais les codeurs ne font pas tout, loin de là. Quelques personnes nous aide sur les forums pour répondre aux utilisateurs, écrire/corriger la doc (coucou Seb, Denis et Remi 🙂 ), tester de nouvelles fonctionnalités, dessiner le logo (salut Romu), faire des packages pour les distributions principales ou écrire des scripts d’installations ;). Ceci nous aide encore plus qu’un patch car se sont des tâches très ingrates du point de vue “codeur”, mais qui est pourtant l’un des aspect les plus cruciaux pour la réussite d’un projet! Je tiens donc à les remercier du font du coeur, car un projet c’est avant tout une communauté avant d’être des lignes de codes. Ils sont la vraie force de ce projet qui tente d’être le plus ouvert possible.

Quels sont pour toi les trois principaux points forts de Shinken par rapport à Nagios Core ?

Pas simple de répondre à cette question… On pourrait s’attendre à ce que je dise son architecture distribué, mais en fait ceci n’arrive qu’en 4ième position (même si pour certains confrontés à des soucis de performances il va naturellement remonté en première ligne dans leur cas).

Dans l’ordre :

1. mise en avant du trio : corrélation + règles business + notion d’importance “business” qui simplifie grandement la vie des administrateurs
2. le fait qu’il tourne sous Windows (et Android, mais j’ai encore du mal à trouver un vrai usage pour ce dernier 🙂 )
3. ouverture du projet (j’ouvre sans trop poser de questions le temps que la personne veux aider) 

Le premier permet aux administrateurs d’un grand parc de se concentrer sur ce qui est “important”. Hors à notre époque de ressources humaines limitées, c’est plus que nécessaire.

Le second est souvent sous estimé, mais il est pourtant crucial dans le futur succès du projet. Nous avons vu que Nagios était orienté pour les infra de taille moyenne. Or Shinken lui couvre tout le spectre : moyen; haut avec le distribué mais également tout petit parc qui n’ont souvent pas d’admin Linux sous la main et seulement un serveur Windows à disposition.

Le dernier est tout simplement naturel pour moi, je ne saurai fonctionner autrement, mais le succès d’un projet passe par son ouverture. Il n’y a qu’a voir une preuve en regardant le déclin de Nagios : c’est plus un problème humain d’un projet qui n’avance plus dans son ensemble que technique qui est en est la cause.

Et les trois points faibles ?

1. Le relatif manque de grosses productions tournant avec Shinken. Ce n’est pas étonnant vu que jusqu’à maintenant il était vu comme jeune, et mis à part l’aspect distribué n’apportait pas forcément beaucoup à Nagios (ce qui est loin d’être le cas 🙂 ). Son image ne justifiait pas encore une migration d’un des élément central de son IT du point de vue infra. Le manque de support d’entreprise fait parti de ce point. Il fragilise encore son image (“fait dans un garage”, alors que non, c’est “fait dans un bureau” 🙂 ) et limite fortement les conférences que l’on peux donner pour évangéliser ce projet. Heureusement, c’est un point qui s’améliore avec le temps 🙂
2. Pas assez de tutoriaux “près à consommer” sur ce qu’apporte Shinken par rapport à Nagios.
3. Il n’a pas sa propre UI, ce qui impacte fortement sa visibilité quoi qu’on en pense.

Quels sont les raisons que tu peux mettre en avant pour convaincre une DSI de changer de solution de supervision et de se tourner vers Shinken ? (question de Guillaume Reynaud du blog Quick Tutoriel)

Un outil de supervision est là pour aider les admis à garder les services pour les utilisateurs en état de fonctionnement. Dis comme ça c’est simple, mais en fait si c’était simple à atteindre il y a 10ans (quelques dizaines de serveurs tout au plus, des services infra qui avait une vue “pure IT” – non business – et des services rarement en cluster) avec des outils comme Nagios n’est plus possible efficacement.

Un service qui tombe est désormais directement converti en monnaie sonnante et trébuchante par le directeur financier. Or nous avons désormais une vue plus “business” qu’IT, des parcs de plus en plus large, de nombreuses couches d’abstractions (qui a dit virtualisation?), multiplication des serveurs et des services et des contracts de services sur la tête (arriver à ce moment là de la conversation, le DSI devrait être plus réceptif déjà, car ce sont des soucis qu’il a tous les jours).

Shinken est justement pensé pour cela : monté en charge sans soucis, notion dans le core de la criticité d’une application, de la notion de cluster, de la corrélation et ainsi arriver à une chose si simple à expliquer, mais si dure à obtenir : faire en sorte que les admins puissent se concentrer en priorité sur les problèmes sources qui impactent des services importants pour le business. Nagios se “vends” lui même comme un outil de supervision “IT”. Ceci n’est plus suffisant. Faut dépasser la vision pure IT, et passer au niveau “business”, car c’est ça que l’on attend les services informatiques désormais. Leur solution de supervision doit suivre logiquement. (ici, le DSI doit être plus réceptif, donc l’achever avec les gains apportés par la métrologie, sortir une carte ou deux de Nagvis, et c’est gagné).

En réaction à l’orientation très fermée du développement de Nagios Core, on voit fleurir de nombreux forks. Tu arrives donc dans un marché très concurrentiel…

Oh que oui ! D’un certain côté tant mieux, ceci laisse le choix à l’utilisateur, mais le risque réside dans la fragmentation de la communauté en plusieures bien moins fortes. Ceci est une part du dilemme qui m’a animé avant de publier Shinken en tant que projet à part entière. Mais j’ai pensé que même si le projet n’arrivait pas à s’imposer, au moins il aurait été un « proof of concept » géant sur où il fallait aller dans la supervision à mes yeux.

Au final, il semble bien prendre et j’en suis très heureux. On voit encore fleurir les forks, come celui dernièrement de Centreon, mais je pense que l’écosystème va jouer son rôle, et va sélectionner les meilleurs projets. Qui sait, peux être que Nagios sortira grand vainqueur (même si j’en doute fortement)? Qu’Icinga amènera de vraies avancées, que quelqu’un arrivera à comprendre l’architecture de Merlin ou que le couple Centreon-engine/Centreon-Broker raviera cette première place?

Un risque fort réside dans le fait d’avoir des coeurs “presques compatibles”, un peu comme un HTML à la mode IE6, le tout poussé par des besoins business des différents intervenants qui n’auraient plus d’intérêt à coopérer. Il ne faut pas oublier que des solution comme Zabbix montent aussi au créneau et réclame cette première place d’outil de supervision du monde Open Source. Bien malin sera celui qui saura ce que va donner cet Opéra joué par des musiciens qui on leur propre partition à jouer. Espérons seulement qu’un chef d’orchestre se révèle et que la musique reprenne une certaine harmonie. Ce vote se faisant par les utilisateurs, il sera sage et justifié. C’est après tout l’un des principal avantage de notre écosystème “Open Source” tant concurrentiel et sans merci !

Pour un utilisateur connaissant bien Nagios, quel est l’investissement en temps pour switcher vers  Shinken ?

Pas énorme. Disons une matinée pour l’installation propre et comprendre le fonctionnement global. Puis une après-midi pour mettre en place son premier environnement distribué/hautement disponible complet en suivant le tutorial. Beaucoup d’efforts on étés fait pour que la migration se passe de la manière la plus douce possible, comme la génération automatique de certains modules par exemple. En ce qui concerne les fonctionnalités avancées comme les règles business et les notion d’impact business, on rajoutera une matinée supplémentaire, pas tant dans l’écriture, mais surtout dans ce que ceci implique en matière de supervision 🙂

Une petite remarque par contre : pour un utilisateur ne connaissant pas Nagios, il y a toujours un certain temps d’adaptation qui ne diffère pas trop de Nagios. Comme par exemple comprendre les concepts de supervision (que beaucoup passent bien trop rapidement à mon goût) et les différentes sondes. Vous pouvez rajouter tous les outils de découverte que vous voulez (comme celui dans Shinken 🙂 ), ces phases seront toujours importantes pour pleinement utiliser l’outil à sa juste valeur. Un outil de supervision mal maîtrise fait plus de mal que de bien. Cette phase est donc cruciale et mérite un certain investissement qui sera rentabilisé par centuples plus tard 🙂

Quels sont les principaux avantages de Shinken par rapport à une solution comme Centreon ? (question de Guillaume Reynaud du blog Quick Tutoriel)

Exactement les mêmes que par rapport à Nagios, Centreon apportant une UI, certe pratique, mais qui ne révolutionne pas la conception de la supervision. Shinken avec son système avancé de corrélation, règles business et notion d’importance si (enfin il essaie au moins). Ce sont des choses qui aident les admins et leurs chefs dans leur vie de tous les jours, bien plus qu’un nouveau style CSS. Ceci sera vu un peu plus loin d’ailleurs.

Il faut voir par contre que Centreon est une solution complète, alors que Shinken est un outil, une brique de base. Centreon offre par exemple une gestion très pratique des traps SNMP ou son propre service de reporting.

Heureusement, les deux ne sont pas antinomiques, et il est possible, mais non trivial, de les faire dialoguer. C’est d’ailleurs ce que j’ai encore en production. Ceci grèvera cependant les possibilités de Shinken, comme par exemple la définition des règles business ou encore les notions d’importance business (des patchs “hacks” sont en cours pour Centreon 2.4). Mais qui sait, si la demande envers le projet Centreon se fait pressante, on peux espérer un support plus important de Shinken dans ce dernier, même si il faut bien le reconnaître que l’arrivée récente de centreon-engine ne va pas dans ce sens.

De part son architecture, Shinken offre nativement une supervision distribuée hautement disponible (contrairement à d’autres outils de supervision open-source),penses tu que cette fonctionnalité fait de shinken un outil a n’utiliser que sur des grandes architectures de système d’information ? (question d’Anthony Paradis modo du forum de Monitoring-FR)

Je ne pense pas, car justement je ne mettrait pas l’architecture dans la top 3 de ses avantages.

Une petit société avec 10 serveurs sous Windows sera bien contente d’avoir son système de supervision sur cette même plate forme, et mettre facilement un backup en place sur un second.

Une de taille moyenne sera contente d’enlever un serveur physique Nagios et mettre une machine virtuelle Shinken à la place grâce au gain de performances. Ils seront content également d’avoir un outil qui fait la liaison de dépendance automatique des VM et des hôtes pour eux, avec le support des migrations de machines virtuelles d’un hôte à un autre sans avoir à toucher quoi que ce soit.

Passons à l’actualité, la version (0.8 aka Guilty Gecko) sort dans quelques semaines. Mise à part les classiques corrections de bugs, quelles sont les nouvelles fonctions ?

Comme vu dans la dernière release, les aspects d’architectures sont finis, donc pas de grosse annonce de ce côté là. Cette version sera d’ailleurs la 0.8 et non la 0.7 car Shinken est déjà en production à plusieurs endroit sans soucis, donc il est temps d’accélérer un peu le mouvement vers la 1.0 qui devrait être pour la fin de l’année si tout va bien, et qui sera un signal fort sur la stabilité du projet.

Cette 0.8 aura donc principalement :

• un outil CLI pour interroger/commande directement le daemon principal
• des améliorations des “business rules” qui gèrent mieux maintenant les états dégradés
• une reprise en main du module GLPI par les auteurs de ce derniers, donc une bien meilleure intégration entre les deux outils
• un module “générique” de chargement depuis une base mysql (pour gérer les X outils de CMDB par exemple)
• une possibilité de définir des modulation de la criticité business d’un élément suivant la période. Par exemple un serveur de paye est critique 3 ou 4 jours par mois, mais est “normal” le reste du temps.
• un module thrift
• mais la grosse partie qui nous a occupé une grande partie de l’été et qui va nous occuper encore un moment : l’arrivée d’une interface utilisateur dédiée !

A cours terme, quelles orientations penses tu donner à Shinken ?

Je pense qu’il faut dépasser la vision d’outil et se diriger vers la solution de supervision.

Combien d’administrateurs ont encore le temps de devenir des experts dans la supervision et monter leur propre solution à base de Shinken ou Nagios à la main ? Combien d’administrateurs sous Windows attendent un outil de supervision simple à mettre en place et sans prix exorbitant de licences ?

Les administrateurs d’aujourd’hui ne sont plus des barbus qui recompilent tous leurs outils, même si ceci m’attriste un peu il faut bien l’avouer (j’ai une capillarité limitée mais je suis un barbu dans l’âme 🙂 ). Mais c’est un fait, désormais nous mettons en place des solutions, non plus des outils. Nous devons nous concentrer sur les services rendus aux utilisateurs et arrêter de ne penser qu’à l’IT ‘infra’. On ne fait plus une infra avec des briques qui sont de simples outils, mais avec des briques qui sont elles mêmes des solutions.

Ce n’est pas pour rien que Zabbix a un succès grandissant : c’est rapide à mettre en place et l’utilisateur n’est pas perdu. Je ne suis pas un fan du fonctionnement “supervision” de Zabbix que je ne trouve pas assez flexible pour les modèles de corrélations (et donc source de tempêtes d’alertes, qui est l’ennemi juré en supervision), mais il a une grande qualité que l’on ne peux pas lui renier : on le met en place rapidement et “ça marche”.

Ceci n’empêchera pas Shinken de pouvoir être utilisé comme une simple brique d’une autre solution plus grosse de type Centreon, il est hors de question de casser ce côté modulaire et le core actuel continuera d’être utilisable seul bien évidement.

On reproche souvent à Nagios le manque d’ergonomie de son interface utilisateur (UI) basée sur des standards/technologies Web dépassés. Actuellement, Shinken utilise des UI externes (comme Thruk) qui copient plus ou moins cette dernière. A ton avis quelle est l’interface graphique permettant d’exploiter au mieux Shinken? (question de David Paugam du Groupe Asten)

Il est vrai que les technologies de l’UI de Nagios sont des hérésies à l’heure actuelle (CGI en C qui parse un gros fichier plat, tout ce qu’il ne faut pas en gros). Mais ce qui m’embête bien plus c’est son ergonomie et surtout la vision de la supervision qu’elle propose et le peux de service qu’elle rends à l’utilisateur au final. On mettrait un convertisseur XSL vers HTML en partant du fichier de status que l’on obtiendrait quelque chose de similaire.

Et ceci est le même constat pour les autres interfaces de visualisation (Thruk, Ninja, Centreon, Icinga 1.0 ou 2.0 ou alors MK/Multisite). Si on prends un peu de recul, que l’on enlève les jolis styles CSS et les bouts de javascript de certaines qu’est ce qu’elles proposent ?

Et bien les mêmes vues ou presque. Elles nous proposent toutes des vues ‘IT mode infra’ à la sauce CGI. On a donc le droit à une liste longue comme le bras d’éléments orange ou rouge sans aucun ordre (il est inutile de montrer du vert à un admin, le vert c’est réservé aux chefs 🙂 ). Or à l’heure actuelle on a pour un même service rendu aux utilisateurs au moins 3 environnements : DEV, QUALIF et PROD. Or lequel est important ? PROD. Le reste c’est à traiter après les autres.

De même, un service comme un ERP est plus important qu’un outil pour emprunter des DVD au CE. Il est donc crucial que l’administrateur se focalise en priorité sur ce qui est important pour le business, ca c’est ça qui le paye à la fin du mois !

Autre chose, nous avons maintenant des services qui se composent de clusters qui reposent sur des infras à X niveaux (au minimum Web frontaux, BDD, répartiteurs Web, serveur disque, serveurs ESX de virtualisation, baie de disque et toute la partie réseaux ethernet ou SAN bien entendu). Si un élément “pur infra” comme un switch tombe, tout le reste part avec lui, sur tous les services, sur tous les environnements. Vous allez donc avoir une part importante de votre infra en rouge vive sur votre console. Or une seule info importe pour l’administrateur : quel est l’élément source qui m’a causé tout ça ? Le reste est bon à mettre à la poubelle, c’est l’unique info qui importe à l’admin. Son chef lui voudra les mêmes infos mais dans un sens de recherche opposé : quels services sont tombés et pourquoi ?

Or, les outils ci-dessus n’aident en rien à cela. Il n’y a pas de priorisation des éléments, pas de visualisation de la corrélation faite au seins de l’outil, sous forme de graph ou autre. Et ceci en mettant de côté les vues “opposées” des admins et des responsables d’infra qui ne peuvent pas avoir les mêmes vues, car leurs manière de voir les choses est diamétralement opposée !

La seule UI qui a innovée ces dix dernières années dans ce sens c’est NagVis ! J’ai intégré quelques vues en ce sens dans Thruk en début d’année, mais ça n’a pas trop pris et on reste toujours avec la même philosophie qu’il y a 10 ans, ce que ne cache pas l’auteur de Thruk. Il conviendra parfaitement aux administrateurs qui n’ont pas/(pas besoin d’) un point de vue “business”. Pour les petits sites, MK/Multisite est très “joli”, mais est très lié à l’agent check_mk, et peux être considéré comme une solution à part entière, mais sans la partie modulaire par contre.

Reste le problème de la configuration. Là Centreon se pose encore en grand maître des lieux, mais n’est pas adapté à Shinken et va fortement limité son intérêt. Les autres solutions graphiques de configuration souffrent du même problème actuellement, il n’y a donc pas de solution miracle malheureusement à l’heure actuelle…

Souhaites tu intégrer une UI propre à Shinken ?

La réponse est oui !

En fait, j’ai tenté ce que j’ai pu pour l’empêcher, mais le fait est là : la vision problème source/ impact / criticité du coeur de Shinken n’est pas encore prise en compte par les interfaces. Quand le coeur de Shinken n’était pas encore fini à mon goût, je ne voulais pas lancer un projet qui aurait canibalisé nos forces.

J’ai donc tenté de motiver le projet Thruk qui a bien accepté mes patchs malgré mon Perl catastrophique (en même temps ça reste du Perl, ça se trouve il est très beau pour du Perl…), mais l’interface reste à dominance “old school” car elle plait ainsi à beaucoup d’anciens utilisateurs de l’ancienne CGI.

L’auteur de MK/Multisite n’est pas des plus ouverts à mes idées et mes tentatives de présentations de ma vision de la supervision auprès de Centreon n’a pas eu beaucoup d’effet et n’a pas dû convaincre car désormais nous avons un fork de Nagios en plus 🙂

Je me trompe peux être, mais je suis convaincu que mettre en avant la corrélation, la priorisation et tout ce qui va avec la vision “business” facilitera grandement le travail des admins et des responsables d’infrastructure.

Mon objectif est d’arriver à une UI qui permettra de dire simplement à :

• un admin : cet élément d’infra (genre switch, car c’est bien connu c’est toujours le réseaux le responsable…) est un problème source qui engendre un fort impact négatif sur des services importants. Règle le. (donc il donne la TODO list aux admins)
• un responsable d’infra : voici la liste des services rendus aux utilisateurs, celui là à un soucis, et de telle importance et est impacté par le swtich X, mais est en cours de résolution par Y. (donc il donne sur qui taper aux chefs… na taper pas sur l’UI, de toute manière ils l’auraient fait!)

Avec de l’aide d’un designer web, nous nous sommes lancés dans des mockups d’interface qui ne ressemblent pas vraiment à ce qui existe actuellement, tant sur le fond (UI sans BDD ni requêtes, assez original non?) que surtout sur la forme qui se veut très “user-friendly”, avec très peu de vues, mais très étudiées et utiles (80% des utilisateurs restent toute leur vie dans 20% des pages, gagnons du temps, ne faisons que 20% des pages).

Un bon indicateur de succès sera si les utilisateurs considèrent cette interface comme le “gnome” des interfaces de visualisation de supervision, reléguant les autres aux rang de WindowMaker. Elle ne remplacera pas un Thruk ou un Centreon chez les plus barbus d’entre nous, les vrais qui tournent en gentoo, changent les options de compilation de GCC pour gagner 0.5% de perf et ne voient pas l’intérêt des tablettes graphiques dans le monde de demain… Mais j’arriverai à vivre avec ça 🙂

Cette UI intégrera t’elle un outil de génération de rapports dont les DSI sont très ( voir trop) friand ?

Pas dans un premier temps et ce pour trois raison :

• on doit déjà faire le reste de l’UI 🙂 Le reporting c’est la dernière étape, même si c’est celle qui fait “vendre” une solution à un DSI. Mais vu que l’on ne vends rien…
• j’espère bien que le projet Nareto va renaître de ses cendres pour le faire à notre place 🙂
• il faut définir le modèle de données pour cela (dit “en cube”). Étant également DBA à mes heures perdues, je n’arrête pas de pester auprès des devs qui font des requêtes de reporting sur une base qui n’est pas conçue pour ça, avec des schémas purement transactionnels non cubiques et qui me plombent mes (pauvres) serveurs. Hors de question de coder un outil de reporting qui va taper dans un schéma de supervision “temps réel” par exemple, ça serait une hérésie, même si c’est plus rapide à coder dans un premier temps évidement.

Et des fonctions d’édition en ligne des fichiers de configurations ?  (question de David Paugam du Groupe Asten)

Cela sera l’étape intermédiaire avant le reporting en effet, et devrait être consommatrice de temps. Mais je doute dans ce cas de l’édition “in line” en fichiers textes. Outils de configuration + fichiers plats ne font pas bon ménage à mon goût. Une “base” de configuration serait plus adaptée, mais je n’ai pas poussée la réflexion bien plus loin.

Sera t’elle compatible pour une utilisation mobile depuis les smartphones ou comptes tu faire développer des applications dédiées (iPhone et Android) ? (question de Nicolas Ledez du blog Le bazar de Nicolas)

Alors là c’est simple : j’ai une vision bien plus gentille avec les designers d’UI depuis que j’ai une tablette graphique et que j’ai regardé mon fils de 2ans l’essayer. Il l’utilise sans que je lui explique. Je me suis donc penché un peu plus sur ce domaine qui désormais me fascine, car l’ergonomie est quelque chose que j’avais en tête en pensant à celle de Shinken mais qui m’a permis d’avoir des exemples concrets de ce qu’il faut faire, et ne pas faire.

L’interface sera ainsi bien plus proche d’une interface “smartphone” que d’une UI classique d’un outil d’administration, ce qui explique pourquoi elle ne vas pas plaire à tout le monde également. Donc pas de soucis, les tablettes et smarphones sont prévus 🙂

D’un point de vue technique, je ne vois pas l’intérêt de l’application native quand on a toutes les possibilités d’HTML5 sous la main et que l’on n’a pas besoin de prendre en photo son utilisateur.

Il est donc à prévoir d’ailleurs une non-compatiblilité avec IE6 ou 7, et là clairement ils ne sont pas dans le cahier des charges. Je ne serai pas contre un patch (non intrusif…) qui permettrait de les supporter, mais ces navigateurs étant tellement mal faits et limitatifs dans l’interface qu’il serait non efficace de tenter de les gérer.

Quel logiciel de métrologie conseilles tu en parallèle de Shinken ?  (question de David Paugam du Groupe Asten)

PNP4 Nagios. C’est un très bon outil qui a d’ailleurs son propre module depuis Shinken. Celui de Centreon est pas trop mal non plus, mais est plus consommateur de perfs.

Je ne suis pas trop pour un Cacti en parallèle d’un outil de supervision, car on aura tendance à demander à ce dernier de rechercher l’information lui même (par exemple en SNMP) alors que l’on a déjà effectué une telle demande dans un agent de supervision. Ce n’est pas trop du point de vue charge machine ou réseaux que ceci m’embête, mais bien d’un point de vue conceptuel où on fait deux fois la même chose, et où l’admin va devoir gérer deux agents et configurations, ce qui est totalement injustifié quand on a un PNP qui peux faire tout aussi bien que Cacti par exemple.

Shinken est développé en langage Python. Quels sont pour toi les avantages de ce langage par rapport au langage C dont Nagios Core est issu ? Une vue extérieure pourrait penser que le Python est moins performant que C, surtout pour des applications proches des couches systèmes et réseaux.

J’avais le même a priori il y a quelques années. J’ai été élevé à l’assembleur et au C, avec de l’Emacs et du Makefile fait à la main (je n’ai pas tourné barbu pour rien hein…). Même si j’avais bien vu l’intérêt de l’orienté objet pour la création d’UI (modèle MVC + orienté objet = moins de code, moins de bugs), mais pas dans le domaine très “noble” des daemons serveurs.

J’ai aussi été bassiné pendant de longues années par des algorithmes au nom impossible à retenir (Disjtra, je suis désolé, j’adore ton algo, mais alors ton nom….) mais qui faisaient toute la différence dans ce que le développeur mettait comme “intelligence” dans son code (bien plus que de joli commentaires ou des lignes de 80 caractères au maximum). Les algos allant bien évidement avec la recherche de leur efficacité en O(1) si possible, O(n) dans de nombreux cas, et O(n*…*n) si on s’y était mal pris.

Je n’avais jamais fait le lien entre les deux. Pour moi la performance allait tout d’abord au langage choisi (plus c’est bas niveau, plus c’est rapide) puis le reste. Or c’est totalement faux, et c’est en devenant admin et étant confronté à des codes/requêtes testé(e)s sur de petits cas de tests mais qui se révélaient désastreux sur un cas réel (genre testé en 0.1s avec une table à 100 éléments, et qui prends 8h sur une table avec 10000). Le tout sur des serveurs plutôt “costaux”.

Et là le langage (haut niveau) n’y était pour rien, on aurait pu faire le même en C que ça aurait pris aussi 8h (aller, 7h45, toujours aussi insupportable pour un utilisateur et l’administrateur du pauvre serveur).

Non, la performance vient en premier lieu des algorithmes, pas du code. Mieux vaut un bon algo avec un langage lent qu’un mauvais avec de l’assembleur bien codé mais un algo mal pensé.

Or si on y pense, un outil de supervision a besoin de deux choses :

• calculer une date de prochain check
• lancer la sonde de supervision, donc un fork()

 Le reste, ce sont des problèmes de haut niveau.

 Si on refait la même chose que Shinken mais en C, on gagnera en performance sans aucun doute. Mais ceci va tout simplement demander un temps astronomique avec les ressources des projets Nagios ou Shinken, et on perdrait en modularité de code (on ne peux architecturer aussi simplement et rapidement un code en C qu’un code en Python, aussi bon codeur que l’on soit).

On peux se dire que plus on se rapproche du système, moins l’importance des algos est importante, un fork() est un fork() après tout. Mais en fait non, la manière dont on fait les appels bas niveau à un impact direct sur les performances. Par exemple, Nagios passe le plus clair de son temps à faire des choses “de la mauvaise manière” :

• lancer des fils, donc des forks() pour ensuite les tuer. Le pauvre système à un mal fou à suivre, un fork() c’est très lourd!
• écrire des fichiers plats qui seront lu par le processus principal pour obtenir les informations. C’est bien rigolo, mais le VFS du noyau n’est pas ce qui est le plus rapide au monde, si on pouvait directement parler de mémoire à mémoire avec une socket, on gagnerait un temps énorme!

 Ca tombe bien, ceci a été crié depuis 2 ans maintenant, mais les projets Nagios et centreon-engine s’y attellent aujourd’hui. Je leur souhaite bien du courage. Personnellement j’ai préféré faire confiance aux codeurs de Python qui sont sûrement bien plus doués que moi pour gérer ces problèmes bas niveaux de communication inter-process. Ceci permet par exemple de passer plus de temps sur des aspects importants pour la supervision comme les notions d’importances ou de corrélations. Ces dernières ne demandent pas de puissance de calcul particulières, mais résolvent les problèmes de bon nombres d’administrateurs dans la vie de tous les jours, les problèmes de performances étant désormais oublié 🙂

Le fait de disposer d’un coeur développé en Python permet d’installer un serveur Shinken sur une machine Windows. Conseilles tu cette architecture ? Quelles sont les éventuelles limitations ?

Oui, et vous remarquez que j’ai même mis ceci dans le TOP3 des features! Shinken est conçu/testé pour deux environnements : Linux et Windows.

Le Windows sera moins performant, non par ce qu’il est codé avec les pieds, mais bien parce qu’il a des fork() plus lent (le modèle de sécurité est plus évolué sous Windows, et implique donc des calculs bien supérieurs à ce que l’on fait sous Linux). Je n’ai pas de chiffres, mais on peux s’attendre à diviser les perfs par deux sur le lancement des sondes.

Je conseille donc pour les gros parcs d’avoir si possible des pollers en Linux pour prendre la majorité de la charge (test réseaux, tests des agents, etc). Mais un poller sous Windows peut avoir un gros intérêt également :

• on peux le lancer avec un compte de domaine, donc potentiellement lancer directement des requêtes WMI sur les autres Windows. Et avec ça, on fait presque tout sous Windows!
• pour les petits sites qui n’ont pas d’admin Linux, ils n’ont de toute manière pas le choix 🙂

Si c’est un reactionner, on peux restarter des services à distances, pratique…

Outre les problèmes de performances, il y a quelques limitations :

• il n’y a pas de pipe nommé (nagios.cmd) sous Windows facilement acessible, donc il faut passer par un module externe pour la supervision passive (LiveStatus par exemple)
• il y a beaucoup moins de sondes disponibles sous Windows. Très peu de packs tout en uns sont fait.
• Aucune UI n’est faite pour !

Le premier est facilement contournable, surtout avec l’arrivée de la commande CLI dans la nouvelle version.

Le second est plus problématique, et il faudra qu’on s’y attelle sérieusement 🙂

Le dernier sera réglé avec l’UI de Shinken.

Quel environnement de développement (IDE, outil de debug, gestionnaire de version, tracking…) utilises tu pour le développement de Shinken?

Comme tout le monde, ce avec quoi j’ai appris à l’école:

• IDE : Emacs, avec un module pour pylint et coverage
• Debug : print, mais surtout la méthode de développement dirigée par les tests
• Gestionnaire de version : GIT (le projet est hébergé sur GitHub)
• Tracking : trac sur sourceforge (historique), mais aussi GitHub
• Hudson : pour les tests de non régressions
• Web : WordPress, car c’est tout simplement génial à administrer et mettre à jour 🙂

Si des lecteurs sont intéressés pour s’investir dans le développement de Shinken. Quels sont les besoins les plus importants ?

Un peu de tout en fait !

Des codeurs qui ont besoin d’un certain besoin ou veulent s’amuser en Python, des webdesigners qui sont tentés par la nouvelle UI qui se lâche dans ce domaine (on n’a pas peur de l’HTML 5 et du CSS3 on va dire 🙂 ), des rédacteurs de tutos sur le wiki, des modérateurs sur le forum, quelqu’un qui envoie un petit “merci” par mail (ça aide énormément à maintenir le rythme!) ou alors tout simplement un admin qui tente de l’installer, remonte un bug où nous dit qu’il est en production.

Toute personne qui veux aider est la bienvenue, il n’y a pas de “partie réservée” dans ce projet, mis à part le choix du nom (débile en général) de version qui est mon petit coin à moi 🙂

En discutant personnellement avec des responsables informatiques, les principales craintes qu’ils énoncent à l’utilisation de Shinken en environnement de production sont la pérennité de l’équipe de développement (et donc indirectement du produit) et le support technique. Comment les rassurer sur ces points ?

Ce sont des considérations justes et logiques. J’aurai la même en tant qu’admin. Pour l’instant la communauté est en train de monter, les tests se multiplient et le nombres de contributeurs augmente. Mais il n’y a pas encore de SSLL qui le proposent en formation ou intégration (ça arrive). J’ai par exemple déposé le nom Shinken à l’internationnal par exemple,si ceci peux démontrer à quel point j’y crois (surtout quand on connaît mon aversion pour les trucs administratifs, et là j’ai été servi..). Donc je pense que Shinken arrivera dans un premier temps par la petite porte, comme l’a fait Nagios avant lui d’ailleurs.

As tu des références d’entreprises utilisant Shinken pour la supervision de leur système d’information ?

Il y a pour ceux où je suis au courant déjà Lectra, société où je travaille (300 serveurs, 7k services), une section de Sogeti sur Bordeaux (12K services), l’hébergeur Sobio (100 serveurs) et un conseil général.

Si d’ailleurs certains l’ont mis en place, nous sommes en phase de recherche de références !

Est il intéressant de déployer Shinken sur des parcs informatiques de petite et moyenne taille ?  (question d’Anthony Paradis modo du forum de Monitoring-FR)

Oui pour les petits, car ils sont souvent sous Windows et là c’est tout simplement leur seule solution “libre” de ce calibre à ma connaissance 😉

Pour les moyens qui sont en pleine virtualisation, le module de création automatique des liens de dépendances entre l’hôte et les VM peux être utile par exemple, et montrer un peu à un DSI l’intérêt de ce genre de projet. On peux également le voir comme un “nagios like” et donc utiliser les mêmes arguments (nombreux!) de ce dernier, mis à part l’importance de la communauté de ce dernier (mais il a désormais un avenir incertain sous cette forme, il devient donc plus dur de le “vendre”).

Il offre aussi des simplications importantes dans la configuration de Nagios, donc un bac°5 n’est pas forcément nécessaire pour mettre en place des escalades de notification à 2h et 4h sur une partie du parc par exemple. Cela prends plutôt 5 mins désormais 🙂

Pour finir, comment vois tu Shinken dans 5 ans ce qui est une éternité pour un logiciel informatique ? (question de Romain de Woueb.net)

Comme une solution à part entière, c’est à dire :

• un coeur performant, scalable et qui permet une corrélation avancée : OK, pas la peine d’attendre 5 ans 🙂
• un environnement de sondes énorme : OK pour Linux, à faire pour Windows, même si ce dernier, un check_windows réglerait déjà 90% du besoin de cet environnement (j’ai un poc en alpha dans les cartons 🙂 ).
• une UI de visualisation qui permettra à ses utilisateurs d’avoir les mêmes infos qu’un NagVis mais en plus “dynamique”
• une UI de configuration, très axées découverte et “auto” configuration
• un agent qui permet la découverte sur les éléments distants “à la check_mk” (ce dernier n’est malheureusement pas utilisable sur un environnement distribués, et l’auteur n’est pas pour changer cela à mon grand regret…)? (on avait dit 5ans hein 🙂 )
• un module de reporting (si Nareto ne revient pas)

Mais même si nous n’atteignons jamais ça, déjà avoir une grosse communauté et savoir que ce projet a aidé bon nombres d’administrateurs dans leur vie de tous les jours et à leur permettre de se consacrer à des tâches plus intéressantes que courir partout car ils n’arrivent pas à trouver l’élément qui a fait tout tomber, ça serait déjà un objectif tout à fait satisfaisant pour moi.

Le reste (passer devant Nagios, contenir Zabbix, convaincre les gourous de la supervision du bien fondé de ma vision, avoir le temps de finir les deux Final Fantasy que j’ai de retards, …) ce n’est que du bonus. Si de plus ça peux devenir mon gagne pain, ça me permettrait à justifier à ma femme tout ce temps où je passe dessus 🙂

Un petit mot pour finir ?

Comme mot de fin, j’aimerai remercier Nicolas pour cette interview ainsi que tous ceux qui ont posés des questions et qui portent un intérêt à ce projet :).

—

Nous arrivons à la fin de cet interview. Encore merci à Jean pour sa disponibilité et aux lecteurs qui ont posés de questions intéressantes qui montrent l’intérêt du public pour cette solution de supervision.

Vous pouvez bien sûr poser des questions complémentaire à Jean en utilisant le formulaire en bas de cette page.

Quelques liens relatifs à Shinken:

• Le site officiel de Shinken
• Le forum de Shinken
• La mailing list de Shinken pour les développeurs
• Le compte Twitter de Jean Gabes (@naparuba)
• Le blog de Jean Gabes