Étiquette : supervision

Catégories
Open-source Planet-libre

Supervision de son PC bureautique avec Glances

D’abord orienté vers la supervision de machines distantes, Glances permet également de surveiller l’ensemble des paramètres systèmes de ses machines bureautique. De plus, depuis sa version 1.7.2 , Glances offre une interface Curses sur l’ensembles des plateformes: GNU/Linux, BSD, Mac OS et même … MS Windows.

Il est en effet fréquent d’observer un ralentissement, voir un blocage de sa machine locale. Nous allons voir comment configurer puis utiliser Glances pour en trouver les causes et ainsi prendre les actions adéquates.

Configuration de Glances

Après installation de Glances sur son système (le plus simple étant de passer par PyPI), un fichier de configuration par défaut est disponible sous /etc/glances/glances.conf sous GNU/Linux (voir ici pour les emplacements sur les autres systèmes). Je vous conseille de copier ce fichier en local dans votre répertoire de configuration standard (~/.config/glances ou $XDG_CONFIG_HOME/glances).

mkdir -p ~/.config/glances
cp /etc/glances/glances.conf ~/.config/glances/

On peut ensuite éditer son fichier selon ses besoins: ~/.config/glances/glances.conf

Voici le fichier que j’utilise sur mon PC portable:

[cpu]
# Limits values for CPU user in %
# Defaults values if not defined: 50/70/90
user_careful=50
user_warning=70
user_critical=90
# Limits values for CPU system in %
# Defaults values if not defined: 50/70/90
system_careful=50
system_warning=70
system_critical=90
# Limits values for CPU iowait in %
# Defaults values if not defined: 40/60/80
# Not easy to tweek...
# Source: http://blog.scoutapp.com/articles/2011/02/10/understanding-disk-i-o-when-should-you-be-worried
#         http://blog.logicmonitor.com/2011/04/20/troubleshooting-server-performance-and-application-monitoring-a-real-example/
#         http://blog.developpeur-neurasthenique.fr/auto-hebergement-iowait-ma-tuer-1-2-vmstat-mpstat-atop-pidstat.html (FR)
iowait_careful=40
iowait_warning=60
iowait_critical=80

[load]
# Value * Core
# Defaults values if not defined: 0.7/1.0/5.0 per Core
# Source: http://blog.scoutapp.com/articles/2009/07/31/understanding-load-averages
#         http://www.linuxjournal.com/article/9001
careful=0.7
warning=1.0
critical=5.0

[memory]
# Defaults limits for free RAM memory in %
# Defaults values if not defined: 50/70/90
careful=50
warning=70
critical=90

[swap]
# Defaults limits for free swap memory in %
# Defaults values if not defined: 50/70/90
careful=50
warning=70
critical=90

[temperature]
# Temperatures in °C for sensors
# Defaults values if not defined: 60/70/80
careful=60
warning=70
critical=80

[hddtemperature]
# Temperatures in °C for hddtemp
# Defaults values if not defined: 45/52/60
careful=45
warning=52
critical=60

[filesystem]
# Defaults limits for free filesytem space in %
# Defaults values if not defined: 50/70/90
careful=50
warning=70
critical=90

[process]
# Limits values for CPU per process in %
# Defaults values if not defined: 50/70/90
cpu_careful=50
cpu_warning=70
cpu_critical=90
# Limits values for MEM per process in %
# Defaults values if not defined: 50/70/90
mem_careful=50
mem_warning=70
mem_critical=90

[monitor]
# Define the list of processes to monitor
# *** This section is optionnal ***
# The list is composed of item (list_#nb <= 10)
# An item is defined:
# * description: Description of the processes (max 16 chars)
# * regex: regular expression of the processes to monitor
# * command: (optional) full path to shell command/script for extended stat
#            Use with caution. Should return a single line string.
# * countmin: (optional) minimal number of processes
#             A warning will be displayed if number of process < count
# * countmax: (optional) maximum number of processes
#             A warning will be displayed if number of process > count
list_1_description=Chromium browser
list_1_regex=.*chromium-browse.*
list_1_countmax=50
list_2_description=OpenVPN
list_2_regex=.*openvpn.*
list_2_countmin=1
list_3_description=Dropbox
list_3_regex=.*dropbox.*
list_3_countmin=1
list_3_command=dropbox filestatus ~/Dropbox

En plus des jeux de limites pour les alertes de CPU, de charge (LOAD) et de mémoire (MEM), je souhaiterai que l’on s’attarde un peu sur la section [monitor] qui permet de mettre en avant une liste de processus jugés importants.

