Somone sera présent à la Convention Annuelle du CRIP 2013

 

Somone a décidé de faire évoluer son partenariat avec le CRIP.

Nous sommes donc passé de partenaire WEB à partenaire BRONZE, et nous serons présents à la convention annuelle pour présenter notre savoir-faire et nos solutions les 2 jours au stand 49B.

N’hésitez pas à venir nous voir, par curiosité ou si vous avez un projet.

Nous serons à l’écoute et nous aurons le plaisir de vous remettre une copie papier de notre premier Livre Blanc.

 

747x194_ConventionCRiP2013

 

 

 

 

 

 

Une autre surprise est à venir, mais nous en parlerons ultérieurement.

livre blanc

Livre Blanc Somone: Maîtrisez le cycle de vie de votre supervision informatique

 

Somone est une société spécialisée dans les domaines de la supervision et de l’hypervision et elle souhaite le partager avec ses clients!
Nous avons  décidé la publication régulière de livres blancs qui auront pour utilité d’accompagner le client dans la maîtrise de la supervision de son SI et dans sa volonté de générer de la valeur ajoutée / réduire ses coûts.

Le premier livre porte sur le thème de la maîtrise du cycle de vie de la supervision, et a été réalisé suite à notre prestation lors du salon IT Innovation Day du CRIP.

Bonne Lecture, et n’oubliez pas que nous restons disponible pour tout complément d’informations!

Livre disponible ici.

Alexandre DUCROCQ
Business Driver

Somone au forum IT INNOVATION DAY organisé par le CRIP/Itiforums

Ce forum sur l’Innovation organisé par ITI Forums et parrainé par le CRIP fait suite à la demande exprimée par l’association d’utilisateurs qui regroupe plus de 2000 responsables d’Infrastructure et de Production.

Cheikh Sadibou Deme, Président de Somone, à l’écoute de la problématique d’un client.

Le CRiP est une association indépendante d’utilisateurs qui rassemble plus de 2000 responsables d’Infrastructure et de Production IT représentant plus de 210 grands comptes et administrations.

SOMONE était présent à ce forum qui lui a permis de présenter sa solution TeeM Monitoring Lifecycle Management lors d’une présentation orale, suivie du retour enthousiaste de l’un de nos clients.

Notre stand a reçu la visite de nombreuses sociétés qui cherchaient à optimiser leur budget supervision et la qualité de service qu’ils délivraient en interne.

L’expérience a été très positive, le public nombreux et intéressé. Nous sommes ravis d’avoir été retenu par le comité de sélection et d’avoir ainsi pu présenter notre savoir-faire et notre innovation. Cet événement nous a motivé à pousser plus encore notre partenariat avec le CRIP à l’avenir, au-delà du fait d’être déjà reconnu comme prestataire de confiance.

 


Logo_Agora_CRiP

news

Somone : News du mois de Mars

Sorties

Informations

Lectures

news

News du mois de Mars…

Sorties

Informations

Lectures

TeeM Monitoring Lifecycle Management, et son module d’industrialisation

TeeM Monitoring Lifecycle Management permet entre autre l’industrialisation de la configuration de la supervision et l’insertion en masse d’équipements ou objets de supervision.

Avec TeeM MLM (Module d’industrialisation), les exploitants de la supervision évitent le travail manuel de première configuration de la supervision,notamment par le biais de l’outil d’inventaire “GLPI”. TeeM MLM (Module d’industrialisation) permet d’importer en masse les équipements et applications de l’outil d’inventaire vers la solution de supervision.

TeeM MLM (Module d’industrialisation) aide aussi au maintien en condition opérationnelle et mise-à-jour de la solution de supervision. En effet, grâce à un système de gestion des changements, les exploitants de la supervision peuvent recharger la configuration pratiquement en temps réel.

Le projet TeeM MLM (module d’industrialisation) a démarré en Mai 2010 quand des scripts d’industrialisation ont été développés pour le compte d’un client en utilisant une première API de Centreon CLAPI. Équivalent à une version alpha, d’énormes efforts ont été consenti pour le debuggage en collaboration avec Merethis. Ces scripts ont donné naissance à l’actuel TeeM MLM (Module d’industrialisation).

Avec ces scripts, nous passions d’un fichier CSV à de la configuration Nagios. Suite a cela, nous avons voulu utiliser ces scripts avec comme source de données l’inventaire du client via GLPI, pour créer les hôtes dans un premier temps, puis leur assigner des services templates en utilisant les applications connues dans GLPI. Dans les spécifications, nous devions avoir une étape intermédiaire que le client validait. Cela se traduisait par un fichier Excel.

Toutes ces actions étaient regroupées dans un Job Talend en deux parties. La première partie consiste à générer un fichier Excel à partir d’une liste de serveurs (Input : liste de serveur en CSV, Talend : CSV => SQL, Talend : vues SQL => plusieurs CSV, Perl : CSVs => Excel). Puis, s’en suivait une étape de validation client faite à partir du fichier Excel généré. Enfin la seconde partie du Talend était lancée (Input : Excel, Perl : Excel => CSVs, Perl : CSVs => Clapi).

