La supervision pilotée par le comportement
J’ai découvert avec cucumber-nagios bien plus qu’un simple plugin supplémentaire pour Nagios. Celui-ci prétend en effet nous amener vers le nirvana de ce que les anglophones appellent « Behaviour Driven Infrastructure » que nous pouvons traduire approximativement par Infrastructure piloté par le comportement. Que cache ce terme, en quoi peux-t’il s’appliquer au domaine de la supervision sont quelques unes des questions auxquelles nous allons tenter d’apporter sinon des réponses; au moins des éclaircissements.
La représentation traditionnelle d’un SI en supervision
Aujourd’hui, tous les systèmes de supervision représentent un système de supervision comme un ensemble de serveurs sur lesquels tournent des services. C’est une représentation technique des choses qui associe la notion de santé d’une système d’informations …. Beaucoup de clients aujourd’hui souhaitent vérifier le matériel, les processus,
Cette représentation traditionnelle d’un système d’informations, au moins dans le domaine de la supervision, semble de plus en plus poussée vers l’obsolescence dû à quelques évolutions majeures intervenues dans nos SI depuis 5 ans.
Quelques problèmes
- La redondance et la haute disponibilité qui rendent la représentation traditionnelle plus lourde à modéliser.
- La virtualisation massive des systèmes d’informations des entreprises, que ce soit avec Xen, VMware, KVM… amenant une distinction supplémentaire entre serveurs physiques et serveurs virtuels dépendant d’un serveur physique.
- Le Cloud qui est en train de faire exploser la notion même de matériel puisque vous ne savez plus à un instant temps « T » quels sont les composants de votre infrastructure qui sont sollicités.
Du coup, les systèmes de supervision actuels souffrent de plus en plus pour représenter la complexité des interactions entre serveurs actifs, non actifs, physiques, virtuels… Les conséquences en exploitation sont nombreuses avec des difficultés croissantes à pouvoir décider ce qui ressort d’un problème, d’un incident, ce qui devrait être notifié, escaladé. Certains nous promettent le nirvana (encore 😉 en portant la notion de corrélation à un niveau jamais atteint et difficilement exploitable. Ils nous fournissent des moteurs de corrélation de plus en plus complexe à paramétrer et configurer. Impasse ?
La représentation comportementale de votre SI
Les auteurs de Cucumber qui est à la base du plugin préfère ouvrir une autre voie en partant du principe qu’un système doit se comporter d’une certaine façon pour rendre le service attendu.
Quelques bénéfices
- Vous n’avez plus à modifier les paramètres de chaque sonde à chaque modification de votre infra. Le comportement observé devant en toute logique resté le même.
- Vous êtes directement orienté vers l’impact métier du problème.
- Vous n’êtes pas alerté au moindre problème, seulement pour ceux impactant l’activité ou le service rendu.
- Vous prenez en compte l’expérience utilisateur. C’est bien là le principal non ?
Les outils pour le faire
La trousse à outils pour arriver à ce type de supervision est train de se mettre en place au niveau du monde de la supervision Open Source et nous vous avons déjà présenté ici Watir et Cucumber, pierres angulaires de ce type de supervision à venir… ou non
Alors à vous de me dire si ces idées sont intéressantes et/ou se contentent de suivre une nouvelle mode comme nous en connaissons régulièrement. À vos commentaires 🙂
11 Comments
Leave a Comment
Vous devez être connecté pour publier un commentaire.
Licence
Sauf mention spéciale, le contenu de ce site est distribué sous licence Creative Commons version BY 3.0.
Je crois que tu es carrément dans le vrai. Les clients nous demande plus aujourd’hui une supervision fonctionnelle et applicative que simplement technique.
Je rajouterai aussi que la notion de SLA (niveau de service) cher à ITIL oblige aussi à mesurer exactement le ressenti utilisateur, plus que l’indicateur technique pur.
Que dire sinon : oh que oui!
Je pense qu’il faut les deux, la vue business et technique. Cette dernière est une brique utile pour la première qui doit être la maitresse des alertes. Un « problème » sur une application utilisateur ou un moindre ressenti doit être corrélé pour aider à trouver la source du point de vue infra.
La gestion des dépendances et la corrélation est donc obligatoire actuellement, et encore plus dans l’avenir 🙂
Oui, bien sûr il faut les deux mais comme nous parlons beaucoup, voir exclusivement de supervision technique, il était bon de mettre un peu la lumière sur cette autre « forme » de supervision 😉 Et les deux se complètent à merveille car là où la supervision de « haut niveau » permet de répondre à la question : Mes services sont-ils rendus correctement d’un point de vue utilisateur; la supervision technique permet de remonter à la source du problème et d’en mesure l’impact quand quelque chose ne va pas bien. Le beurre et l’argent du beurre en somme 🙂
Effectivement, le suivi de la performance applicative devient un passage obligé, et complémentaire de la supervision sys/rsx. Mais s’appuyer sur des scénarios et jeux de test applicatifs ne me semble plus d’actualité. De nouveaux outils basés sur des sondes réseaux (à bien positionner !) et déduisant les perfs des applis sont au point et particulièrement bluffants ! En plus d’informer de la vrai disponibilité des services, il amènent un niveau d’information fins …Seul hic, ça coute cher et pas de projet libre à ma connaissance… Ex de produit : Vantage de Compuware.
Merci pour l’info concernant Vantage. Je suis allé voir et me reste une question (sûrement plus 🙂 : Comment une sonde réseau, même bien positionnée; peut-elle vérifier que le contenu d’une page n’est pas vide ou hackée ou que l’utilisateur peut mettre un produit dans son panier sur un site de e-commerce ?
Effectivement, il est certainement possible de hacker le système (mais il faut y trouver un intérêt).
Il faut par contre ce rendre compte que ces outils peuvent aller très loin dans le suivi des actions de l’utilisateur : On pourra ainsi connaitre le temps de reponse d’une transaction pré-renseignée (paiement d’une facture par exemple), distinguer l’origine des utilisateurs (quel batiment, quel site est plus lent…). Cela permet meme d’améliorer l’ergonomie des applis, si on se rend compte par ex. qu’une appli ramène des centaines de lignes, et qu’une seule est attendue par l’utiliateur… Les technos évolues et permettent de décoder du Ctirix, du HTTPS (après insertion du certicat)…
Au final, l’objectif c’est de « factualiser » ce qui se passe : En cas de pb de lenteur, on ne pourra plus dire « c’est la faute du réseau » ! Un outil en or pour le DSI face à sa direction…
Je rappelle aussi que cet outil complète la panoplie classique de supervision (Nagios/centreon pour moi), mais bien sur, ne la remplace pas !
D’expérience ce n’est pas toujours possible de mettre en place un tel « hook » sur le réseau. J’ai déjà eu le soucis avec un tel outil fourni par Oracle avec un load balancing IPVS en mode direct routing. Mais il est vrai que dans l’absolu c’est l’idéal, car on mesure ce que les « vrais » utilisateurs voient 🙂
Par contre c’est hors de prix et spécifiques à telle ou telle application pour l’instant 🙁
Attention à ne pas trop simplifier : la supervision technique ne sert pas qu’à « remonter à la source du problème », elle sert aussi à prévenir les problèmes. Si vous avez deux serveurs équivalents pour assurer un service, une supervision fonctionnelle et applicative ne vous préviendra que lorsque les deux seront en panne (trop tard) alors qu’une supervision technique pourrait dire « attention, plus qu’un seul serveur en marche ».
Cf. le roman « Jurassic Park » où le parc bascule sur le générateur de secours et où personne ne remarque que le générateur principal est en panne… avant que le secours ne s’arrête également (libérant les grosses bêtes).
Bonne remarque et j’aime bien la référence en exemple 😉 Mais ne devrait-on pas voir une dégradation de service si un des deux serveurs est ko ?
je suis d’accord avec toi, il faut que cette supervision fonctionnelle vienne s’appuyer sur cette supervision Technique. La supervision technique est toujours nécessaire mais doit être un élément plus un background, limite pour faire du RCA (Root Cause Analysis). Cette liaison entre technique et fonctionnelle est de plus en plus vitale car les DSI commence à mettre le nez dans la supervision qui il y a quelques années n’était qu’un joujou d’admin sys & réseau.
Ils veulent connaitre de la supervision toutes dégradation des services rendues pour minimiser la perte de business. Et ceci est important pour le future des projets de supervision Open Source. Il faut qu’il avance vers ce genre de supervision de manière plus native.
Bonjour a tous ,
j’abonde dans votre sens a tous, SLA, QOS, Securite, QoE (Quality of Experience : perception par l’utilisateur de la qualité du service)… sont des informations devenues obligatoires dans la supervision de nos SI et qui doivent être visibles dans nos outils d’analyse.
Mais si remonter l’information n’est pas si difficile grace a nos moteurs preferés (shinken,nagios,…),
presenter la bonne information à la bonne personne : sans la noyer de technicité pour un decideur (DSI/RSSI) ou etre trop abstrait pour une administrateur n’est pas chose evidente. Devoir gerer X logiciels pour en aggreger les resultats (manuellement ou scripté) peut rapidement devenir casse-tete et problematique, en plus d’une correlation/analyse comportementale.
Nous proposerons d’ailleurs le mois prochain un plugin pour Centreon qui permet de superviser la sécurité.