EA2012-Shinken

= Présentation =


 * Enseignants: Georges-Pierre Bonneau, Didier Donsez
 * Auteur: Noé-Jean Caramelli (Noe-Jean.Caramelli@e.ujf-grenoble.fr)
 * Télécharger : [[Media:Shinken.pdf]]

= Abstract = First, this paper describes the background of supervision needs and introduce the two most famous monitoring software Nagios and Shinken.

Then it focuses on Shinken, presents the architecture, the principles and the most important technical features.

It concludes with a demonstration that the source code is provided.

Keywords
Shinken, Nagios, monitoring system, IT infrastructure

= Résumé = D'abord, cette présentation rappelle l'origine des besoins en supervision, introduit les deux logiciels de supervision les plus connus Nagios et Shinken.

Puis elle se concentre sur Shinken, en présente l'architecture, le fonctionnement et les points techniques les plus important.

Elle se conclut par une démonstration dont le code source est fournit.

Mots Clés
Shinken, Nagios, supervision, système d'information

= Synthèse =

Shinken est un logiciel de surveillance de parc informatique. Mais d'où vient ce besoin ?

Le développement des réseaux
Ces dernières années, les réseaux se sont particulièrement développés. Les débits augmentent, et avec ceux, les possibilités. Les réseaux informatiques sont devenus un des piliers centraux de l'économie et du fonctionnement des entreprises, à la fois pour les communications, mais aussi pour les données vitales des entreprises (bases de données clients, stocks, …) et enfin pour la gestion des finances. En conséquence, l'état des machines assurant ces fonctionnalités devient de plus en plus critique à mesure que le papier est entièrement remplacé par des systèmes informatisés.

L’Expansion des systèmes d'information
L'autre raison de la naissance de ce besoin de supervision est l'augmentation du nombre et du type des machines interconnectées. Les réseaux ne se restreignent plus aux serveurs et ordinateurs de bureau traditionnels comme c'était le cas il y a quelques années. Les systèmes d'information des entreprises sont désormais constitués d'un parc de machines très hétérogènes tel que des téléphones VoIP, des imprimantes de plus en plus nombreuses, des appareils mobiles, des sondes, des caméra de surveillances, des pare-feu, des portails… Et cette diversification tends à évoluer vers l'internet des objets. Les caractéristiques et les constantes vitales des appareils connectés deviennent de plus en plus variées avec la diversification de leur type.

L'augmentation de la quantité d'information, la taille des réseaux et du type des machines mène à la création de services dont l'état est critique, et le besoin de supervision et d'administration de ces réseaux est de plus en plus important.

Un exemple
Voici l'exemple d'un réseau de serveurs (exchange.nagois.org) répartit à travers États-Unis, qui demande un système de supervision performant pour en assurer le fonctionnement et en connaître l'état.

Les outils de supervision
Il existe deux outils majeurs pour la supervision de parcs informatiques : Nagios et Shinken. Ces deux outils sont liés par l'histoire du développement des outils de supervision, puisque Shinken est directement inspiré de Nagios. Il est cependant important de préciser que la supervision ne se restreint pas à ces deux logiciels. Il existe d'autres méthodes de supervision et également d'autres logiciels et technologies qui viennent compléter les logiciels de supervision présentés ici, en leur ajoutant différentes couches.

Nagios
Nagios est céé en 1996 par Ethan Galstad dans le Minnesota (U.S.). Il repose sur un modèle centralisé et mono-démon. Il est sous licence GNU-GPL. Nagios est développé en C. En pratique, il résiste mal à une charge de plus de 200 machines. Bien sûr cela dépend des performances du réseau et du serveur de supervision utilisé, mais la limite imposée par l'architecture mono-demon apparaît rapidement. Elle constitue un goulot d'étranglement.

Shinken
Shinken est céé en 2010 par Jean Gabès diplômé en 2005 de l'ENSEIRB à Bordeaux. Il repose sur une architecture distribuée et est constitué d'un pool de démon. Pour prendre en compte l'aspect de mise en réseau apporté par l'aspect distribué du logiciel, mais aussi son utilisation qui n'a de sens que sur un réseau, il est placé sous licence GNU-AGPL. Il est développé en Python.

Présentation de l'information à l'utilisateur : exemples
Exemple d'une liste de caractéristiques systèmes de différentes machines supervisées et de leur état, incluant leur statuts.

Exemples de présentation de statistiques sur l'état du système supervisé. On remarque que les interfaces basiques fournies avec Skinken ou Nagios sont concues pour donner des informations pertinentes à un administrateur ou à un technicien en informatique, mais qu'il existe aussi des pages cnçues pour êtres facilement comprises et interprétables par des non-informaticiens

La suite de la présentation se concentre sur Shinken.

Les possibilités qu'offre Shinken
L'architecture distribuée de Shinken permet de mettre en place un système de supervision disponible avec une balance de charge. Sinken permet :
 * l'acquisition active des données grâce aux plugins : http://www.shinken-monitoring.org/wiki/official/thebasics-plugins/
 * l'acquisition passive grâce à NSCA/TSCA, des protocoles spécialisés dans cette fonction : http://www.shinken-monitoring.org/wiki/scaling_shinken/

