Shinken (logiciel)
| Shinken | |
Logo |
|
|
|
|
| Développeur | Jean Gabès |
|---|---|
| Dernière version | 1.2.4 (30 janvier 2013) |
| Environnement | Linux, *NIX, Windows |
| Langue | Anglais |
| Type | Supervision |
| Licence | GNU AGPL |
| Site web | www.shinken-monitoring.org |
| modifier |
|
Shinken est une application permettant la surveillance système et réseau. Elle surveille les hôtes et services spécifiés, alertant lorsque les systèmes vont mal et quand ils vont mieux. C'est un logiciel libre sous licence GNU AGPL. Elle est complètement compatible avec le logiciel Nagios et elle a pour but d'apporter une supervision distribuée et hautement disponible facile à mettre en place. Démarrée comme une preuve de concept pour Nagios sur les architectures distribuée[1], le programme a rapidement démontré des performances et une flexibilité bien plus importantes que son ainé Nagios[réf. nécessaire].
Suite à un refus en décembre 2009 des développeurs de Nagios de voir Shinken devenir la nouvelle branche de développement de Nagios dans le futur[1][2], Shinken peut désormais être considéré comme un projet indépendant de système de surveillance système et réseau.
Sommaire |
Possibilités [modifier]
Shinken possède une architecture novatrice:
- Architecture distribué, hautement disponible avec balancement de charge automatique
- Supporte la notion de multisites/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 methodes actives suivantes sont supportés:
- Superviser des services réseaux : (SMTP, POP3, HTTP, NNTP, ICMP, SNMP, LDAP, etc.)
- Superviser les ressources des serveurs (charge du processeur, occupation des disque 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éploiement à 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 (nouveau en v1.2)
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 parent 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 ou PNP4Nagios(RRDtool)
- Intégration native à même l'interface graphique Shinken WebUI, Thruk ou Multisite de la visualization 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)
- Les possibilité de tests deviennent donc infinies, il suffit d'écrire tout plugin qui n'existerait pas déjà sur les sites spécialisés.
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 est géré par le gestionnaire graphique SkonfUI
- Les "Pack" sont inclus de base dans Shinken et peuvenet ê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
L'architecture de l'outil [modifier]
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[1] :
- 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 attentes (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 status 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ée Graphite, API interactif Livestatus, export vers syslog et autres modules. Un seul broker par Scheduler ou 1 broker pour multiples scheduler.
- 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 tel que NSCA, TSCA, Service Web, Command Pipe et autres. Il peut y avoir plusieurs receveurs.
Voir aussi [modifier]
Articles connexes [modifier]
- Autres logiciels de supervision
- Divers
Liens externes [modifier]
- (en) Site officiel
- (en) NagiosExchange
- (fr) Communauté francophone Nagios
- (fr) RMLL Présentation de Shinken aux RMLL 2010 à Bordeaux.
Notes et références [modifier]
- (fr) Shinken : quand un Python rencontre Nagios, par Jean Gabès, sur unixgarden.com
- Proposition d'inclusion de Shinken dans la branche de développement de Nagios sur https://sourceforge.net/mailarchive/message.php?msg_id=6f8615170912010909me433f0do3eb284c11def9dc4%40mail.gmail.com