GNU/Linux Magazine Hors-série N°
Numéro
62

Ne quittez plus vos serveurs des yeux !

Temporalité
Septembre/Octobre 2012
Image v3
Ne quittez plus vos serveurs des yeux !
Article mis en avant

Dans ce numéro...


Un élément récurrent dans le déploiement d’applications libres/open source est la complexité et la résolution de dépendances quand on souhaite utiliser la dernière version du logiciel souhaité. On pourra rétorquer que les paquets sont là pour régler ce problème et c’est certainement vrai… pour les applications ne bougeant pas beaucoup (OpenSSH ou Apache par exemple). Pour le cas des solutions de supervision, le besoin est sensiblement différent.
Shinken est une solution de monitoring moderne et adaptée aux problématiques actuelles d’analyse de la disponibilité des services. Cependant, pour bien maîtriser Shinken, il est nécessaire de bien comprendre les composants de base de son architecture, ainsi que leur rôle au sein de l’outil. Cet article va essayer d’introduire les différents composants de Shinken, leur rôle dans le fonctionnement global de Shinken, ainsi que la manière dont ils interagissent entre eux.
Nous avons vu des techniques pour tirer un maximum d’informations (utiles) de nos notifications, comme le fait de n’en recevoir qu’une pour un seul problème source. C’est très pratique, mais cette source n’est pas la seule utile dans l’obtention des informations de notre système de supervision. Les consoles graphiques sont également (et surtout ?) importantes. Or, tout ce que nous avons vu pour les notifications est également valable pour les interfaces graphiques. C’est même encore plus important, vu le nombres d’éléments à afficher. Nous allons voir l’interface standard de Shinken, qui tente de résoudre ce problème avec WebUI.
Quoi de plus complexe et consommateur de temps pour un administrateur que sa gestion de configuration (à part la mise en place de procédure ISO...) ? La configuration d’un outil de supervision n'est donc pas en reste et apporte malheureusement son lot de maux de têtes. La configuration d’un logiciel de supervision peut même se révéler être un véritable cauchemar, tant les suivis de deux serveurs peuvent être totalement opposés.
Nous avons vu dans l’article précédent la gestion de configuration classique en fichiers plats et le module de découverte, qui permet d’automatiser un peu cela. Cependant, les fichiers plats n’ont pas que des avantages et parfois, ils se révèlent peu adaptés dans certaines circonstances, comme celles où il faut monter un environnement hautement disponible par exemple. L'interface en ligne de commandes n'a pas que ses adorateurs (si si, véridique !) ; nous allons voir ici une interface qui se place au-dessus du module de découverte.
Comme dans beaucoup d'articles de ce hors-série, nous allons essayer ici de simplifier la gestion de la configuration de notre outil de supervision préféré. La gestion de la configuration de Shinken peut se faire « à l'ancienne », à savoir en éditant des fichiers textes décrivant les différents machines/services que vous souhaitez surveiller. Cette méthode, certes simpliste, ne passe évidemment pas à l'échelle. Au travers des articles précédents, vous avez vu comment Shinken permet de « découvrir » votre réseau et vos serveurs afin de configurer de manière automatique votre infrastructure. Il ne restera alors qu'à affiner certains détails (seuils... ). Nous allons vous proposer ici une autre approche de la gestion de la configuration de Shinken.
Gérer ses équipements (inventaire matériel et logiciel, contrats, informations financières...) et le monitoring dans le même outil, quel doux rêve ! Certes, c’est devenu une réalité grâce à la triplette GLPI – FusionInventory – Shinken. Tout le monde attendait d’avoir une centralisation forte, toutes les informations au même endroit et sans désynchronisation de données entre les outils. Voici donc la réponse que je vais vous présenter dans cet article.
Il est temps de passer à la pratique. J’espère que vous êtes au point sur la théorie cher lecteur, car elle va vous être utile. Vous êtes invité à relire l’article sur la configuration des quelques éléments utiles comme les hôtes et les services, car nous allons utiliser les concepts définis précédemment.
Les administrateurs sont en général très fiers de leurs serveurs, baies de disques et autres switchs. Ils ont raison de l’être. Pas parce que c’est intrinsèquement difficile de gérer (convenablement) un tel parc, mais plutôt que sans un tel système en place, performant et sans pannes intempestives, leur société ne pourrait pas faire de chiffre d’affaires et payer leur salaire, ainsi que celui de leurs collègues.
Nous avons vu les cas de corrélations dites « simples », qui peuvent s’exprimer sur une simple ligne avec des ET, des OU ou des Xof:. Cependant parfois, même avec cela, ça ne suffit pas. Les règles peuvent être bien plus complexes, comme dépendantes de données de performance et d’état en même temps par exemple.
Généralement, la supervision adresse les besoins de supervision technique. Cette approche limite et cantonne les solutions de supervision à des outils de techniciens et ne permet pas d'obtenir de la part de ces outils une visibilité de la part des responsables fonctionnels (qui sont alors obligés de se tourner vers des solutions dédiées).
Avant toute chose, sachez que si vous êtes un admin fainéant (efficace pardon...), vous allez sûrement passer votre chemin ! En effet, cette partie - comme son nom l’indique - sera consacrée à la réalisation d’un plugin Shinken. Mais elle ne sera en aucun cas là pour réinventer la roue. Si vous voulez une bonne base de plugins déjà existants, rendez-vous sur www.monitoringexchange.org. Cela étant dit, nous pouvons commencer cette partie. Enfin presque, faisons d’abord quelques rappels pour ceux qui n’auraient pas lu les articles précédents.
Nous avons vu que de nombreuses fonctionnalités optionnelles telles que la sauvegarde des données de rétention en base MongoDB, ou l’authentification au sein de l’interface Web de Shinken étaient fournies à travers des modules. Voyons maintenant comment en créer de nouvelles.
Comme nous l’avons vu dans les présentations de Nagios et Shinken, l'un de leurs points forts réside dans la modularité, soit la possibilité d’augmenter leurs capacités si besoin. Nous allons voir dans cet article plusieurs astuces pour améliorer la supervision ou la configuration de cette dernière, grâce à certains modules de Shinken.