[monitor]
# Define the list of processes to monitor
# *** This section is optionnal ***
# The list is composed of item (list_#nb <= 10)
# An item is defined:
# * description: Description of the processes (max 16 chars)
# * regex: regular expression of the processes to monitor
# * command: (optional) full path to shell command/script for extended stat
#            Use with caution. Should return a single line string.
# * countmin: (optional) minimal number of processes
#             A warning will be displayed if number of process < count
# * countmax: (optional) maximum number of processes
#             A warning will be displayed if number of process > count
list_1_description=Chromium browser
list_1_regex=.*chromium-browse.*
list_1_countmax=50
list_2_description=OpenVPN
list_2_regex=.*openvpn.*
list_2_min=1
list_3_description=Dropbox
list_3_regex=.*dropbox.*
list_3_countmin=1
list_3_command=dropbox filestatus ~/Dropbox

Je défini donc 3 groupes de processus qui vont donner l’affichage suivant dans l’interface de Glances:

capture_142

Supervision de Chromium

Le premier groupe (list_1) permet de surveiller les processus relatifs à mon navigateur Web (Chromium).

Pour cela je lui donne un label (list_1_description) qui est une chaîne de caractères complètement arbitraire (mais limité à 15 caractères):

list_1_description=Chromium browser

Ensuite, il faut définir l’expression régulière qui va permettre de regrouper les processus:

list_1_regex=.*chromium-browse.*

Le problème avec Chromium, c’est qu’il peut être très consommateur de ressources (notamment mémoire) si l’on ouvre un grand nombre de pages. Je configure donc une surveillance du nombre maximum de processus. Glances affichera donc la ligne en rouge si ce nombre est dépassé:

list_1_countmax=50

Je ne défini pas de commande (list_1_command) associé à ce groupe. Donc par défaut Glances va calculer la consommation CPU et la mémoire globale des processus de ce groupe.

Supervision d’OpenVPN

J’utilise souvent un service VPN pour surfer (entre autre…) sur le Web. J’ai donc ajouté une supervision du processus OpenVPN:

list_2_description=OpenVPN
list_2_regex=.*openvpn.*
list_2_min=1

Contrairement à Chromium, je pose ici une alerte si le nombre de processus est inférieur à 1 (donc si OpenVPN n’est pas lancé).

Supervision de Dropbox

Avoir ces fichiers disponibles sur toutes ses machines est devenu pour moi complètement indispensable. La supervision du service Dropbox est faite par Glances de la manière suivante:

list_3_description=Dropbox
list_3_regex=.*dropbox.*
list_3_countmin=1
list_3_command=dropbox filestatus ~/Dropbox

Rien de bien nouveau sur les 3 première lignes, la dernière nécessite cependant quelques explications. La commande (shell) passée en paramètre de (list_3_command) sera exécuté à chaque « check » de Glances (donc par défaut toutes les 3 secondes). Cette commande va demander à Dropbox l’état de synchronisation mon répertoire (voir ce billet pour apprendre à  administrer Dropbox en ligne de commande).

Utilisation de Glances

Votre Glances est maintenant prêt à être utilisé. Donc si vous rencontrez un problème sur votre machine, il faudra ouvrir un terminal et saisir la commande:

glances -ey -C ~/.config/glances/glances.conf

Glances va se lancer et afficher les informations sur votre système:

capture_143

 

En plus de la section [monitor] ou l’on retrouve la supervision de nos groupes Chromium, OpenVPN et Dropbox, on a également l’ensemble des informations systèmes.

Dans le bandeau du haut, les informations sur la CPU, la charge et la mémoire. Les codes couleurs sont standards:

GREEN stat counter is "OK"
BLUE stat counter is "CAREFUL"
MAGENTA stat counter is "WARNING"
RED stat counter is "CRITICAL"

Sur le panneau de gauche, on a les informations moins critiques comme: les débits des interfaces réseau, les capteurs de température, les IO disques et l’espace disque.

Au centre, sur la section [monitor], on retrouve la liste des processus avec, par défaut, un tri « intelligent ». Par exemple, en cas de consommation mémoire excessive, le tri sera automatiquement fait sur la consommation RAM des processus.

Enfin en bas de l’écran, un rappel des dernières alertes.

Pour une description précise des fonctions de Glances, je vous conseille la lecture de la documentation officielle (lisible ici).

Conclusion

Nous arrivons à la fin de ce billet. Je n’ai pas parlé du mode client serveur qui permet de lancer Glances en tache de fond et de l’interroger à la demande mais je pense que ce mode d’utilisation est plus utilise pour la supervision de serveurs.

