Supervision IT Open Source


Etant donné les circonstances je vais me permettre de partagez avec vous ,certains outils de supervision open source ,bien que les opérateurs télécoms offrent de meilleures plateforme dédié pour leurs équipements ,d’autres développe des solutions complémentaires pour minimisez leur factures d’achat de solutions de supervisions  .

dans mon cas : IBM Netvoli Netview (avec license) ,TNMS de Siemens (avec license) , SnmpC 4 avec license , SolarWinds (Piraté)

Ma première expérience s’est orienté au debut par la solution la plus connu de Tous qui s’appelle Nagios .

Nagios (anciennement appelé Netsaint) 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 GPL.

C’est un programme modulaire qui se décompose en trois parties :

  1. Le moteur de l’application qui vient ordonnancer les tâches de supervision.
  2. L’interface web, qui permet d’avoir une vue d’ensemble du système d’information et des possibles anomalies.
  3. Les plugins, une centaine de mini programmes que l’on peut compléter en fonction des besoins de chacun pour superviser chaque service ou ressource disponible sur l’ensemble des ordinateurs ou éléments réseaux du SI.

La deuxièmement expérience a était Cacti pour la gestion SLA .

Open SLA

Équivalent de base Munin ou MRTG .

Cette Solution bien sur a était implanté sous la Distribution Ubuntu . Merci a la Communauté Tunisienne et française pour son soutien .
ce lien vous donnera plus de détails sur l’installation . le lien

La Troisième expérience : FAN Fully Automated Nagios

FAN stands for "Fully Automated Nagios". FAN goals are to provide a Nagios installation including most tools provided by the Nagios Community. FAN provides a CDRom image in the standard ISO format, making it easy to easilly install a Nagios server.
Added to this, a wide bunch of tools are including to the distribution, in order to improve the user experience around Nagios.

Une compilation bien rempli qui facilite aux etudiants de mettre en place un systeme de supervision et de monitoring et la gestion des SLA (Service level agrement ) deja discuté sur le blog .

FAN is based on a minimal CentOS. Added to this, all other CentOS packages are still available, once FAN is installed, so that you keep all advantages of CentOS along with Nagios and other tools facilities since they are preinstalled and configured for you.

Software provided

Here is the list of tools provided by FAN:

  • Nagios: Core monitoring application
  • Nagios plugins: plugins to monitor servers
  • Centreon: web frontend for Nagios (Centreon is one of the better tools for that!)
  • NagVis: a great tools for configuring maps
  • NDOUtils: Nagios module to store monitoring data in MySQL
  • NRPE: the check_nrpe plugin (NRPE daemon is not provided)
  • NaReTo (Nagios Reporting Tools): a great tool for getting availabilty report

la Quatrieme Experience : EON

EyesOfNetwork, encore appelé EON, (pour faire classe dans les salons vous pouvez prononcer ï-aune :P ) est une distribution Linux crée pour être une appliance logiciel orienté supervision ITIL. Cette application se veut simple, pragmatique et utile.

Autrement dit, 99,9% de son administration/utilisation se fait via le Web et vous n’avez pas besoin d’être expert en solution Libre et autres linuxerie shello-hèssehèssehacho-perlienne pour l’utiliser.

EyesOfNetwork est accessible via une interface Web unique dont l’objectif est de réunir les différents acteurs d’un système d’informations (DSI, Administrateurs, Techniciens, Opérateurs, …). Chacun des ces acteurs dispose d’une vue correspondant à son métier.Toutes les informations sont consolidées en Base de Données MYSQL ou BERKELEY.

EyesOfNetwork est un produit sous licence GPL2 sponsorisé et proposé par APX dans le cadre de prestations de services (Intégration, Télé-service, Support téléphonique et Tierce Maintenance Applicative).

Téléchargement ….


La dernière Experience de cette année est OpenNMS …


http://www.opennms.org/wiki/Main_Page

L’application OpenNMS a été créée par Day One en tant que solution de gestion de réseaux destinée aux entreprises, et a été développée selon le modèle open 


Maintenant je vous laisse le choix chers Etudiants ou professionnels du métier a travaillez sur une solution qui vous rapproche le plus les uns des autres sinon ca va etre comme ca .

Bonne lecture .

la Morale : Mac pour le graphisme Palm pour la mobilité Windows pour le solitaire

EtherApe,Iftop,Bmon…


iftop-bmon-etherape

Pour compléter l’idée de Freefoxtv.net concernant les outils de Monitoring du moins pour voir son traffic réseau soit de sa carte ou de son reseau local .

sudo apt-get install bmon

bmon : bandwidth monitor

sudo apt-get install ethearpe

Etherape est un moniteur graphique avancé de connexions et flux TCP/IP en temps réel .

et enfin Iftop

