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

Cryptographie : débuter par la pratique grâce à picoCTF

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

L’apprentissage de la cryptographie n’est pas toujours évident lorsqu’on souhaite le faire par la pratique. Lorsque l’on débute, il existe cependant des challenges accessibles qui permettent de découvrir ce monde passionnant sans avoir de connaissances mathématiques approfondies en la matière. C’est le cas de picoCTF, qui propose une série d’épreuves en cryptographie avec une difficulté progressive et à destination des débutants !

Game & Watch : utilisons judicieusement la mémoire

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

Au terme de l'article précédent [1] concernant la transformation de la console Nintendo Game & Watch en plateforme de développement, nous nous sommes heurtés à un problème : les 128 Ko de flash intégrés au microcontrôleur STM32 sont une ressource précieuse, car en quantité réduite. Mais heureusement pour nous, le STM32H7B0 dispose d'une mémoire vive de taille conséquente (~ 1,2 Mo) et se trouve être connecté à une flash externe QSPI offrant autant d'espace. Pour pouvoir développer des codes plus étoffés, nous devons apprendre à utiliser ces deux ressources.

Raspberry Pi Pico : PIO, DMA et mémoire flash

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

Le microcontrôleur RP2040 équipant la Pico est une petite merveille et malgré l'absence de connectivité wifi ou Bluetooth, l'étendue des fonctionnalités intégrées reste très impressionnante. Nous avons abordé le sujet du sous-système PIO dans un précédent article [1], mais celui-ci n'était qu'une découverte de la fonctionnalité. Il est temps à présent de pousser plus loin nos expérimentations en mêlant plusieurs ressources à notre disposition : PIO, DMA et accès à la flash QSPI.

Body