Si vous avez des configurations spécifiques de Glances (et surtout du [monitor]) pour surveiller vos PC, partager cela (configuration et screenshot) avec nous !

Catégories
Open-source Planet-libre Reseau

Le difficile choix des outils de supervision des réseaux

Je viens de lire le mail d’un lecteur concernant ses interrogations sur le choix des logiciels permettant de surveiller son réseau. Comme c’est une question récurrente dans ma boîte mail et que je pense que ses questions et nos réponses peuvent intéresser d’autres personnes, j’ai décidé de lui répondre directement sur le blog.

On commence par le mail en question:

—

Bonjour Nicolas,

Je me permet de te contacter car je recherche à faire de la supervision sur mon réseau mais je ne sais pas vers quel outils me tourner.

Sachant que mon réseau est relativement petit, quelques switchs, firewalls, routeurs, serveurs, j’aimerais trouver un outils pour surveiller le traffic entrant sortant (réseau LAN connecté à Internet), pinger, savoir la consommation CPU et RAM des serveurs, etc…

J’ai pu voir sur internet et sur ton blog que tu conseillais nagios/centreon/cacti.
Mais j’ai aussi vu une autre solution se commant « The Dude » qui est une appli tournant sur Windows.

Je voulais savoir si avec nagios n’était pas trop lourd pour cela ? Nagios ne nous permet pas de sortir des statistiques sur les performances ? Nous sommes obligé de le couplé à cacti pour que ce soit plus « lisible » ? A ce que j’ai compris Centreon permet de rendre Nagios plus « user frendly », mais qu’apporte-t-il de plus ?

En abstraction de cela, existe-t-il une solution plus simple, plus légère ou plus adapté à ma petite infra au lieu de Nagios ?

Désolé, je sais que vous ne répondez normalement pas aux questions par mail mais je tente quand même ma chance en espérant que vous lisez ce mail un bon jour. 🙂

Kévin

 —

Comme la grande majorité des professionnels de l’informatique, ce lecteur est un peu perdu dans la nébuleuse des solutions de supervision. Ainsi, il mélange la supervision pure (Nagios), la métrologie (Cacti) et les outils de diagnostics élémentaires (ping, iftop…).  A sa décharge, il est vrai qu’il n’y a aucun cours digne de ce nom dans les écoles d’ingénieurs, les DUT ou les cursus universitaires en informatique.

Pour répondre à la question de Kévin, il faut, je pense, commencer par revenir à son besoin.

Il parle de la supervision d’un réseau avec des machines diverses et variées (firewall, routeur, switch, serveurs). On est donc en présence d’un petit réseau (moins de 100 noeuds) avec comme besoin principal un suivi de la consommation des ressources: bande passante de la liaison Internet, CPU et mémoire pour les serveurs. Kévin parle également de ‘ping’, c’est à dire d’un moyen simple de vérifier qu’une machine est bien opérationnelle. D’un autre coté, il n’aborde pas la problématique de la gestion des alertes, c’est à dire des solutions dynamiques pour prévenir une ou plusieurs personnes en cas d’incident.

Dans ce cas précis, je conseillerai donc à Kévin de s’orienter vers la mise en place d’un serveur Munin (lire mon billet sur le sujet), ce qui lui permettra assez facilement de surveiller les serveurs GNU/Linux ou Windows et même les routeurs et switchs Cisco (voir les scripts suivants). Le principal avantage de cette solution est la facilité de mise en place et la légéreté de l’infrastructure. On peut sans problème héberger le serveur Munin sur une machine GNU/Linux existante.

Comme vous pouvez le noter, je ne propose pas de solution pour le ‘ping’ des noeuds. En effet, sans une gestion des alertes, c’est clairement le genre d’outil qui ne sert absolument à rien à moins que Kévin veuille passer ses journée à regarder une page remontant les éventuelles erreurs rencontrées.

Par contre, si son besoin évolue et qu’il est prêt à gérer un véritable serveur de supervision, avec toutes les contraintes de temps et de compétence que cela demande, alors je l’orienterai vers Shinken. Pourquoi Shinken et pas Nagios ? Tout d’abord pour la simplicité de mise en oeuvre (voir mon billet sur l’installation et la configuration initiale de Shinken) mais également pour son module de découverte automatique des noeuds qui est un véritable plus, même pour un petit réseau.

Les informations que je viens de donner ne sont que des pistes et d’autres solutions sont possibles. Je pense notamment à l’utilisation de distributions orientées supervision comme Eyes Of Network ou Fully Automated Nagios (à quand une version Shinken ?).