La commande iftop permet d’analyser la consommation de bande passante de sa machine linux. Iftop affiche à la manière de top ou htop les débits réseaux des 

sudo apt-get install iftop

iftop -i ethxx

la commande en plus riche .

iftop -h | -npbBP -i interface -f filter code -N net/mask

Bien sur ce sont la des outils parmi d’autres que grace a mon ami Athmane j’ai decouvert tres utile dans des cas .

Merci a toi freefoxtv.

Service Level Agrement ou Convention de Service


sla panel

Le Service Level Agreement ou SLA est une expression anglaise qui peut être traduite par « Accord de Niveau de Service » ou par « Engagement de Service », ou encore plus simplement « Convention de Service ».

Le SLA est le contrat ou la partie du contrat spécifiant l’ensemble des niveaux de services à fournir par le prestataire informatique au(x) client(s). Il s’agit d’un engagement formel et contraignant, établi entre un prestataire et son (ses) client(s).

Le SLA est utilisé dans la plupart des contrats d’outsourcing et permet de :

  • identifier et définir les besoins du client ;
  • fournir un cadre général de compréhension des deux parties ;
  • simplifier les problèmes complexes ;
  • encourager les dialogues en cas de conflit ;
  • éliminer les attentes irréalistes ;
  • être utilisé comme un instrument de marketing par les services commerciaux et techniques des ASP;
  • transformer une obligation de moyen en obligation de résultat.

L’ASP (Application Service Provider), traduit en français par « Fournisseur d’Applications Hébergées » (FAH), est une société qui fournit, sur abonnement, un accès à des applications ainsi que de l’infrastructure et la maintenance nécessaires.

Contrairement à l’outsourcing classique, l’ASP ne reprend pas l’infrastructure IT existante du client pour gérer ses ressources informatiques, mais fournit au client un accès à sa propre infrastructure IT.

Dans la mesure où l’ASP doit combiner des compétences dans le service, la technologie des réseaux et leur gestion mais aussi dans l’administration, l’intégration, la gestion et le support des applications, il sera amené à s’octroyer plusieurs partenaires.

Toutefois, sur la base du contrat ainsi que du SLA, l’ASP restera le seul responsable, à l’égard du client, de la livraison du service. Il maintiendra donc de nombreuses relations avec des sociétés telles que des fournisseurs de système d’exploitation, des fournisseurs de hardware, des fournisseurs d’équipement de réseaux, des fournisseurs de réseaux, d’applications, et d’autres fournisseurs d’infrastructure, etc…

Il s’agira notamment des prestataires suivants :

  • ISV (Independent Software Vendor – vendeur indépendant de logiciels),
  • AIP (Application Infrastructure Provider – fournisseur d’infrastructure d’applications),
  • NSP (Network Service Provider – fournisseur de services réseaux),
  • VAR (Value Added Reseller – revendeur à valeur ajoutée),
  • SI (Systems Integrator – intégrateur de systèmes), …

La rédaction du SLA

Le SLA fait partie intégrante du contrat entre l’ASP et son client. Il fait souvent l’objet d’une annexe à ce contrat.

L’office Mondial de la Propriété Intellectuelle (OMPI) et l’ASPIC ont mis au point des Best Practices, afin de prévenir certains litiges fréquents entre l’ASP et son client. Celles-ci portent sur l’identification de l’infrastructure, la connectivité, la sécurité, l’application, l’implémentation et la maintenance des services.

Le SLA en lui-même doit prévoir un maximum de situations pour concentrer les obligations et le niveau de service à fournir.

On y retrouvera le temps imparti dans lequel les services seront fournis, la description et l’étendue des services qui seront fournis, ceux qui ne devront pas être fournis, un calendrier des implémentations, les utilisateurs du service et leur localisation.

Le cœur du SLA réside dans les clauses fixant le niveau des services attendus, à savoir le taux de disponibilité et de fiabilité du service (par exemple : les heures et les jours pendant lesquels le service sera disponible).

Sera également précisé le temps de réponse qui devra être octroyé au fournisseur en cas de plainte pour dysfonctionnement (par exemple, prévoir que 95% des problèmes seront résolus après une heure à compter de la plainte).

Les conditions de payement devront être également très précises ainsi que les procédures qui en découlent. Il faudra de même prévoir les modalités des licences de logiciels, les titulaires des droits y attenant, et leurs conditions financières, la propriété des données, leur protection, leur confidentialité ainsi que leur récupération (dans quelles circonstances, suivant quelle procédure et conditions).

Un autre point crucial concerne la détermination des obligations du client, comme l’ « updating » de son infrastructure pour assurer la compatibilité avec les services de l’ASP, la formation de son personnel, la fourniture d’informations correctes à ses utilisateurs…

