Remerciez-le!

Remerciez @Admin pour avoir partagé cet document gratuitement, de la manière la plus simple, en partageant sur les réseaux sociaux.

Choix d’une solution de supervision : atouts et fonctionnement de Nagios Sur qu

Choix d’une solution de supervision : atouts et fonctionnement de Nagios Sur quels critères juger une solution de supervision ? Quel est le fonctionnement de Nagios, référence open source en matière de supervision ? La mise en place de la solution de supervision devant être traitée comme un projet à part entière, commençons par l’étude des besoins. Choix d’une licence open source En ces périodes où les budgets des services informatiques fondent comme neige au soleil, la gestion des licences est de plus en plus contraignante. Les demandes des utilisateurs augmentent et conduisent à une accumulation de licences. Les outils de supervision ne font pas exception à cette règle. On peut, dans certains cas, arriver à ces situations où seuls les environnements critiques sont supervisés, faute de moyens pour acquérir les licences nécessaires aux autres environnements. Cette situation est dommageable à la qualité du service fourni aux utilisateurs – l’outil risque par exemple de ne pas être utilisé pour signaler un problème sur un environnement de test avant mise en production. L’utilisation d’un outil open source est tout indiquée dans ce genre de situation. Le besoin d’adaptabilité et de modularité Le choix d’une licence open source permet de répondre à un second besoin : l’adaptabilité. Comme nous l’avons vu, tous les environnements informatiques sont différents. La supervision doit s’adapter à chaque situation. Elle ne doit pas se comporter de la même manière sur un petit site que sur un système réparti sur plusieurs sites distants. Les applications à gérer sont également extrêmement variées. La modularité de l’outil est primordiale pour ne pas laisser de côté tout un pan du système. Avec un outil de supervision propriétaire, dans bien des situations, même si les administrateurs savent comment superviser un élément non pris en compte, ils ne peuvent pas, contractuellement ou techniquement, l’ajouter dans l’outil. Dans le cas d’un outil open source, il n’y a pas de limitation. Les administrateurs peuvent l’adapter librement. Transparence du mécanisme de remontée d’alerte Un autre besoin des administrateurs est de savoir comment est recueillie l’information. Les alertes qu’ils ne comprennent pas ne peuvent guère leur inspirer confiance. S’ils savent précisément comment est récupérée l’information, ils la prendront immé- diatement en considération. Ils pourront même essayer de l’améliorer. C’est tout l’intérêt des solutions open source ! De très bonnes performances Les systèmes d’information varient en architecture mais aussi en taille. La solution de supervision choisie doit être performante afin d’être en mesure de gérer un nombre important d’éléments. Il serait dommage de se restreindre à cause des piètres performances de l’outil. Bien évidemment, toute solution a ses limites, ne serait-ce qu’en raison des limitations des serveurs. L’outil doit dans l’idéal proposer des méthodes de répartition de charge sur plusieurs serveurs. Mise en commun des expériences Le phénomène de communauté est également important. Si chaque système d’information se distingue des autres, les différences ne sont généralement cantonnées qu’à une partie restreinte. Les systèmes ont, en général, de nombreux points communs et doivent être supervisés de la même manière. Au sein d’une communauté d’utilisateurs, il est possible de partager et de rassembler les meilleures pratiques de supervision. Ce phénomène de communauté est extrêmement marqué lorsqu’il s’agit d’outils open source car tout le monde peut participer à la conception de l’application, et chacun peut apporter son expérience dans la supervision d’un élément particulier et en faire profiter l’ensemble de la communauté. Critères de sélection d’un projet open source Le monde du logiciel libre est vaste. Comment s’y retrouver parmi les nombreuses solutions qui existent et trouver celle qui répond au mieux à ses besoins ? Un monde particulier, avec ses propres règles Lorsqu’on arrive dans le monde de l’open source, on perd un peu ses points de repères. Il n’est en général plus question d’éditeur, mais de communauté d’utilisateurs et de développeurs. Ce changement peut être dur à appréhender. Il est difficile de savoir comment tout ceci peut fonctionner correctement face aux solutions proprié- taires soutenues par de grands éditeurs. Il est courant d’avoir initialement certaines craintes quant à l’assistance dont on va pouvoir bénéficier. Chaque projet open source part en général d’un petit groupe de personnes (parfois une seule) qui souhaite répondre à un besoin particulier. Dans notre cas, le but de l’outil est de superviser les systèmes d’information. Une fois l’outil dans sa première version, un groupe d’utilisateurs l’adopte. Cette première période est critique. Si la solution n’apporte pas de réponse innovante aux problèmes rencontrés, elle ne va pas rassembler un grand groupe d’utilisateurs. Or ce groupe est vital dans l’écosystème de l’outil : c’est la communauté. Une petite partie de ces utilisateurs deviennent également développeurs et ils aident les auteurs à améliorer l’outil. Les autres utilisateurs, quant à eux, peuvent écrire de la documentation ou remonter des bugs directement aux développeurs. Importance de la communauté La solution ne peut progresser que si elle possède une grande communauté. On peut parler de masse critique d’utilisateurs pour qu’une solution devienne une référence dans le monde de l’open source. Les solutions non innovantes n’ont pas beaucoup d’utilisateurs et périclitent. Une fois qu’une solution est très présente au sein de la communauté, vient la phase où les entreprises commencent à s’y intéresser : se pose alors la question de l’assistance. Assistance aux entreprises L’assistance est fournie par des sociétés spécialisées regroupant des personnes très sensibles à la philosophie de l’open source. Celles-ci ont une forte expérience de l’outil et peuvent l’adapter si besoin. Ces modifications peuvent alors, si le client est d’accord, être remontées aux développeurs de l’application, en vue d’une inclusion dans la version officielle. L’entreprise cliente a tout intérêt à accepter. Si les modifications sont reportées dans la version officielle, de nombreux utilisateurs peuvent alors les utiliser et, le cas échéant, détecter des bugs et proposer des solutions de contournement. Les solutions de supervision open source ne font pas exception à la règle. Elles sont soumises, comme toutes les autres, aux règles de l’open source et de la communauté. Le rôle de la communauté est même plus important pour une solution de supervision (qui est confrontée à des situations extrêmement variées) que pour la plupart des autres outils open source. Le choix de Nagios Si l’on retient tous ces critères dans le choix d’une solution open source stable, performante et ayant une forte communauté, Nagios sort largement vainqueur. Cette solution est en effet la référence en matière de supervision dans le monde de l’open source. Histoire de Nagios L’histoire d’un outil peut nous en apprendre beaucoup sur lui. Nagios est développé par Ethan Galstad et débute son histoire en 1999 sous le nom de NetSaint. Quelque temps plus tard, à cause d’un problème de propriété intellectuelle sur le nom, il devient Nagios. Actuellement en version 3.1, il a plus de neuf ans d’existence. Comme nous le verrons par la suite, il se bonifie avec l’âge, à l’image d’un grand vin. Il a évolué depuis ses tous débuts afin de s’adapter à des parcs de plus en plus importants, tout en améliorant ses performances et ses capacités de gestion de configuration. Nagios ne fait rien sans ses plug-ins Il est le digne héritier du principe KISS (Keep It Simple, Stupid) d’Unix : il ne fait qu’une chose, mais la fait bien. Son rôle est d’ordonnancer les vérifications sur les éléments à superviser et de lancer une alerte si besoin. Il ne fait rien d’autre, pas même aller vérifier lui-même l’état des éléments à surveiller. Ceci peut paraître étonnant, mais Nagios ne sait rien faire tout seul. Il ne peut même pas vérifier le bon état du serveur sur lequel il est hébergé. Son auteur a en effet considéré qu’il ne pouvait prévoir toutes les vérifications qu’un tel outil doit intégrer. Il a donc décidé de n’en mettre aucune au sein de Nagios et de laisser la responsabilité des vérifications à des plug-ins que l’utilisateur devra fournir à l’outil. Position de Nagios par rapport à la métrologie Si on applique le principe de modularité à la métrologie, celle-ci ne doit pas être gérée directement par le même outil que celui chargé de la supervision. C’est pourquoi Nagios ne gère pas les données de métrologie, mais les récupère et les transmet à un outil dédié. Nagios récupère les données car, dans beaucoup de situations, les alertes sont définies par une comparaison entre les données mesurées et des seuils définis par l’utilisateur. Vu que Nagios doit récupérer cette valeur via un plug- in, il serait dommage qu’un outil de métrologie doive aller la chercher une seconde fois. Nagios va simplement exporter les données dans un fichier plat qui sera ensuite lu par l’outil de métrologie. De cette manière, l’utilisateur peut choisir l’outil de métrologie qu’il souhaite. Atouts de Nagios par rapport aux autres outils open source Nagios n’est pas le seul outil de supervision open source. Par rapport à ses concurrents, sa plus grande force réside dans sa modularité complète. Il n’a pas de domaine de prédilection et peut observer tout ce que ses plug-ins sont capables de rapporter. D’autres outils open source uploads/Management/ nagios.pdf