Qu’en pensez-vous ? Quelles autres pistes pouvez-vous proposer à Kévin ?

Catégories
Nagios Open-source Planet-libre Reseau Systeme Web

La supervision chez Web4All, hébergeur associatif

Ce billet a été rédigé par Jonathan Gaulupeau et à pour double objectif de mettre en avant Web4all, un hébergeur alternatif à but non lucratif et de montrer comment des outils open-source sont utilisés pour assurer une supervision professionnelle de ce type de réseau.


Web4All, qui sommes-nous ?

Web4All est une association à but non lucratif qui a pour but de fournir un hébergement mutualisé de qualité professionnelle au plus grand nombre. Nos offres, plus orientées vers l’utile que vers le tape-à-l’œil, sont parmi les moins chères du marché.

Notre gestion est totalement désintéressée. Tous les acteurs de Web4All sont des bénévoles animés par l’envie de rendre un service de qualité à plus de 2000 clients.

Nous sommes constamment à la recherche du meilleur rapport qualité / prix. Nous étudions pour cela aussi bien des solutions libres que propriétaires. Dans les faits, la quasi-totalité de nous outils est issue de la communauté open-source. Cependant, nos besoins étant parfois très spécifiques, nous développons également nos propres outils.

Pourquoi la supervision ?

Toute entité possédant un ou plusieurs serveurs (quels que soient les systèmes d’exploitation utilisés) se doit de contrôler en permanence leur état. D’autant plus lorsqu’il s’agit, comme nous, de serveurs dont dépend le maintien en conditions opérationnelles des services que nous proposons.

En réalité, ce n’est pas tout à fait le cas, notre infrastructure étant redondée afin de fournir des services à haut taux de disponibilité.

La supervision sous quelle forme, quels outils ?

Je n’ai parlé, jusqu’à présent, que de la supervision en temps réel. Celle qui nous remonte une alarme si un service ne respecte pas des paramètres que nous avons définis. Un technicien peut alors prendre en compte l’alarme, en chercher la cause et, de préférence, la régler. Si, malgré nos précautions, un service est impacté, le technicien en informe les clients par une interface dédiée.

Chez nous, cette supervision est assurée par Nagios.

Quelques services surveillés par Nagios sur un frontal Apache

Toutefois, un autre aspect est important dans la supervision : suivre l’évolution de divers indicateurs sur une période plus ou moins longue. En clair, nous avons besoin, par exemple, pour anticiper l’évolution de nos besoins en terme de stockage, de regarder l’évolution sur l’espace disque que nous avons eu par le passé. Ces indicateurs peuvent nous fournir des informations remontant à des mois, voire des années. Ils nous permettent également de prévoir les pics de charge que subira notre infrastructure. Très pratique pour savoir quand ne pas programmer des tâches d’archivage par exemple. Enfin, cela peut s’avérer très utile lorsqu’il s’agit de réaliser un état de santé général. Nous savons à quoi doivent ressembler nos graphiques, nous pouvons donc voir d’un coup d’œil si tout semble correct.

Cette partie est réalisée par un autre outil : Cacti.

Graphique de trafic réseau réalisé par Cacti

Tous ces indicateurs combinés nous permettent d’évaluer notre qualité, point très important pour la personne chargée de la QoS (Quality of Service). Ils nous permettent également de prévoir nos futurs achats et évolutions de l’infrastructure. Nous pouvons ainsi réaliser tous les tests nécessaires aux évolutions dans un environnement de pré-production, sans travailler dans l’urgence et la panique que pourrait constituer une dégradation de la qualité des services rendus aux clients.

Enfin, nous avons également une carte d’état en temps réel du réseau client de Web4All qui est accessible à tous les clients.

Cette carte se base sur les informations récupérées par Cacti.

Carte d’état en temps réel du réseau client de Web4All

Ce que nous supervisons

Tous ces tests sont réalisés dans Nagios ainsi que dans Cacti.

Les basiques

Les incontournables de la supervision que sont :

  • Le ping -> Un ping est réalisé sur le serveur, nous indiquant s’il est joignable ou non sur le réseau. C’est l’information la plus élémentaire dont nous avons besoin.
  • Le load average -> Le load est récupéré par SNMP. Il nous indique la charge système. Des seuils de criticité sont définis en fonction des habitudes de chaque serveur.
  • La mémoire -> Le taux de mémoire utilisée est récupéré par SNMP. Il nous permet de savoir si une application souffre d’une fuite mémoire par exemple.
  • L’espace disque -> Le taux d’espace libre sur les partitions des serveurs est récupéré par SNMP. Il nous permet d’être alertés avant qu’une partition ne soit pleine.