Quelques temps après, suite à une volonté de rationaliser et de simplifier «l’industrialisation», toute la mécanique a été reprise dans un unique script, utilisant comme brique les classes python développées chez le client pour accéder à CLAPI. Suite à cela, les options de TeeM MLM (Module d’industrialisation) ont été simplifiées pour faciliter son utilisation.

A. BUFFET

shinken_logo

Etude Shinken / Centreon

Dans le cadre d’une mission, j’ai souhaité mettre en avant un produit innovant afin de sortir du couple Nagios / Centreon. En effet, Out Of the Box, Les performances sur environnements virtualisés (VMWare) sont assez médiocres … (1500 checks / 5 min) avec une forte accumulation de maintenance.
J’ai donc déployé Shinken / Centreon avec les problèmes de compatibilité que cela allait supposer et qui étaient connus au moment de la décision.
Shinken est une ré-implémentation de Nagios en Python qui garde la rétro compatibilité avec Nagios, tout en introduisant un certain nombre de fonctionnalités, comme la découverte d’objets, des règles business, etc…

Avant le déploiement voici la liste des pour et des contre :

Les pour :

  • Équilibrage de charge
  • Haute disponibilité
  • Performant
  • Scalable
  • Rétro compatible Nagios
  • Fonctionne bien en environnement virtualisé
  • Codé en langage moderne (Python)

Les contre :

  • Compatibilité moyenne avec Centreon
  • Nécessite beaucoup de dépendances
  • Consomme de la mémoire

Maquette :

Le projet de migration d’un autre produit vers Shinken / Centreon (version 1.2.2) validé, j’ai entrepris de créer une maquette avec les cinq applications les plus importantes afin de me faire une idée concrète.
Globalement l’installation est simple et sans accroc grâce à un script complet qui installe l’ensemble des composants et des dépendances (très nombreuses et qui requièrent les droits root pour yum).
J’ai donc installé et configuré les serveurs suivants :

  • Centreon (8 Go de RAM) : Centreon ; Shinken- Arbiter ; Shinken-Scheduler ; Shinken-Broker ; Shinken-Receiver ; Shinken-Reactionner.
  • DB (8 Go de RAM): MySQL ; MongoDB (pour la rétention des états et la configuration de la WebUI de Shinken).
  • Poller1 (4 Go de RAM) : Shinken-Scheduler ; Shinken-Poller.
  • Poller2 (4 Go de RAM) : Shinken-Scheduler ; Shinken-Poller.

Premier point délicat, l’interfaçage avec Centreon. En effet, lorsque l’on vérifie la configuration, cela échoue car Shinken ne renvoie pas la bonne ligne à la fin de cette vérification. J’ai donc patché et mis en forme la sortie pour la rendre plus lisible.
Un second patch a été réalisé pour pouvoir utiliser les règles Business (autre avantage de Shinken) comme celles de Nagios BPA mais en plus évolué.

Montée en charge et problèmes rencontrés :

Au fur et à mesure de l’avancement du déploiement, je constate une forte montée en RAM due à une forte consommation de Shinken-Broker. Ce rôle étant primordial pour la visibilité (Logs, Livestatus, NDO, Gra- phiques, etc…), le fait que le processus soit tué par un manque de mémoire est relativement gênant.
De plus, deux versions bugfixes sont venues corriger des bugs importants (pour la génération de log et l’ordonnancement ainsi que pour les downtime) et en apporter d’autres.
Au niveau comportement des Pollers, l’utilisation d’agentless consomme beaucoup de ressources au niveau CPU et peu au niveau RAM.
La compatibilité entre Centreon et Shinken est aussi un facteur bloquant car il empêche de distribuer la charge sur plusieurs serveurs car dans la vision Centreon, un Poller représente les rôles d’Arbiter, Scheduler et Broker au minimum et comme ce dernier est le plus important pour dialoguer avec Centreon, il peut difficilement être séparé des autres.

Conclusion et direction prise :

La maquette a été réalisée sur un nombre peu important de services (env. 2300) et la consommation de mémoire était trop importante pour monter au delà. De plus, les deux versions bugfixes ont été sorties avec très peu de temps entre les deux car la 1.2.3 introduisait un bug critique.
Cette situation devenant plus que gênante, j’ai migré la maquette vers Nagios (avec sa RAM divisée par 2) et optimisé ma configuration et mon architecture pour supporter l’utilisation en environnement virtualisé avec les éléments suivants:

  • Utilisation de RAMDISKs.
  • Mettre en mémoire certaines tables NDO.
  • Utilisation de mod_gearman pour déléguer les exécutions des checks à des workers dédiés.

Au passage j’ai rajouté un Poller pour absorber la charge d’exécution et j’ai les indicateurs suivants:

  • Nombre d’hôtes: 630.
  • Nombre de services: 5069.
  • Latence: 0,4s.

Les serveurs Centreon et Nagios sont très peu chargés et avec des workers supplémentaires bien dimensionnés, il peuvent accueillir une charge bien plus grande.
G. LE BRIS