Supervision Nagios sous Ubuntu


Nagios at Home and at Work

Depuis une dizaine d’années déja, plusieurs projets de supervision ont vu le jour au sein de la communauté du logiciel libre. Il suffit pour cela d’aller faire un petit tour sur sourceforge pour se rendre compte de la multitude de projets émergeants autour de la supervision système et réseau.

On notera ainsi, parmi les plus populaires :

Parmi tous les logiciels libre de supervision, Nagios est très certainement le plus répendu et également le plus suivi par la communauté de développeur.

#on installe nagios 3:
cd
wget http://freefr.dl.sourceforge.net/sourceforge/nagios/nagios-3.0.6.tar.gz

tar zxvf nagios-3.0.6.tar.gz
cd nagios-3.0.6
./configure –with-command-group=nagcmd
make all
make install
make install-init
make install-config
make install-commandmode
make install-webconf

#ca c’est si vous voulez les alertes par mails, donc à configurer (sans le #)
#gedit /usr/local/nagios/etc/objects/contacts.cfg

htpasswd -c /usr/local/nagios/etc/htpasswd.users nagiosadmin
#htpasswd va être votre protection pour le web gui,
#ici l’utilisateur nagiosadmin est
#le seul à pouvoir se connecter sur l’interface
#On vous demande un password, vous le rentrez deux fois

cd ..

#Maintenant on s’occupe des plugins:
wget http://freefr.dl.sourceforge.net/sourceforge/nagiosplug/nagios-plugins-1.4.13.tar.gz

tar zxvf nagios-plugins-1.4.13.tar.gz
cd nagios-plugins-1.4.13
./configure –with-nagios-user=nagios –with-nagios-group=nagios
make
make install
#cette ligne permet le lancement de nagios 3 au démarage de votre système,
#passez si vous en avez pas besoin:
ln -s /etc/init.d/nagios /etc/rcS.d/S99nagios

cd ..
rm -rf nagios*
cd /home
mkdir nagios
#on vérifie le fichier de configuration de nagios avant de le lancer:
/usr/local/nagios/bin/nagios -v /usr/local/nagios/etc/nagios.cfg
#on restart apache et on lance nagios:
/etc/init.d/apache2 restart
/etc/init.d/nagios start
#on vérifie qu’il n’y a pas de foirage:
/etc/init.d/nagios status

#####################TERMINE####################

On va sur notre serveur, apache:
http://localhost/nagios/

et on rentre
nagiosadmin
votrepassword

site officiel: nagios

Bien sur le sujet est bien traité sur le forum Ubuntu .

Bon courage .

Nouveau câble sous-marin tunisien


cables-sous-marins-2007

Le câble sous marin optique "Hannibal" relie, via la Sicile, la Tunisie au réseau paneuropéen d’Interoute, apportant une meilleure capacité et une meilleure résistance, afin de satisfaire la demande croissante en services Internet. Ce câble ajoute une nouvelle route pour la Tunisie, à côté des câbles sous-marins Sea-Me-We-4 et Keltra, et offre pour Tunisie Telecom un réseau international plus fiable et sécurisé. La capacité totale du câble est de 3,2 Térabits par seconde, soit plus de sept fois la capacité du câble SEA-ME-WE-4. [www.interoute.fr].

Bienvenue au monde des Télécomms.

Woozweb Un Service de Monitoring Sous Linux


Bonjour , bien que je suis l’évolution de chaque site de mes lecteurs  et mon absence est d’ordre professionnel ,je vous fais part d’une application sur le web intéressante bien sur sous open source . Pour ma part je suis passé par Nagios deja en production .

je resume:

Monitoring

Monitoring

Woozweb est à la fois un observatoire du web et un service de monitoring. En tant qu’observatoire du web, Woozweb recueille une grande quantité d’information concernant les sites significatifs de l’internet français, les analyse et les met à disposition des personnes intéressées.

Woozweb permet de surveiller 5 sites gratuitement et d’obtenir des informations très intéressantes, comme le fameux temps de téléchargement complet de votre page, la disponibilité.

Ce service fournit des graphes de performances, mais permet également d’envoyer des alertes en cas d’indisponibilité ou si une chaine de caractère n’est pas retrouvée…

Woozweb réalise deux types de monitoring :
un monitoring haute-fréquence et un monitoring basse fréquence. Le monitoring haute fréquence est opéré à intervalle de 15 minutes. Le monitoring basse fréquence est opéré de manière hebdomadaire.

je vous laisse découvrir le site ,bon Test .

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 45 autres abonnés