Le réseau

C’est le cœur de notre activité. Il fait donc l’objet de toutes les attentions.

Nous surveillons le taux de transfert de toutes les interfaces des serveurs. Nous pouvons alors être alertés en cas de pic anormal ainsi qu’étudier l’évolution de la charge réseau afin d’anticiper les besoins en terme de bande passante.

Les services

Chaque service est testé par Nagios grâce à des plug-ins.

Ces plugins sont soit récupérés sur la plateforme d’échange Nagios Exchange soit écrits spécifiquement pour Web4All.

Voici quelques exemples :

  • Serveur DNS -> Test de résolution de nom
  • Serveur Mail -> Test des protocoles POP, IMAP, SMTP, état de la queue des mails, etc.
  • Frontaux Apache -> Test des Apache Server Status
  • Load Balancers -> Vérification du nombre de serveurs dans le pool
  • Serveurs SQL -> Test de connexion à une base de données

Les aide-mémoires

Certains tests n’ont pour but que de nous rappeler de réaliser une action bien précise.

Par exemple, tous nos certificats SSL sont testés afin de nous remonter une alerte plusieurs semaines avant leur date d’expiration.

Conclusion

La supervision est un point essentiel chez Web4All. Elle nous permet d’avoir une meilleure réactivité grâce aux alertes remontées par Nagios, mais elle nous permet également de mieux préparer l’avenir grâce aux graphiques réalisés par Cacti.

Enfin, grâce à la supervision, nous pouvons également fournir à nos clients le taux de disponibilité réel de nos services.

 

A propos de l’auteur: Jonathan est expert sur le logiciel de conception mécanique CATIA V5, la « crise » du secteur automobile l’a poussé à s’orienter vers l’administration des systèmes Unix. Il est aujourd’hui Ingénieur Systèmes & Réseaux. Depuis 2009 il s’est engagé dans l’association Web4All ou il fait partie du Conseil d’Administration et ou il s’occupe de l’administration des serveurs ainsi que de leur supervision.

A propos de Web4All: Web4all est un hébergeur associatif qui propose des hébergements de site web à faible coût ainsi que la vente de nom de domaine et un service emails.

J’espère que comme moi cet article vous a intéressé. N’hésitez pas à poser des questions à Jonathan dans les commentaires de ce billet, je suis sur qu’il se fera un plaisir de vous répondre.

Catégories
Open-source Reseau

Ntop et la supervision réseau via Netflow/IPFix

NTop est un outil libre (licence GPL) de supervision réseau permettant d’afficher en temps réel les informations collectées dans une interface Web. Pour effectuer cette collecte, NTop se base sur la librairie libpcap (du projet TCPDump) pour capturer les flux transitant sur les interfaces réseau de la machine ou est installé le logiciel. Les dernières versions de NTop permettent également de collecter des informations venant de machines distantes grâce aux protocoles SNMP et Netflow/IPfix. C’est sur ce dernier point que nous allons nous focaliser dans ce billet.

Lire la suite « Ntop et la supervision réseau via Netflow/IPFix »
Catégories
Blog Nagios Open-source

Et si on parlait supervision des blogs ?

Vous connaissez sans aucun doute les blogs Presse-Citron, Al-Kanz, Nowwhere else ou Le journal du Geek ? Ces derniers ont la caractéristique de faire, en partie, vivre leurs auteurs. Et oui le Web 2.0 entre dans la phase de « professionnalisation ». Ces blogs deviennent donc des points sensibles dont l’indisponibilité ou dis fonctionnement peut entrainer une image négative ainsi qu’une baisse des revenus (pas vrai Korben;)). Si l’on parle souvent de la qualité intrinsèque des offres des hébergements, on parle moins de la supervision des serveurs et des services qui la compose.

C’est quoi la supervision ?

C’est une matière à part entière dans l’informatique, elle permet d’anticiper et d’alerter un administrateur (le blogueur ou une personne mandatée) d’éventuel problèmes sur ses site.

Dans le cas précis d’un blog, on peut citer les fonctions de supervision suivantes:

  • le serveur est allumé et répond au niveau IP (on arrive bien à le pinguer…)
  • le serveur Web est lancé et répond bien aux requêtes dans un temps imparti
  • la base de donnée MySQL est lancée et répond bien aux requêtes
  • la charge CPU du serveur n’atteint pas un seuil critique
  • la mémoire libre du serveur ne descend pas sous un seuil critique
  • l’espace disque libre de descend pas en dessus d’un seuil critique
  • la charge réseau ne dépasse pas un seuil critique
  • …

