La supervision avec Shinken

Article rédigé par Sébastien Khedim en GMSIA5″

 

 

Introduction

Shinken est un outil de supervision basé sur Nagios, réécrit dans un autre langage de programmation (Python), qui permet de pouvoir séparer les différentes étapes d’acheminement des informations de supervision. Ce qui apporte comme avantages:

• Supervision distribuée hautement disponible très facile à mettre en place, et de manière intégrée à la configuration globale
• Gestion des noms en UTF-8
• Presque 5 fois plus de performances que le Nagios classique
• Multiplateforme : tourne nativement sur GNU/Linux et Windows. Il est même possible de mixer les deux dans une même architecture!
• Simplicité de migration depuis Nagios.

 

Les composants

Contrairement à Nagios qui gère tout le processus avec un seul service , Shinken sépare les différentes taches en plusieurs daemons (services).

Arbiter

Il est chargé de lire la configuration, de la découper en autant de parties qu’il y a d’ordonnanceurs dans l’architecture, et leur envoyer ainsi qu’aux autres éléments de l’architecture. Il est également garant de la haute disponibilité : si un élément tombe, il envoi la configuration qu’il avait en charge à un élément spare défini par l’administrateur. Enfin, son dernier rôle est de lire les ordres des administrateurs fournis dans le pipe nommé nagios.cmd et de les transmettre à tous les ordonnanceur ou un seul suivant la demande.

Schedulers

ils sont chargés d’ordonnancer les vérifications et de levers des actions en cas de soucis avec ces dernières. Ils ne lancent pas directement les vérifications ni les notifications. Il ne font que les proposer dans des files d’attentes où vont venir piocher d’autres éléments de l’architecture. L’administrateur peut en avoir autant qu’il veut, l’Arbiter va découper la configuration en fonction du nombre de schedulers définis.

Pollers

Ils ont pour rôle de lancer les sondes demandées par les ordonnanceurs dans lesquelles ils vont piocher les demandes. Ils utilisent un realm de process qui effectuerons les vérifications. Une fois par seconde, ils vont retourner les résultats aux ordonnanceurs pour que ces derniers puissent réaliser des actions supplémentaires si besoin (comme une notification) et réordonnancer les tests. Ils sont en première ligne pour les performances, et l’administrateur peut en avoir autant qu’il en a envi/besoin. Il peut également avoir des pollers sur GNU/Linux et d’autres en Windows par exemple comme nous le verrons plus loin.

Reactionners

Ils sont en charge de lancer les vérifications et les actions correctrices. Ils sont découplés des pollers car il est plus pratique d’avoir un unique reactionner (avec un spare) pour n’avoir qu’un seul lieu où se remplissent les flux RSS d’alertes ou les autorisations SMTP par exemple.

Broker

Il est en charge de récupérer les informations d’états des ordonnanceurs et de les traiter. Ces traitements sont fait par des modules. De nombreux modules existent : un pour l’export en base merlin (MySQL), un autre pour l’export des données de métrologie dans le fichier service-perfdata, une présentation des données de style Livestatus, un export en base Oracle ou encore un export en base CouchDB.

Skonf UI

Skonf UI est une interface Web permettant le scan du réseau et la gestion simplifiée des hôtes et des services. Contrairement à Nagios où il faut rentrer dans un fichier de configuration spécifique pour entrer ou modifier un hôte.

Pour scanner son réseau il suffit de lancer l’interface SkonfUI de demander un scan sur une plage d’adresses IP, et Shinken va se charger automatiquement de détecter les hôtes et les services qui leurs sont associés, grâce à des packs préconfigurés comme (SQL server oracle exchange AD…)