EA2012-Shinken: Difference between revisions
No edit summary |
No edit summary |
||
| Line 8: | Line 8: | ||
= Abstract = |
= 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 === |
=== Keywords === |
||
| Line 14: | Line 19: | ||
= Résumé = |
= 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 === |
=== Mots Clés === |
||
Revision as of 15:59, 24 December 2012
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
lien externe [1].
Shinken est un logiciel de surveillance de parc informatique. Mais d'où vient ce besoin ?
Besoin des entreprises
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 [img]
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é.
Exemples de l'interface WebUI
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.
Définition de la criticité
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
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 <windows.h>
#include <stdio.h>
#include <stdlib.h>
#include <conio.h>
//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
- 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)/