L’archivage de ces informations, la présentation sous forme de rapports graphiques et l’expédition d’alertes (par mail, SMS, Twitter…) font également partie de cette supervision.

La supervision permet également d’anticiper les problèmes de dimensionnement des serveurs hébergeant les blogs. En effet, une trop faible fréquence de CPU ou une mémoire insuffisante pourront facilement être détectées. A l’inverse, on pourra facilement voir si un serveur est surdimensionné par rapport au besoin (et donc optimiser ses coûts d’hébergement).

Quels sont les solutions actuelles ?

Il est vrai qu’actuellement l’offre de services en ligne pour la supervision des blogs personnels (qu’ils soient professionnel ou non) n’est pas très riche. Certains services voient le jour (surtout de l’autre coté de la manche ou le nombre de blogueurs pro est plus important).

On peut citer par exemple Hyperic, Server Density ou Site24x7.  Server Density est le dernier que j’ai découvert, il permet un supervision simple de son serveur (gratuit pour 1 serveur puis compter $15 par serveur par mois si vous voulez superviser plusieurs serveurs à partir du même compte).

Une autre solution est de s’installer soit même un serveur de supervision open-source. Des logiciels comme Nagios sont maintenant intégré dans des distribution GNU/Linux de type live-cd (FAN par exemple). Je ne vous cache pas que ces outils demandent quand même une bonne connaissance système et réseau. Il faudra que le serveur  soit hébergé sur une machine dédié sur un réseau différent des serveurs à superviser (par exemple une machine à votre domicile allumée en permanence).

Conclusion

Je pense que nous sommes seulement au début de la prise en compte de cette problématique de supervision par les blogueurs. Les offres de service en ligne vont surement apparaître dans les prochains moins pour répondre à cette demande et je ne serais pas surpris qu’un mastodonte comme gOOgle propose une solution.

Et vous, vous en êtes ou avec la supervision de votre site/blog ?

Catégories
Nagios Open-source Reseau

VNStat surveille votre bande passante

Obsolete
Merci de consulter ce billet plus récent.

VNStat est un petit utilitaire bien sympathique pour surveiller la bande passante utilisée sur les interfaces réseaux de ses machines GNU/Linux ou BSD.

Installation de VNstat

Sous GNU/Linux Ubuntu:

# sudo apt-get install vnstat

Sous FreeBSD:

# pkg_add -r vnstat

Puis ajouter la ligne suivant dans votre crontab (seulement sous FreeBSD):

*/5 * * * * root if [ -x /usr/local/bin/vnstat ] && [ `ls -l /var/db/vnstat/ | wc -l` -ge 1 ]; then /usr/local/bin/vnstat -u; fi

Déclaration des interfaces réseaux à surveiller

Imaginons que la machine à surveiller est un routeur avec deux interfaces réseaux: em0 qui est l’interface coté Internet (c’est à dire l’interface connecté à votre modem/routeur DSL) et em1 qui est l’interface coté LAN (celle connecté à vos machines).

Il faut donc effectuer la déclaration suivante qui va créer automatiquement les fichiers de base de données.

# vnstat -u -i em0 –nick « Internet »
# vnstat -u -i em1 –nick « LAN »

Utilisation de VNStat

Le crontab que nous avons configuré dans la première étape de l’installation est programmé pour se lancer toutes les 5 minutes. Il faut donc attendre un petit moment avant de pouvoir utiliser VNStat.

La première commande permet d’afficher un résumé des statistiques par interface.:

# vnstat
rx      /     tx      /    total    /  estimated
Internet (em0):
yesterday    421.40 MB  /  984.95 MB  /    1.37 GB
today     91.20 MB  /   86.35 MB  /  177.54 MB  /     294 MB

LAN (em1):
yesterday    626.97 MB  /  242.34 MB  /  869.32 MB
today      1.46 GB  /  565.40 MB  /    2.01 GB  /    3.36 GB

Statistiques sur la dernière heure avec l’option -h:

# vnstat -h
Internet (em0)                                                           14:25
^                                                        r
|                                                        r
|                                                        r
|                                                        r
|                                                        r
|                                                        r
|                                                        r
|     r                                                  r     r
|     r                                                  r  r  r
|  r  r  r                  t                 t  t       r  r  rt r  r
-+—————————————————————————>
|  15 16 17 18 19 20 21 22 23 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14

