Shinken (logiciel)

Shinken possède une architecture novatrice :

• Architecture distribuée, hautement disponible avec répartition de charge automatique.
• Supporte la notion de multi-sites/clients grâce aux realms (royaumes).
• Peut être exécuté sous Windows, Linux et Android.

Shinken permet d'effectuer de l'acquisition active de données de façon parallèle et balancé sur plusieurs processus et plusieurs hôtes. Les méthodes actives suivantes sont supportées :

• Superviser des services réseaux : SMTP, POP3, HTTP, NNTP, ICMP, SNMP, LDAP, etc.
• Superviser les ressources des serveurs (charge du processeur, occupation des disques durs, utilisation de la mémoire paginée) et ceci sur les systèmes d'exploitation les plus répandus.
• Interface avec le protocole SNMP par l'intermédiaire des sondes.
• La supervision à distance peut utiliser SSH ou un tunnel SSL (notamment via un agent NRPE).
• Les plugins sont écrits dans les langages de programmation les plus adaptés à leur tâche : scripts shell (Bash, ksh, etc.), C++, Perl, Python, Ruby, PHP, C#, etc.
• Deux modules d'acquisition haute performance intégré à Shinken sont disponibles (NRPEbooster pour le protocole NRPE et SNMPbooster pour le protocole SNMP).

Shinken permet aussi une acquisition passive de donnée pour les déploiements à très grande échelle :

• Acquisition par le protocole NSCA, TSCA (Apache Thrift), Service Web.
• Acquisition de données pures, sans états, par le protocole réseau de collectd.

Shinken possède aussi des caractéristiques de traitement puissantes :

• Possibilité de définir une hiérarchie dans le réseau pour pouvoir faire la différence entre un serveur en panne et un serveur injoignable.
• Possibilité de définir des dépendances entre des services.
• Capacité de gestion des oscillations (nombreux passages d'un état normal à un état d'erreur dans un temps court).
• Recherche native des problèmes sources et suppression très efficace de faux positifs.
• Associer un impact d'affaire à un équipement ou service.
• Association automatique de l'impact d'affaire à des éléments parents ayant fait défaut.
• Règles métiers pour les états, afin d'associer des règles logiques pour un ensemble d'états.

Shinken permet de rendre disponibles les données de performance et d'état à des tiers :

• Shinken possède une interface graphique native Shinken WebUI afin d'interagir avec le système.
• Exportation de données de performance vers la BD de métrologie Graphite[6] ou PNP4Nagios(RRDtool).
• Intégration native à même l'interface graphique Shinken WebUI, Thruk ou Multisite de la visualisation des données de performance de PNP ou Graphite.
• API interactif Livestatus afin de rendre disponibles les états, configurations et données de performance.
• Acquittement des alertes par les administrateurs.
• La remontée des alertes est entièrement paramétrable grâce à l'utilisation de plugins (alerte par courrier électronique, SMS, etc.).

Shinken permet de créer ses propres plugins, dans le langage désiré. Il suffit de respecter la norme Nagios des codes retour :

• 0 OK (tout va bien) ;
• 1 WARNING (le seuil d'alerte est dépassé) ;
• 2 CRITICAL (le service a un problème) ;
• 3 UNKNOWN (impossible de connaître l'état du service).

La création de nouveaux plugins permet de répondre de façon personnalisée à tout besoin.

Shinken possède aussi un mécanisme simple de « Pack » de supervision qui simplifie beaucoup la mise en place.

• Les « Pack » sont disponibles sur le site communautaire de Shinken.
• Les « Pack » et la découverte sont gérés par le gestionnaire graphique SkonfUI.
• Les « Pack » sont inclus de base dans Shinken et peuvent être dynamiquement mis à jour par le gestionnaire Graphite de Shinken SkonfUI.

Shinken possède aussi d'autres caractéristiques notables :

• Gestion des noms en UTF-8.

Ce qui différencie Shinken de son aîné Nagios n'est pas tant le langage de programmation utilisé que son architecture, qui repose sur le principe Unix : à une tâche un outil. C'est pour cette raison que Shinken n'est pas monolithique comme Nagios, mais utilise six processus différents qui travaillent ensemble et permettent d'obtenir une flexibilité bien supérieure au Nagios originel.

C'est cette architecture qui permet d'obtenir la mise en place facile d'une supervision distribuée : un processus s'occupe de lire la configuration de l'utilisateur et la découpe intelligemment (en respectant les relations entre les éléments) afin de distribuer les morceaux vers des processus chargés d'absorber la charge de supervision. De cette manière, en cas de nouvelle charge, l'utilisateur peut rajouter des processus sans avoir à modifier sa configuration en profondeur. C'est un lissage de charge automatique.

C'est de ce choix architectural que vient le nom de logiciel. Shinken, un nom de katana très tranchant, représente l'objectif du projet, à savoir de découper la configuration pour la renvoyer sur des daemons.

Shinken se découpe en 6 modules[3] :

• L’arbitre (Arbiter) : Il est responsable de la validation et du chargement de la configuration, la découpe en différentes parties (N ordonnanceurs = N parties), et l’envoie aux autres éléments. Il gère également la haute disponibilité : si un élément devient injoignable, il redirige la configuration sur un autre. Il ne peut y en avoir qu’un seul actif dans l’architecture avec des "spare" aux fins de relève.
• L’ordonnanceur (Scheduler) : Il est chargé d’ordonnancer les checks, d’analyser leurs résultats et de déclencher une action en fonction de ces derniers si c’est nécessaire. Ce n’est pas lui qui lance les checks ou les notifications, il ne fait que rediriger les informations. Il garde juste dans une file d’attente les checks en attente (pending) et notification pour les autres éléments (collecteurs ou "Réactionneur"). Il peut y avoir plusieurs ordonnanceurs, c'est d'ailleurs conseillé.
• Le collecteur (Poller) : Son rôle est de lancer les plugins en fonction des requêtes des ordonnanceurs. Ces plugins, qui peuvent être ceux de Nagios, vont aller interroger le système surveillé et retourner un résultat indiquant l'état. Lorsqu’un plugin renvoie un résultat, il le transmet à l’ordonnanceur. Il peut y avoir plusieurs collecteurs.
• Le « réactionneur » (Reactionner) : il est chargé de l'envoi des notifications et de lancer les « event_handlers » (action automatique programmable). Il peut en voir autant que l’administrateur en veut.
• Le « courtier » (Broker) : Son rôle est de prendre des données sur les schedulers (comme les statuts par exemple) et de les rendre disponibles à l'externe de Shinken. Il fonctionne avec des modules. Il existe plusieurs de ces modules : export dans une base NDO, exporter vers une base de données Graphite, API interactif Livestatus, export vers syslog et autres modules. Un seul broker par Scheduler ou 1 broker pour multiples schedulers.
• Le « receveur » (Receiver) : Son rôle est de recevoir les données d'acquisition passive et de les acheminer vers le bon scheduler responsable de faire la corrélation et le traitement des statuts. Il possède divers modules d'Acquisition tels que NSCA, TSCA, Service Web, Command Pipe et autres. Il peut y avoir plusieurs receveurs.