Magazines précédents

Créez vos applications Android comme un pro !
GNU/Linux-Magazine Hors-série N°61
Créez vos applications Android comme un pro !
20 Recettes pour développer vos applications Android
GNU/Linux-Magazine Hors-série N°60
20 recettes pour développer vos applications Android
ZEND Framework 2
GNU/Linux-Magazine Hors-série N°58
ZEND Framework 2
Carnet de Root
GNU/Linux-Magazine Hors-série N°57
Carnet de Root
Java
GNU/Linux-Magazine Hors-série N°56
Java

Les derniers articles Premiums

Les derniers articles Premium

De la scytale au bit quantique : l’avenir de la cryptographie

Magazine
Marque
Contenu Premium
Spécialité(s)
Résumé

Imaginez un monde où nos données seraient aussi insaisissables que le célèbre chat de Schrödinger : à la fois sécurisées et non sécurisées jusqu'à ce qu'un cryptographe quantique décide d’y jeter un œil. Cet article nous emmène dans les méandres de la cryptographie quantique, où la physique quantique n'est pas seulement une affaire de laboratoires, mais la clé d'un futur numérique très sécurisé. Entre principes quantiques mystérieux, défis techniques, et applications pratiques, nous allons découvrir comment cette technologie s'apprête à encoder nos données dans une dimension où même les meilleurs cryptographes n’y pourraient rien faire.

Les nouvelles menaces liées à l’intelligence artificielle

Magazine
Marque
Contenu Premium
Spécialité(s)
Résumé

Sommes-nous proches de la singularité technologique ? Peu probable. Même si l’intelligence artificielle a fait un bond ces dernières années (elle est étudiée depuis des dizaines d’années), nous sommes loin d’en perdre le contrôle. Et pourtant, une partie de l’utilisation de l’intelligence artificielle échappe aux analystes. Eh oui ! Comme tout système, elle est utilisée par des acteurs malveillants essayant d’en tirer profit pécuniairement. Cet article met en exergue quelques-unes des applications de l’intelligence artificielle par des acteurs malveillants et décrit succinctement comment parer à leurs attaques.

Migration d’une collection Ansible à l’aide de fqcn_migration

Magazine
Marque
Contenu Premium
Spécialité(s)
Résumé

Distribuer du contenu Ansible réutilisable (rôle, playbooks) par l’intermédiaire d’une collection est devenu le standard dans l’écosystème de l’outil d’automatisation. Pour éviter tout conflit de noms, ces collections sont caractérisées par un nom unique, formé d’une espace de nom, qui peut-être employé par plusieurs collections (tel qu'ansible ou community) et d’un nom plus spécifique à la fonction de la collection en elle-même. Cependant, il arrive parfois qu’il faille migrer une collection d’un espace de noms à un autre, par exemple une collection personnelle ou communautaire qui passe à un espace de noms plus connus ou certifiés. De même, le nom même de la collection peut être amené à changer, si elle dépasse son périmètre d’origine ou que le produit qu’elle concerne est lui-même renommé.

Body