h   rx (kB)    tx (kB)      h   rx (kB)    tx (kB)      h   rx (kB)    tx (kB)
15     117458      17933    23       7006      69069    07       4913      31545
16     205687      21665    00      26175      23108    08      61198      19855
17     112410      14211    01       5373       5281    09     682414      39748
18       4981       6441    02       3734       4623    10     191760      16684
19       5792      42644    03       3822       4842    11     238408      95350
20       4211       4416    04      31824      23303    12     135037      37811
21       5571       6457    05      17429     111179    13      91544      24793
22       5680      32557    06       6706     135740    14      40126       6404

Statistiques journalières avec l’option -d:

# vnstat -d
Internet (em0)  /  daily

day         rx      |     tx      |  total
————————+————-+—————————————-
14.04.    626.97 MB  |  242.34 MB  |  869.32 MB   %%%%%%%:::
15.04.      1.47 GB  |  566.67 MB  |    2.02 GB   %%%%%%%%%%%%%%%%%%:::::::
————————+————-+—————————————-
estimated     2.43 GB  |     937 MB  |    3.35 GB

Statistiques hebdomadaire avec l’option -w:

# vnstat -w
Internet (em0)  /  weekly

rx      |       tx      |    total
—————————-+—————+————–
last 7 days      2.09 GB  |    810.27 MB  |      2.89 GB
current week      2.09 GB  |    810.27 MB  |      2.89 GB
—————————-+—————+————–
estimated      5.67 GB  |      2.14 GB  |      7.82 GB

Statistiques mensuelle avec l’option -m:

# vnstat -m
Internet (em0)  /  monthly

month         rx      |      tx      |   total
————————-+————–+————————————–
Apr ’09       2.09 GB  |   810.27 MB  |     2.89 GB   %%%%%%%%%%%%%%%%::::::
————————-+————–+————————————–
estimated      4.31 GB  |     1.63 GB  |     5.93 GB

D’autres options permette d’avoir une vu en « temps réel » de la consomation de bande passante:

Calcul sur les 5 dernières secondes:

# vnstat -tr
19 packets sampled in 5 seconds
Traffic average for em4

rx           0.14 kB/s              2 packets/s
tx           0.13 kB/s              1 packets/s

Calcul instantané:

# vnstat -l
Monitoring em0…    (press CTRL-C to stop)

rx:       2.36 kB/s    11 p/s            tx:       1.46 kB/s    13 p/s

Le texte c’est bien , mais les graphes c’est mieux

Si vous avez l’âme d’un futur manager, vous êtes en train de vous dire que cet utilitaire n’est pas mal mais qu’une présentation sous forme de graphe ferait un plus bel effet dans mon prochain rapport… Heureusement, les auteurs de VNStat ont pensé à vous et vous proposent VNStati.

L’utilisation est presque la même que pour VNStat. La première commande permet de génèrer (au format PNG) un résumé des statistiques par interface (utiliser l’option -i pour fixer l’interface):

# vnstati -i em0

Statistiques sur la dernière heure avec l’option -h:

# vnstati -h

Statistiques journalières avec l’option -d:

# vnstati -d

Statistiques mensuelle avec l’option -m:

# vnstati -m

Conclusion

Bien que VNStat ne boxe pas dans la même catégorie que des logiciels comme Cacti, je trouve que c’est un bon complément à des outils comme iftop ou ntop (en beaucoup plus léger pour ce dernier). Il existe même un projet parallèle pour intégrer ces rapports dans un site Web à partir d’un front-end PHP (projet vnStat PHP frontend).

Catégories
Nagios Open-source Reseau Systeme

Le serveur de supervision libre – PART 4

Nous arrivons bientôt à la fin de l’installation de notre serveur de supervision. Avec Nagios et Centreon il est parfaitement opérationnel. Je trouve cependant qu’il manque encore à Centreon des fonctions de graphes évoluées. C’est pour cela que je propose d’ajouter sur notre bébé un serveur Cacti.

PART 1 – Installation du système d’exploitation GNU/Linux
PART 2 – Installation de Nagios
PART 3 – Installation de Centreon
PART 4 – Installation de Cacti

Lire la suite « Le serveur de supervision libre – PART 4 »
Catégories
Nagios Open-source Reseau Systeme

Le serveur de supervision libre – PART 3

Les deux premiers billet de cette série nous ont permis d’installer le coeur de notre serveur de supervision: le logiciel Nagios. Nous allons donc maintenant nous occuper de l’enrobage: l’interface Web d’administration Centreon.

PART 1 – Installation du système d’exploitation GNU/Linux
PART 2 – Installation de Nagios
PART 3 – Installation de Centreon
PART 4 – Installation de Cacti