S’ensuit la phase de « reporting ». Le SLA doit examiner concrètement comment les services seront contrôlés, avec quels outils, suivant quelle procédure d’audit, par qui, à quelle fréquence etc., pour pouvoir éventuellement engager ensuite la procédure de plainte qui sera très précisément décrite (la personne à contacter, la manière de formuler les plaintes, les procédures d’urgence, les temps maximum dans lesquels l’ASP devra réagir etc.). Des outils de support à toute ces procédures doivent également être pointés, leur niveau et nature (helpdesk, combien d’opérateurs y sont disponibles, de quelle heure à quelle heure, quel jour, qui sont les personnes payées pour répondre à toute question, qui est responsable pour le « service clientèle » au sein de l’ASP, …).

Par ailleurs, il sera fait expressément mention des crédits de service, compensations financières, pénalités ou autres conséquences de la fourniture défectueuse des services.

Les clauses de sécurité revêtent également une importance capitale au sein d’un SLA. Comment prévoir que la sécurité d’accès au système est valablement assurée ? Il sera donc nécessaire de prévoir une procédure de recouvrement de données et des copies de sauvegarde.

L’étendue de la responsabilité, de l’indemnisation de l’ASP vis-à-vis des tiers, et des autres intervenants dans le projet (ISV, VAR, …) doit être définie. En particulier, seront visées les limitations de sa responsabilité et la prévision des cas de force majeure applicables.

Enfin, des modes de résiliation précis devront être stipulés, ainsi que d’éventuels modes de résolution des litiges (tels que prévus par les recommandations de l’ASPIC par exemple).

Pourquoi un SLA peut-il échouer ?

La cause principale de litiges réside dans le processus de négociation. En effet, dans son appel d’offres, le client définira ses besoins et ses objectifs. Le fournisseur de services IT, quant à lui, devra délimiter son périmètre de services, et de maintenance éventuelle, qu’il pourra fournir au client. Ce processus de rapprochement n’est pas aisé, et devra parfois nécessiter l’intervention de tiers.

Le Service Level Management, n’est pas toujours bien mis en place. Vu la complexité du secteur de l’IT et du marché de l’ASP, un contrôle est très difficile mais s’avère, pour la même raison, essentiel. Le client se doit donc de mettre en place un système spécialement conçu (logiciel par exemple) pour effectuer le suivi des niveaux de service se trouvant dans le SLA , ainsi que le contrôle des procédures de rapport, de modifications des services ou de la gestion des conflits.

Les spécifications sont souvent lacunaires : soit qu’elles ne sont pas claires, soit qu’elles sont incomplètes.

Le manque de clarté se retrouve en effet souvent dans la délimitation du paramètre « disponibilité ». La disponibilité d’un réseau, par exemple, est souvent spécifiée par une figure de pourcentage de disponibilité. Cependant, on oublie souvent de spécifier l’effectivité d’un service au sein du plan commercial du client. Si on stipule une disponibilité de 98%, comment la mesurer, à quoi correspondent-elle et quels sont les 2% restants ?

Quant aux services en tant que tels, leur description est souvent incomplète. Par exemple, des clauses à propos de la sécurité et des dégâts qui peuvent être causés doivent être définis de manière exhaustive. Trop souvent, ces derniers ne sont pas bien classifiés ou quantifiés, ce qui entraîne des confusions et incompréhensions à propos des responsabilités de chacun, et donc parfois … de longues procédures judiciaires.

Par ailleurs, la plupart des SLA se concentrent trop sur les efforts et moyens déployés par un prestataire de service dans le cadre de tel ou tel problème, en oubliant qu’il y a un résultat à atteindre. Au lieu de prévoir « le service X fournira à votre société le résultat Y », l’on prévoit «  dans le cas où le système se bloque, le prestataire X apportera son service à concurrence du temps Y ».

Le prix est souvent mal défini. Si l’on rentre dans une logique de forfait, il est alors très difficile pour le client de déterminer un rapport prix/exécution.

Enfin, au vu de tous les éléments précités, le SLA sera souvent considéré et rédigé comme un document hautement technique, dont la compréhension est réservée à des initiés…

Les défis du SLA sont donc de dépasser ce cadre technique de la fourniture d’un service pour parvenir à une compréhension des besoins de chacun.

Thibault Verbiest
Avocat aux barreaux de Paris et de Bruxelles (Ulys).

En Algérie , ce systéme est offert dans nos plateforme que ca soit l’Opérateur National ou les Opérateurs privés . Alors Messieurs les administrateurs avant de chercher le coupable chercher les Problémes ,Certains Equipements parlent .

Ou tout simplement faites des Rapports d’analyse .

Suivre

Recevez les nouvelles publications par mail.

Rejoignez 47 autres abonnés