De plus l'interface WebUI qui est fournie de base permet d'interpréter les données de performances et permet d'émettre des notifications sur l'état du parc informatique supervisé. Cette interface peut être complétée avec d'autres couches logicielles ou remplacée par une autre interface.

Le système des Packs permet une mise en place rapide de l'acquisition active des données. Il facilite la découverte, le partage et l'installation des fichiers de configuration nécessaires pour superviser un matériel spécifique ou spécialisé.

Les plugins sont indépendants de Shinken. Ils n'ont qu'une spécification (que l'on verra plus tard) à respecter pour fonctionner. Un plugin n'est en fait qu'un programme qui peut être écrit dans n'importe quel langage, Cela confère à Shinken une grande flexibilité.

Architecture de Shinken
Shinken est découpé en 6 démons
 * Arbiter : gestion configuration, assurance de disponibilité • Scheduler : ordonnance les checks (plugins). Analyse les résultats ; déclenche une action.
 * Poller : lance les plugins (requêtes Scheduler)
 * Reactionner : envoi des notifications et lance des actions (event handler)
 * Broker : Interface entre Shinken (scheduler) et l’extérieur (une BD)
 * Receiver : reçoit les données d’acquisition passive et les passe au sheduler pour traitement.

Statuts de l'état des composants
Les statuts (universel) :
 * 0 = OK
 * 1 = WARNING
 * 2 = CRITICAL
 * 3 = UNKNOW

Données métriques
Le statuts est couplé à des données métriques qui permettent d'avoir un historique des caractéristiques importantes du système et de prendre des décisions, des mesures ou de faire des actions plus fines que simplement avec le statuts.

Cette définition de la criticité de l'état d'un composant est valable pour Shinken et Nagios mais est uun standard de fait pour les outils de supervision. C'est la seule spécification que les plugins doivent respecter pour fonctionner avec Shinken.

Démonstration
La démonstration met en œuvre une carte arduino et un simple potentiomètre pour simuler une sonde de température.

Code
Code du plugin :

/******************************************************************************/   /*	Noe-Jean Caramelli														  */ /*		fonctions d'acces au port com : base developpez.com, modifiees		 */ /*	09-11-2012																 */    /*	Plugin Shinken pour sonde de temperature Celsius sur port serie RS232	  */ /******************************************************************************/   #include     #include     #include     #include     //status Shinken #define OK			0 #define WARNING		1 #define CRITICAL	2 #define UNKNOW		3 #define WARNING_TEMP_LEVEL	333 #define CRITICAL_TEMP_LEVEL	666 #define COM_NO			3		//Numero du port COM utilise #define RX_SIZE        4096    //taille tampon entree #define TX_SIZE        4096    //taille tampon sortie #define MAX_WAIT_READ  2000    //temps max d'attente pour la lecture (ms) HANDLE g_hCOM = NULL; //handle du port COM ouvert //delais d'attente sur le port COM COMMTIMEOUTS g_cto = { MAX_WAIT_READ, //ReadIntervalTimeOut 0,             //ReadTotalTimeOutMultiplier MAX_WAIT_READ, //ReadTotalTimeOutConstant 0,             //WriteTotalTimeOutMultiplier 0              //WriteTotalTimeOutConstant };   //configuration du port COM DCB g_dcb = { sizeof(DCB),       //DCBlength 9600,              //BaudRate TRUE,              //fBinary FALSE,             //fParity FALSE,             //fOutxCtsFlow FALSE,             //fOutxDsrFlow DTR_CONTROL_ENABLE, //fDtrControl FALSE,             //fDsrSensitivity FALSE,             //fTXContinueOnXoff FALSE,             //fOutX FALSE,             //fInX FALSE,             //fErrorChar FALSE,             //fNull RTS_CONTROL_ENABLE, //fRtsControl FALSE,             //fAbortOnError 0,                 //fDummy2 0,                 //wReserved 0x100,             //XonLim 0x100,             //XoffLim 8,                 //ByteSize NOPARITY,          //Parity ONESTOPBIT,        //StopBits 0x11,              //XonChar 0x13,              //XoffChar '?',               //ErrorChar 0x1A,              //EofChar 0x10               //EvtChar };   /******************************************************************************/    /*                 Prototypes fonctions RS232                                 */ /******************************************************************************/   BOOL OpenCOM  (int com_no); BOOL CloseCOM ; BOOL ReadCOM (void* buffer, int nBytesToRead, int* pBytesRead); BOOL WriteCOM (void* buffer, int nBytesToWrite, int* pBytesWritten); /******************************************************************************/   /******************************************************************************/    /*                 Code du plugin Shinken                                     */ /******************************************************************************/   int main(int argc, char* argv[]) { char buffer[16]; int nb_bytes_read; int temp; //ouvre le port serie COM_NO if(!OpenCOM(COM_NO)) { printf("Probleme lors de l'ouverture du port COM%d ! \n", COM_NO); //system ("PAUSE"); exit(UNKNOW); }   //lit une tramme de l'arduino if(!ReadCOM(buffer, sizeof(buffer)-1, &nb_bytes_read)) { printf("Probleme lors de la lecture du port COM%d ! \n", COM_NO); //system ("PAUSE"); exit(UNKNOW); }   	buffer[nb_bytes_read] = '\0'; //ferme le port COM_NO CloseCOM; //printf("%d octet(s) recu(s) :\n%s\n", nb_bytes_read, buffer); temp=atoi(buffer); //printf("temp=%d\n", temp); //system ("PAUSE"); if(temp < -274) { printf("Valeur de temperature en dessous du 0 absolu ! Verifier capteur... | %d \n", temp); //system ("PAUSE"); exit(UNKNOW); }   	else if(temp < WARNING_TEMP_LEVEL) { printf("Temperature correcte. | %d \n", temp); //system ("PAUSE"); exit(OK); }   	else if(temp < CRITICAL_TEMP_LEVEL) { printf("Chauffe anormale... | %d \n", temp); //system ("PAUSE"); exit(WARNING); }   	else { printf("Ca crame !!!! | %d \n", temp); //system ("PAUSE"); exit(CRITICAL); }       return 0; }   /******************************************************************************/    /*  OpenCOM : ouverture et configuration du port COM. */   /*  entree : com_no : Id du port COM a ouvrir. */   /*  retour : vrai si l'operation a reussi, faux sinon. */   /******************************************************************************/    BOOL OpenCOM(int com_no) { //variables locales char szCOM[16]; //construction du nom du port, tentative d'ouverture sprintf(szCOM, "COM%d", com_no); g_hCOM = CreateFile(szCOM, GENERIC_READ|GENERIC_WRITE, 0, NULL,                           OPEN_EXISTING, FILE_ATTRIBUTE_SYSTEM, NULL); if(g_hCOM == INVALID_HANDLE_VALUE) {           //printf("Erreur lors de l'ouverture du port COM%d", com_no); return FALSE; }       //affectation taille des tampons d'emission et de reception SetupComm(g_hCOM, RX_SIZE, TX_SIZE); //configuration du port COM if(!SetCommTimeouts(g_hCOM, &g_cto) || !SetCommState(g_hCOM, &g_dcb)) {           //printf("Erreur lors de la configuration du port COM%d", com_no); CloseHandle(g_hCOM); return FALSE; }       //on vide les tampons d'emission et de reception, mise a 1 DTR PurgeComm(g_hCOM, PURGE_TXCLEAR|PURGE_RXCLEAR|PURGE_TXABORT|PURGE_RXABORT); EscapeCommFunction(g_hCOM, SETDTR); return TRUE; }   /******************************************************************************/    /*  CloseCOM : fermeture du port COM. */   /*  retour : vrai si reussi. .					 */    /******************************************************************************/    BOOL CloseCOM { //fermeture du port COM CloseHandle(g_hCOM); return TRUE; }   /******************************************************************************/    /*  ReadCOM : lecture de donnees sur le port COM. */   /*  entree : buffer       : buffer des donnees lues. */   /*           nBytesToRead : nombre max d'octets a lire. */   /*           pBytesRead   : variable affectee le nombre d'octets lus. */   /*  retour : vrai si l'operation a reussi, faux sinon. */   /**/    /*  Remarques : -la constante MAX_WAIT_READ utilisee dans la structure		  */ /*              COMMTIMEOUTS permet de limiter le temps d'attente si aucun   */ /*              caracteres n'est present dans le tampon d'entree. */   /*              -la fonction peut donc retourner vrai sans avoir lu de donnees*/ /******************************************************************************/   BOOL ReadCOM(void* buffer, int nBytesToRead, int* pBytesRead) { return ReadFile(g_hCOM, buffer, nBytesToRead, pBytesRead, NULL); }   /******************************************************************************/    /*  WriteCOM : envoi de donnees sur le port COM. */   /*  entree : buffer        : buffer avec les donnees a envoyer. */   /*           nBytesToWrite : nombre d'octets a envoyer. */   /*           pBytesWritten : variable qui va recevoir le nombre d'octets	  */ /*                          envoyes. */   /*  retour : vrai si l'operation a reussi, faux sinon. */   /******************************************************************************/    BOOL WriteCOM(void* buffer, int nBytesToWrite, int* pBytesWritten) { //ecriture sur le port return WriteFile(g_hCOM, buffer, nBytesToWrite, pBytesWritten, NULL); }

= Sources =

lien externe.
 * GNU/Linux Magasine France - Hors Série, numéro 62, septembre/octobre 2012, 8€, aux éditions Diamond : http://www.unixgarden.com/index.php/gnu-linux-magazine-hs/gnulinux-magazine-hs-n62-septembreoctobre-2012-en-kiosque/
 * http://www.shinken-monitoring.org/
 * http://fr.wikipedia.org/wiki/Shinken_(informatique)/