Centreon offre à Nagios une nouvelle interface et lui apporte de nouvelles fonctionnalités. Il va rendre la configuration de Nagios plus facile et d’avoir une interface graphique améliorée. C’est une interface qui pour moi n’est pas obligatoire mais qui peut s’avérer utile dans certains cas:

  • si une équipe doit gérer le serveur Nagios, il sera plus facile de les former en utilisant Centreon
  • si vous êtes allergique aux fichiers de configuration au format texte
  • si vous êtes un “accro” aux interfaces Web

Attention toutefois, Centreon va générer des fichiers de configuration de Nagios à sa manière. Vous allez donc perdre tout le contrôle sur ces fichiers… Bref si vous êtes un administrateur système soigneux, qui prend soit de commenter/archiver voir gérer en configuration ce type de fichiers, je vous conseille de passer votre chemin et d’attendre le prochain billet de cette série.

Lire la suite « Le serveur de supervision libre – PART 3 »

Catégories
Open-source Reseau Systeme

Installation de Zenoss sous GNU/Linux

Tout comme Nagios, Zenoss est un outil de supervision open-source gratuit (il existe une version commerciale comportant plus d’options). Il se base sur une application Web qui va surveiler les noeuds de votre réseau et générer des rapports si chers aux yeux des décideurs informatiques…

Nous allons, dans ce premier billet, voir comment installer Zenoss Core (c’est à dire la version open-source sous licence GPL) sur une distribution GNU/Linux Fedora.

Lire la suite « Installation de Zenoss sous GNU/Linux »
Catégories
Reseau

Cacti, le complement idéal de Nagios !

Nous allons dans ce post parler de l’installation de Cacti, qui me semble offrir des fonctions complémentaires à Nagios déjà évoqué dans ce blog.

C’est quoi donc ?

Cacti est une interface Web écrite en PHP permettant de gérer des graphes RRD. Ces graphes RRD peuvent avoir comme source le résultat de n’importe quelle requêtes SNMP ou d’un simple script. Cela permet donc une large possibilitée d’utilisation. La gestion se fait par des menus relativement simple à utiliser (il faut tout de même un temps de prise en main mais la documentation est très bien faite).

Configuration nécessaire

Un operating system (Unix de préference)
Un serveur Web fraichement installé (Apache par exemple).
Une base de données MySQL.
Les sources de Cacti ou un package pour votre operating system.

Installation de cacti (exemple donnée pour une Fedora Core 6)

Update: cliquez ici pour voir un nouvel article sur une procédure d’upgrade en version 0.8.7 

Il faut commencer par installer les utilitaires SNMP:

# yum install net-snmp net-snmp-utils

Puis Cacti en lui même (on utilise le package du repos extra):

# yum install cacti

Avant toute chose, nous allons ajouter la configuration nécessaire pour que le serveur Web (Apache) prenne en compte cacti:

# cd /etc/httpd/conf.d/
# vi cacti.conf
Alias /cacti/ /usr/share/cacti/
<Directory /cacti/>
Options Indexes
AllowOverride None
Order allow,deny
Allow from all
</Directory>
# apachectl restart

Après vous être placé dans le répertoire d’installation, il faut créer la base de donnée MySQL (on part sur l’hypothése ou la base de donnée est sur le même serveur):

# mysqladmin –user=root create cacti
# mysql cacti < cacti.sql
# mysql –user=root mysql
mysql> GRANT ALL ON cacti.* TO cactiuser@localhost IDENTIFIED BY ‘somepassword’;
mysql> flush privileges;

… et la configurer en éditant le fichier include/config.php:

# vi include/db.php
<?
/* make sure these values refect your actual database/host/user/password */
$database_type = « mysql »;
$database_default = « cacti »;
$database_hostname = « localhost »;
$database_username = « cactiuser »;
$database_password = « password »;
$database_port = « 3306 »;
?>

Nous pouvons alors lancer un navigateur Web sur l’URL: http://votreadresseip/cacti/
Au premier lancement, une page de configuration va apparaître. Vous devez choisir RRD (dernière version).

Il est parfois nécessaire de changer les droits du répertoire de travail de Cacti:

# cd /usr/share/cacti/
# chown -R cacti rra/ log/

La dernière étape va automatiser le lancement de cacti toutes les 5 minutes:

# crontab -e -u cacti
*/5 * * * * /usr/bin/php /usr/share/cacti/poller.php > /dev/null 2>&1

Et voila, vous avez maintenant un bel outils pour générer toutes les courbes RRD possibles 😉