Catégories
Developpement Open-source Planet-libre

Internationaliser ses programmes Python

Bien que je pense qu’il vaille mieux utiliser un logiciel en Anglais plutôt qu’un logiciel (mal traduit) en Français, la problématique de l’internationalisation des développements viendra tôt ou tard sur le tapis si vous avez des utilisateurs de plusieurs pays.

Nous allons donc dans ce billet aborder le sujet spécifique de la traduction d’un logiciel écrit dans le langage Python. Pour cela nous allons nous baser sur un programme simple et connu de tous: un bon vieux Hello World !

J’ai créé un projet GitHub avec l’ensemble des fichiers don je parle dans ce billet.

On commence par créer, dans un répertoire de travail, la structure suivante:

mkdir -p i18n/fr/LC_MESSAGES
touch hello.py
 Ce qui va donner:
.
├── hello.py
└── i18n
 ├── fr
     └── LC_MESSAGES

On édite une première version du script Python hello.py:

#!/usr/bin/env python

__appname__ = 'hello'
__version__ = "1.0"
__author__ = "Nicolas Hennion <nicolas@nicolargo.com>"
__licence__ = "LGPL"

def main():
    print("Hello world !")

if __name__ == "__main__":
    main()

Sans surprise, l’exécution de ce programme donne:

$ python hello.py
Hello World !

1. Rendre son code compatible

La première étape est de rendre notre code compatible avec l’internationalisation: Pour cela, on édite notre programme en effectuant les modifications suivantes:

#!/usr/bin/env python

__appname__ = 'hello'
__version__ = "1.0"
__author__ = "Nicolas Hennion <nicolas@nicolargo.com>"
__licence__ = "LGPL"

import gettext
gettext.install(__appname__)

def main():
    print(_("Hello world !"))

if __name__ == "__main__":
    main()
On notera donc:
  • l’inclusion de la librairie gettext
  • l’appel à la fonction gettext.install permettant de charger, s’il existe, le fichier de langue correspondant à la langue du système
  • le repérage de la chaîne de caractère à traduire en la faisant précéder par le caractère _: print(_(« Hello world ! »))

2. Génération du modèle de traduction

On passe ensuite à la création du modèle de traduction général (.pot) qui va servir de support de base pour toutes les langues. On utilise l’outil système suivant:

xgettext --language=Python --keyword=_ --output=./i18n/hello.pot ./hello.py

Attention, ce n’est pas dans ce fichier qu’il faut effectuer la traduction. Ce n’est qu’un modèle.

3. Génération du fichier de traduction

On va donc se retrouver avec un fichier ./i18n/hello.pot. C’est à partir de ce modèle que nous allons créer le fichier de traduction pour un langage donnée.

Par exemple, la création du fichier de traduction Francais (fr_FR) se fait:

msginit --input=./i18n/hello.pot --output=./i18n/fr/LC_MESSAGES/hello.po

4. Traduire votre programme

Il reste ensuite le travail le plus manuel à faire: la traduction en elle même…

Pour cela, on édite le fichier i18n/fr/LC_MESSAGES/hello.po:

...
#: hello.py:12
msgid "Hello world !"
msgstr "Bonjour le monde !"
...

5. Compiler le fichier de traduction

Une fois ce fichier renseigné il faut le compiler. C’est le résultat de cette compilation, qui se présente sous la forme d’un fichier .mo qui sera exploité par votre logiciel.

Pour compiler le fichier i18n/fr/LC_MESSAGES/hello.po vers le fichier i18n/fr/LC_MESSAGES/hello.mo:

msgfmt ./i18n/fr/LC_MESSAGES/hello.po --output-file ./i18n/fr/LC_MESSAGES/hello.mo

Il ne reste plus qu’à installer le fichier de traduction compilé (donc le fichier .mo) dans le répertoire standard de votre système d’exploitation:

Installation du fichier de traduction compilé sur le système:

sudo cp i18n/fr/LC_MESSAGES/hello.mo /usr/share/locale/fr/LC_MESSAGES/hello.mo

Note: cette installation devra normalement être faite par votre script d’installation (Makefile ou setup.py).

Il ne reste plus qu’a tester votre programme et oh miracle:

$ python hello.py
Bonjour le monde !

6. Mettre à jour votre fichier de traduction

En cas de mise à jour de votre programme (ajout ou suppression de chaînes de caractères à traduire, il n’est pas la peine de out recommencer. Il faut dans ce cas, utiliser les commandes suivantes:

xgettext --language=Python --keyword=_ --output=./i18n/hello.pot ./hello.py
msgmerge --update --no-fuzzy-matching --backup=off ./i18n/fr/LC_MESSAGES/hello.po ./i18n/hello.pot

Compléter la traduction puis re-compiler pour obtenir la nouvelle version du fichier .mo:

msgfmt ./i18n/fr/LC_MESSAGES/hello.po --output-file ./i18n/fr/LC_MESSAGES/hello.mo

7. Automatisation

Il est bien sûr conseillé d’automatiser les taches que l’on vient de voir, idéalement par un script. Vous pouvez par exemple vous baser sur le script que j’utilise pour l’internationalisation de Glances (voir ici).

Reste maintenant le travail le plus long: trouver des contributeurs/traducteurs pour traduire vos applications 🙂

Catégories
Open-source Planet-libre Systeme

Glances 1.5 est arrivé

Update: La version corrige un bug qui peut, sur certain OS, empêcher le bon fonctionnement de la version 1.5. Je viens donc de publier une version correctrice (1.5.1) qui effectue les contrôles nécessaires avant le démarrage de Glances.

Quelques mois après la sortie de la version 1.4 et la riche actualité qui a suivi (buzz sur pas mal de sites et intégration dans les paquets Debian Sid), voici donc la nouvelle mouture de Glances.

Pour rappel, Glances est un logiciel de supervision système en ligne de commande (interface texte basée sur Curses) permettant de voir en un clin d’oeil l’état de sa machine. Un code couleur permet de mettre en avant les statistiques que Glances juge nominale, à surveiller,  en alerte ou critique. Il peut également afficher la liste des dernières alertes/critiques. La lisibilité et l’économie de l’espace pour l’affichage sont des critères importants que j’ai essayé de garder en tête lors du développement et du choix des évolutions.

Nous allons dans ce billet aborder les principales nouveautés de la version 1.5, avec notamment un focus sur la fonction client/serveur permettant de surveiller les machines à distance.

Glances est disponible sous GNU/Linux, BSD, Mac OS X et même Windows (uniquement en mode serveur).

Installation et mise à jour

En attendant la disponibilité de la version 1.5 de Glances dans vos packets managers favoris, il est possible (et conseillé) d’utiliser le gestionnaire de paquet Python Pip pour installer ou mettre à jour le logiciel.

Installation:

# apt-get install python-pip build-essential python-dev
# pip install glances

Mise à jour:

# pip install -- upgrade glances

Si vous avez déjà une version antérieure de Glances installée, il se peut que la mise à jour ne ne fasse pas correctement. Il suffit alors de suivre la procédure suivante:

# rm -rf /usr/local/lib/python2.6/dist-packages/glances/
# rm -rf /usr/local/lib/python2.6/dist-packages/Glances-1.*
# rm -f /usr/local/bin/glances
# pip install glances

Note: si vous avez Python 2.7 ou supérieure, il faut adapter les chemins ci-dessus.

Pour tester que l’installation / mise à jour s’est bien passée, le plus simple est de lancer la commande:

$ glances -v
Glances version 1.5

Puis de lancer Glances pour vérifier que les statistiques de votre machine s’affichent correctement:

$ glances

Les nouveautés de la version 1.5

Visuellement, les utilisateurs des anciennes versions ne seront pas perdus. On retrouve un découpage avec des statistiques essentielles en haut de l’écran (CPU, LOAD, MEM) avec une optimisation de l’espace. Puis sur la gauche des informations optionnelles comme le débit des interfaces réseau, les entrées/sorties disques et l’espace des différents points de montage (maintenant avec un affichage optimisé pour tenir compte des noms longs). Sur la droite, on a la possibilité de voir le détail des processus (avec par défaut un classement automatique et dynamique selon l’état de la machine). Enfin en bas de l’écran, le log des dernières alertes que l’on peut nettoyer avec les touches ‘w‘ pour supprimer uniquement les Warning et ‘x‘ pour supprimer toutes les alertes finies).

La touche ‘h‘ permet toujours d’afficher l’aide en ligne avec la liste des touches disponibles.

La liste complète des changements par rapport à la dernière version est disponible dans le fichier ChangeLog.

Focus sur le mode client / serveur

C’est la grosse nouveauté de cette version. La mise à disposition pour les utilisateurs d’un mode client /serveur permettant à partir d’un Glances client d’afficher les statistiques d’un Glances serveur. On peut ainsi à partir d’un client GNU/Linux surveiller une autre machine GNU/Linux ou même, idée folle, une machine Windows.

Quand Glances est lancé en mode serveur, il créé un serveur XMLRPC en écoute sur le port TCP/61209 (ce port est bien sur configurable). Quand un client se connecte, il met à jour les statistiques avec un système de cache pour éviter de surcharger la machine puis il envoie les statistiques au client qui se charge de l’affichage et de la gestion des alertes. Il est bien sûr possible d’avoir plusieurs clients différents connectés sur un même serveur.

Pour lancer Glances en mode serveur, il suffit d’utiliser l’option -s:

server$ glances -s
Glances server is running on 0.0.0.0:61209

On lance ensuite le client sur une autre machine avec l’option -c:

client$ glances -c server
Si tout se passe bien, vous devriez avoir les statistiques du serveur qui s’affiche sur l’écran de votre client. Pour vérifier que la connexion entre le client et le serveur fonctionne correctement, j’ai mis en place un indicateur en bas à gauche de l’écran:

Ce dernier passe change en cas de problème de connexion:

Et Windows ?

Comme je l’ai noté en introduction, la version server de Glances fonctionne sous Windows (moyennant l’installation de Python et de PsUtil). Je dois avouer que je n’ai pas testé à fond la compatibilité de Glances sur cet OS. Au démarrage, Glances vérifie si il est lancé sur une plate-forme Windows. Si c’est le cas, il se lancera automatiquement en mode serveur (sans avoir à mettre le flag -s).

Je suis preneur de tout retour sur le sujet et si une âme généreuse veut bien s’occuper de maintenir un binaire « all inclusive » pour Windows 32 bits et 64 bits, cela serait vraiment bien ! (c’est assez facile à faire avec outil comme PyInstaller).

Catégories
Nagios Open-source Planet-libre Systeme

Installation pas à pas d’un serveur de supervision Shinken

Nous allons aborder l’installation et la configuration basique initiale d’un serveur de supervision basé sur Shinken. Ce billet est le premier d’une série sur le sujet. Dans la suite j’utiliserai une machine virtuelle sous Debian Squeeze 6.0.6 (version minimale) pour illustrer mes dires…

Installation de Shinken

Les commandes sont à saisir à partir du compte root ou en les précédants de la commande ‘sudo’ si celle-ci est installée.

apt-get install curl
curl -L http://install.shinken-monitoring.org | /bin/bash

Attendre quelques minutes…

Lors du premier re-démarrage, je suis tombé sur l’erreur suivante (/tmp/bad_start_for_arbiter):

[1351082314] Error :   Opening the log file 'arbiterd.log' failed with '[Errno 13] Permission denied: u'/usr/local/shinken/var/arbiterd.log''

Pour la résoudre ce problème de droit, j’ai effectué les actions suivantes:

service shinken stop
chown -R shinken:shinken /usr/local/shinken
service shinken start

L’installation se fait dans le répertoire /usr/local/shinken. Pour identifier les éventuels problèmes que vous pouvez rencontrer lors de l’installation, vous pouvez consulter le fichier de log /tmp/shinken.install.log.

Configuration initiale de Shinken

Les fichiers de configuration se trouvent dans le répertoire /usr/local/shinken/etc/.

Avant de commencer à jouer avec cette configuration, il est important d’avoir une connaissance générale de l’architecture de Shinken. Je vous conseille donc la lecture de cette page sur le wiki officiel.

La première chose à faire et de sécuriser l’accès à l’interface WebUI installé par défaut. Pour cela, il faut éditer la section module / WebUI du fichier shinken-specific.cfg en ajoutant le module Mongodb et en changeant le mot de passe auth_secret:

define module {
  module_name WebUI
  module_type webui

  host 0.0.0.0
  port 7767
  auth_secret MOTDEPASSE

  modules Apache_passwd,ActiveDir_UI,Cfg_password,PNP_UI,Mongodb

  manage_acl 1
  play_sound 0
  allow_html_output 0
  max_output_length 100
}

Puis en éditant le mot de passe du compte admin (par défaut: admin) dans le fichier contacts.cfg:

define contact{
    use             generic-contact
    contact_name    admin
    email           votre@mail.com ; adresse mail
    pager           0600000000   ; telephone
    password        motdepasseadmin ; mot de passe
    is_admin        1
}

Comme vous pouvez le voir c’est également dans cette section que vous pouvez changer l’adresse IP (par défaut en écoute sur toute les adresses IP des interfaces) et le port découte (par défaut TCP/7767) de l’interface WebUI.

On peut ensuite relancer Shinken pour prendre en compte la modification:

service shinken restart

Il ne reste plus qu’à acceder à la l’interface Shinken WebUI en saisissant l’URL suivante dans votre navigateur (en remplacant @IP par l’adresse IP de votre serveur): http//@IP:7767/

Lors de mon installation (sur une VM), je ne disposais que de 3 Go de libre sur le montage /var. La configuration par défaut de MongoDB, qui est la base de donnée utilisé par la WebUI pour stocker les informations utilisateurs, à besoin d’un fichier journal de plus de 3 Go. J’avais donc le message suivant au niveau de l’interface:

Et le log suivant dans le fichier /var/log/mongodb/mongodb.log:

Wed Oct 24 16:02:26 [initandlisten] ERROR: Insufficient free space for journal files
Wed Oct 24 16:02:26 [initandlisten] Please make at least 3379MB available in /var/lib/mongodb/journal or use --smallfiles
Wed Oct 24 16:02:26 [initandlisten]
Wed Oct 24 16:02:26 [initandlisten] exception in initAndListen: 15926 Insufficient free space for journals, terminating
Wed Oct 24 16:02:26 dbexit:

Pour forcer MongoDB a être moins gourmand, j’ai changer sa configuration dans le fichier /etc/mongodb.conf:

smallfiles = true

Puis on relance MongoDB:

service mongodb restart

A ce stade vous devriez avoir une interface WebUI fonctionnelle mais désespérément vide (mis à part votre serveur de supervision)…

Il est donc temps de passer à la prochaine étape.

Superviser votre système d’information avec Shinken

Selon la taille de votre réseau, la tache qui consiste à entrer les machines à superviser dans la configuration de Shinken peut s’averer pour le moins lourde. Heureusement, Shinken fournit un outil permettant de découvrir automatiquement les machines présente sur votre réseau (j’en avais déjà parlé dans ce billet) et même sur votre serveur de virtualisation VMWare (via vCenter).

Cet outil se base sur:

On commence donc par installer ces deux pré-requis sur notre serveur de supervision:

apt-get install nmap
/usr/local/shinken/install -p check_esx3

Si vous avez un serveur VMWare vCenter, vous pouvez vérifier le bon fonctionnement du plugin check_esx3 en le lancant en ligne de commande:

/usr/local/shinken/libexec/check_esx3.pl -H @IPVCENTER -u LOGIN -p MOTDEPASSE -l cpu
CHECK_ESX3.PL OK - cpu usage=376.00 MHz (0.59%) | cpu_usagemhz=376.00Mhz;; cpu_usage=0.59%;;

/usr/local/shinken/libexec/check_esx3.pl -H @IPVCENTER -u LOGIN -p MOTDEPASSE -l mem
CHECK_ESX3.PL OK - mem usage=30413.32 MB (23.20%), overhead=652.43 MB, swapped=0.00 MB, memctl=0.00 MB | mem_usagemb=30413.32MB;; mem_usage=23.20%;; mem_overhead=652.43MB;; mem_swap=0.00MB;; mem_memctl=0.00MB;;

/usr/local/shinken/libexec/check_esx3.pl -H @IPVCENTER -u LOGIN -p MOTDEPASSE -l net
CHECK_ESX3.PL OK - net receive=2.00 KBps, send=1.00 KBps, all 2 NICs are connected | net_receive=2.00KBps;; net_send=1.00KBps;; OK_NICs=2;; Bad_NICs=0;;

/usr/local/shinken/libexec/check_esx3.pl -H @IPVCENTER -u LOGIN -p MOTDEPASSE -l vmfs
CHECK_ESX3.PL OK - Storages : 'datastore1'(free)=279348.00 MB (99.65%), 'datastore2'(free)=548125.00 MB (57.51%) | datastore1=279348.00MB;; datastore2=548125.00MB;;

rm /tmp/cwpss_*

Il faut ensuite donner à Shinken les informations sur les réseaux (et serveurs vCenters) ou le logiciel de découverte doit être lancé. Pour cela, il faut éditer le fichier /usr/local/shinken/etc/resource.cfg (section Discovery):

#-- Discovery
# default snmp community
$SNMPCOMMUNITYREAD$=public
# what to discover by default
$NMAPTARGETS$=192.168.1.0/24
# If your scans are too slow, try to increase minrate (number of packet in parallel
# and reduce the number of retries.
$NMAPMINRATE$=1000
$NMAPMAXRETRIES$=0
# VMWare vCenter
$VCENTER$=vcenter.mondomaine.com
$VCENTERLOGIN$=LOGINVCENTER
$VCENTERPASSWORD$=MOTDEPASSEVCENTER

Il est bien sur possible d’ajouter des réseaux ou de machines à la variable $NMAPTARGETS$ en séparant chaque entrée par un espace.

On peut lancer shinken-discovery qui va effectuer la découverte automatique:

/usr/local/shinken/bin/shinken-discovery -c /usr/local/shinken/etc/discovery.cfg -o /usr/local/shinken/etc/objects/discovery/ -r nmap,vsphere

shinken-discovery va générer la configuration des machines découvertes dans le répertoire /usr/local/shinken/etc/objects/discovery/ (configurable dans la commande ci-dessus avec l’option -o).

On relance Shinken pour intégrer les machines ainsi découvertes:

service shinken restart

En allant dans l’interface graphique, vous allez sûrement rencontrer des erreurs de check car tous les plugins ne sont pas installés par défaut. Par exemple :

... BigProcesses CRITICAL3m 10s /bin/sh: /usr/local/shinken/libexec/check_wmi_plus.pl: not found ...

Il faut donc utiliser le script d’installation pour installer les plugins manquant.

Sur ma configuration j’ai ainsi fait:

/usr/local/shinken/install -p check_mysql_health
/usr/local/shinken/install -p manubulon
/usr/local/shinken/install -p check_snmp_bandwidth
/usr/local/shinken/install -p check_netint
/usr/local/shinken/install -p check_nwc_health
/usr/local/shinken/install -p check_wmi_plus

Il faut procéder ainsi jusqu’à avoir installé tous les plugins manquants nécessaires. Pour avoir une liste exhaustive des plugins dont l’installation est supporté par le script Shinken install, il suffit de saisir la commande suivante:

/usr/local/shinken/install -h
...
    -p | --plugin           Install plugins. Argument should be one of the following:
                               check_esx3
                               nagios-plugins
                               check_oracle_health
                               check_mysql_health
                               capture_plugin
                               check_wmi_plus
                               check_mongodb
                               check_emc_clariion
                               check_nwc_health
                               manubulon (snmp plugins)
                               check_hpasm
                               check_netapp2
                               check_mem (local enhanced memory check plugin)
                               check_snmp_bandwidth (check bandwidth usage with snmp)
                               check_netint (enhanced version of check_snmp_int plugins)
                               check_IBM
                               check_IBM_DS
                               check_rsync
...

La découverte automatique est vraiment un plus mais ce n’est pas le Saint Grall. En effet pour configurer finement ce que l’on veut suppervier, il faudra obligatoirement reprendre la configuration à la main en éditant les fichiers se trouvant dans le répertoire /usr/local/shinken/etc/objects/discovery. De plus, la notion de groupe étant plus une problématique fonctionnelle que technique, il vous faudra configurer ces derniers manuellement à partir du fichier /usr/local/shinken/etc/hostgroups.com.

Un exemple de configuration de groupe:

define hostgroup{
   hostgroup_name VirtualisationServers
   alias Virtualisation Servers
   members vcenter, virt1, virt2, virt3, virt4
}

Attention à bien sauvegarder ce répertoire avant de relancer un shinken-discovery, histoire de ne pas perdre vos modifications.

Reste ensuite la phase la plus longue mais également la plus importante de la configuration de Shinken: ne surveiller que les choses importantes pour votre système d’information.

En effet, le mode de découverte automatique n’est pas assez fin pour déterminer par lui même ce qu’il faut superviser. La CPU du PC de la secrétaire monte régulièrement au dessus de 90% d’utilisation ? What else… Par contre si on constate la même consommation CPU sur le serveur Web de votre entreprise, il faut aller y jeter un coup d’oeil…

Le plus simple pour effectuer cette lourde tache est de manipuler la WebUI (voir le chapitre suivant), puis de parcourir l’ensemble des hosts et des services en supprimant ce que l’on juge peu important.

Prise en main de Shinken WebUI

A ce stade, vous devriez avoir un serveur de supervision qui commence à remonter un certain nombres d’informations dans l’interface WebUI.

Je vous encourage ensuite à vous familiariser avec cette nouvelle interface WebUI qui peut être un peu déroutante pour les personnes habituées à manipuler d’autres solutions de supervision. A ce sujet, il est également possible d’utiliser des interfaces alternatives comme Thruk qui se rapproche plus de l’interface native de Nagios.

Thruk, une alternative à Shinken WebUI

Personnellement, je trouve qu’une fois la première impression passée (c’est quoi ces gros icônes ? Ou sont mes hosts !). La modularité apportée par le Dasboard, les filtres et les bookmarks permet d’adapter cette interface à vos besoins. Si les développeurs de Shinken lisent cet article (et je suis sûr qu’ils vont le faire, coucou @naparuba :)), il serait bon près configurer le Dashboard par défaut et quelques filtres bien pensées histoire que les nouveaux utilisateurs ne se trouvent pas devant des pages blanches.

 

On peut également se créer des filtres personnels (par exemple toutes les machines appartenant au groupe « serveur » ou tout les services remontant la charge des machines…) et créer des bookmarks dans la page All de la WebUI.

Et après ?

Nous arrivons au terme de ce premier article sur une configuration pas à pas de Shinken. Au prochain épisode, nous allons nous pencher sur la notion d’impacts/dépendances et de business rules qui sont de grosses valeurs ajoutées de Shinken par rapport à Nagios.

Catégories
Open-source Planet-libre Systeme

Bêta test de Glances 1.5

Je viens de figer en bêta la version 1.5 de Glances, mon outil de supervision système. J’ai donc besoin de vous pour tester cette nouvelle mouture (oui je sais, c’est moche de vous faire bosser un week-end).

Glances 1.5 est une évolution majeure car elle apporte une fonction qui était demandée depuis pas mal de temps par les utilisateur. Cette fonction est le mode client/serveur qui permet de surveiller à distance une machine (ou le serveur Glances en lancé) depuis une autre (Glances fonctionnera sur cette dernière en mode client).

Le principal avantage de cette fonction est d’éviter d’avoir à se connecter sur les machines à surveiller. On lance Glances server une fois pour tout et on peut ensuite se connecter à partir de n’importe qu’elle autre machine. Un autre avantage est le fait d’ouvrir Glances à la supervision des machines sous Windows. En effet, il est possible de lancer Glances serveur sur une machine Windows et de surveiller la majorité des informations systèmes (presque toutes…) à partir d’une machine Linux, Mac ou BSD.

Il y a bien sûr d’autres nouveautés à consulter ici.

Comment installer cette version bêta ?

Le plus simple pour ne pas casser son Glances déjà installé est de se faire une installation à la main:

mkdir -p ~/tmp/glances
cd ~/tmp/glances
rm -f ./glances.py
wget https://raw.github.com/nicolargo/glances/master/glances/glances.py
chmod a+x ./glances.py

Attention, Glances 1.5 nécessite une version 0.4 ou supérieure de la librairie PsUtil pour fonctionner.

Vous pouvez installer la dernière version de PsUtil en utilisant Pip:

pip install psutil

Comment tester cette version bêta ?

On lancera ensuite Glances avec la commande:

~/tmp/glances/glances.py
Merci de tester le maximum de chose (redimensionnement du terminal, test des fonctions: cliquez sur ‘h’ pour avoir la liste complète).

Pour le mode client serveur, la syntaxe est assez simple.

Sur le serveur:

~/tmp/glances/glances.py -s

Note: par défaut le serveur va se mettre en écoute sur le port TCP/61209 (à ouvrir si vous avez un Firewall) et sur toutes les interface de votre machine. Il est possible de configurer le port avec l’option (-p PORT) et l’adresse de binding avec l’option (-B @BIND).

Le serveur Glances est compatible XML/RPC… donc potentiellement accessible depuis des applications tierces 🙂

Sur le client:

~/tmp/glances/glances.py -c @server

Il faut donc fournir l’adresse IP ou le nom d’hôte public de la machine serveur à superviser.

Note: par défaut le client va se connecter en utilisant le port TCP/61209. Il est possible de configurer le port avec l’option (-p PORT).

Comment me remonter les erreurs / problèmes de cette version bêta ?

Le mieux pour moi est que vous utilisez GitHub en créant un bug avec une description précise du problème rencontré. Si vous avez un compte GitHub, il suffit de remplir le formulaire.

Sinon, vous pouvez laisser un commentaire directement sur le blog !

D’avance merci à vous 🙂

Catégories
Open-source Planet-libre Reseau Systeme

De Network Manager à une configuration manuelle

S’il y a bien une fonction que je trouve mal faite dans Gnome c’est le « Network Manager ». Ce logiciel, accessible depuis la barre de menu, permet de configurer, à partir d’une interface graphique, les interfaces réseaux de sa machine. Ce n’est pas la première fois que je tombe sur une configuration que je n’arrive pas à appliquer en utilisant ce logiciel. Il faut dire que celle-ci mélange plusieurs interfaces réseaux avec des configurations DHCP, statiques et des routes spécifiques. J’ai donc décidé de désactiver Network Manager et de configurer mon réseau à la mimine.

Avant de pouvoir configurer manuellement son réseau à partir du fichier /etc/network/interfaces, il faut préalablement désactiver la gestion des interfaces par Network Manager. Nous allons voir comment procéder sur une distribution GNU/Linux Ubuntu 12.04.

Préparation de la manipulation

Avant toute chose, il faut arrêter toutes vos applications. En effet, nous allons toucher à la couche réseau du noyau Linux et il y a de forte chance que vous perdiez la connectivité.  Il est bien sûr totalement impossible de faire cette manip à distance (via SSH ou remote desktop).

Pour pouvoir revenir en arrière, nous allons sauvegarder la configuration de Network Manager:

sudo cp /etc/NetworkManager/NetworkManager.conf /etc/NetworkManager/NetworkManager.conf.OLD

Désactivation de Network Manager

On commence par éditer le fichier /etc/NetworkManager/NetworkManager.conf:

sudo vi /etc/NetworkManager/NetworkManager.conf

Puis passer la clé de configuration managed à true:

[ifupdown]
managed=true

Configuration manuelle des interfaces réseau

On passe ensuite à la configuration manuelle des interfaces réseau de notre machine en éditant le fichier /etc/network/interfaces. Le contenu du fichier dépend bien sûr de votre besoin. J’avais écris un billet sur le sujet il y a quelques années. Mais le mieux est de lire la documentation officielle et complète sur le site de Debian.

Il ne reste ensuite plus qu’à relancer le démon networking pour appliquer les changements et faire chauffer le semiconducteur de la carte mère:

sudo service networking restart

Bye bye Network Manager et son horrible interface graphique ! Bienvenu au fichier interfaces et sa syntaxe simple et claire.

Revenir en arrière ?

En cas de problème, pour revenir à votre configuration initiale ou les interfaces sont gérées par Network Manager, il suffit de saisir les commandes suivantes:

sudo cp /etc/NetworkManager/NetworkManager.conf.OLD /etc/NetworkManager/NetworkManager.conf
sudo service networking restart
Et hop, retour à la case départ.
Catégories
Open-source Planet-libre Systeme

Il n’y a pas qu’Ubuntu dans la vie…

En mettant de côté le monde des serveurs et des smartphones, les systèmes GNU/Linux représentent plus ou moins 1 % des parts de marché sur les PC clients. Si ce chiffre peut paraître ridicule par rapport au nombre de machines sous Windows, il l’est encore plus quand on regarde les parts des systèmes GNU/Linux autres qu’Ubuntu.

Pourtant, en ne donnant pas une chance à ces distributions exotiques, vous pourriez passer à côté d’un système adapté à votre configuration. Le fond du problème est là. La cible de Canonical (l’éditeur d’Ubuntu) est la même que Microsoft : des PC costauds, avec des cartes graphiques supportant l’accélération 3D et une mémoire confortable pour faire tourner vos applications en même temps que l’environnement graphique système (Gnome3 ou KDE).

Hors, tout le monde n’a pas les moyens ou tout simplement l’envie de dépenser plus de 700€ pour avoir un PC bureautique performant. C’est pourtant sur ce créneau spécifique des PC « low cost » que ces distributions apportent toute leur valeur ajoutée. En effet, elle sont pour la plupart basée sur des interfaces graphiques moins consommatrice de ressources hardware. Je pense notamment à LXDE et XFCE porté par Canonical sur les distributions dérivées Lubuntu et Xubuntu mais aussi à OpenBox comme dans le très bon CrunchBang Linux que j’ai testé sur un boîtier « Linutop 4 » dans un dernier article. Le choix de l’interface graphique n’est pas le seul avantage de ces distributions. Elles sélectionnent également les applications proposées en standard aux utilisateurs, en préférant par exemple Midori ou Chromium à la place de Firefox.

Les plus barbus d’entre vous vont me retourner qu’il est tout à fait possible de prendre n’importe quelle distribution GNU/Linux (si possible la plus proche de la philosophie libre) et d’y installer à la main l’interface graphique et les applications de son choix. Cependant, cette démarche est justement réservée aux barbus et pas à Monsieur Lambda que l’on souhaite faire venir du bon côté de la force.

Alors que pouvons-nous faire ? Nous, défenseurs des logiciels libres. Pourquoi pas en donnant sa chance à une distribution alternative, en sortant un peu des pistes que l’on connait si bien (ne vous inquiétez pas, vous ne serez pas perdu bien longtemps). En choisissant tout simplement un système en adéquation avec nos besoins et le matériel associé. En ne refaisant pas les mêmes erreurs qui ont conduit et conduisent encore des utilisateurs vers des OS propriétaires et fermés.

Catégories
Hardware Open-source Planet-libre Systeme

Test d’un Linutop 4 avec Linutop OS 5

J’écris cet article depuis le Linutop 4 que j’ai eu gracieusement en test pendant quelques semaines (au passage merci à l’équipe Linutop). Pour rappel, le Linutop 4 est un mini PC Fanless et totalement silencieux (pas de disque dur mais une mémoire Flash) utilisant un OS maison nommé Linutop OS 5. Il a comme cible les entreprises souhaitant disposer d’un client bureautique léger et les utilisations de type bornes Internet ou affichages dynamique d’informations.

Les caractéristiques

On commence par un bref aperçu des caractéristiques du boîtier:

Note: le système Linutop OS 5, pré-installé par défaut, occupe environ 450 Mo des 2 Go de la mémoire flash interne.

Premier contact

C’est la première fois que j’utilise une machine totalement silencieuse et je dois avouer que lors du premier démarrage, j’ai vérifié que je n’avais pas oublié de brancher l’alimentation avant de voir apparaître la bannière de configuration sur mon écran. Même par rapport à l’utilisation d’un PC portable, le silence est vraiment total.

L’avantage d’utiliser l’OS maison (Linutop OS 5) est qu’il n’y a aucune configuration à faire sur la machine. Une simple fenêtre de configuration est affichée au première démarrage de la machine et permet de fixer les paramètres comme le langage, le clavier… Pour la majorité des utilisations, il n’y a rien à faire mis à part cliquer sur le bouton OK.

Une fois cette étape passée, on se retrouve sur une distribution GNU/Linux basée sur Ubuntu (et donc bénéficiant des paquets de cette distribution) avec XFCE comme gestionnaire graphique.

Les premières minutes d’utilisation ont été un peu difficile pour moi. En effet, étant habitué à travailler sur des machines puissantes (voir sur-dimensionnées), la relative lenteur du temps de réaction pour les opérations de bases (ouvrir et déplacer des fenêtres, charger des pages Web légères…) m’a sauté au yeux. Après quelques heures d’utilisation, je m’y suis habitué et si on ne demande pas des choses trop lourdes à ce boitier il s’acquitte parfaitement de ses tâches.

Une machine pour quoi faire ?

Les caractéristiques hardware de la machine limite l’utilisation à certain domaine. J’ai essayé, dans ce chapitre de résumer les choses que j’ai pu tester.

Machine parfaitement adapté pour:

  • naviguer sur Internet (sauf si vous essayez de lire des vidéos en 720p sur YouTube)
  • de la bureautique classique (document, tableur, présentation)
  • écouter de la musique (bien qu’il manque à mon goût une sortie numérique)
  • faire du déport d’affichage (VNC, RDP/TSE) ou de l’administration via SSH

Machine utilisable pour:

  • regarder des vidéos DivX, MP4, OGG au format SD 480p (le format HD Ready 720p peut passer mais risque de faire chauffer votre machine tandis qu’il faut oublier la lecture de fichier en Full HD 1080p)
  • développer (si vous utilisez des IDE légères Troll> et pas des usines à gaz comme Eclipse <Troll)

Machine inutilisable pour:

  • gérer votre bibliothèque de photos / retouche (j’ai essayé et cela n’est pas exploitable)
  • faire du post traitement vidéo
  • faire plusieurs choses en même temps… (la RAM du boitier que j’avais en test était de 1 Go mais il est possible en option de passer à 2 Go)

Résumé des + et des –

Le hardware: Linutop 4

Les +

  • Le silence total !
  • Qualité de fabrication du boitier. Cela paraît solide
  • Le boîtier chauffe mais pas de manière excessive

Les –

  • 1 Go de RAM en standard c’est vraiment trop peu
  • Impossible d’acheter un boîtier « vierge » sans l’OS Linutop (qui est vendu 79€ séparément). J’aurai donc aimé pouvoir acheter le Linutop OS 4 à 400-79 = 321 €…
  • Pas de port USB en version 3
  • Le prix (environ 400€), ce qui est cher pour la configuration hardware proposée

Le systéme: Linutop OS 5

Les +

  • Pack bureautique complet
  • VLC de base et qui fonctionne très bien sur les fichiers SD

Les + et –

  • Le choix de XFCE s’explique bien évidemment par la relativement faible consommation de ressource de ce gestionnaire. De mon point de vu, quitte à avoir un gestionnaire épuré et faiblement consommateur de CPU et de mémoire, autant partir sur une solution de type Openbox ou Fluxbox. J’ai donc essayé la distribution CrunchBang Linux (32 bits BTO) qui fonctionne parfaitement en version « live USBkey ». Et l’impression de lenteur est beaucoup moins importante qu’avec Linutop OS 5 pour une utilisation classique de surf Internet.

    CrunchBang Linux, une alternative intéressante à Linutop OS 5

Les –

  • Si vous souhaitez utiliser Linutop OS sur une autre machine, il vous faudra débourser 79 €. Je trouve cela un peu fort de café, surtout que des solutions libres et gratuites existent et fonctionnent parfaitement sur les boîtiers (par exemple CrunchBang Linux dont je parle ci-dessus)
  • Firefox qui est un peu trop lourd pour la RAM disponible. J’ai installé Chromium qui fonctionne sans problème.
  • Outil graphique: franchement c’est quoi ce mtPaint graphic editor ? C’est pour concurrencer Paint sous Windows ?

Quelques photos…

Pleins d’autres images à retrouver sur Flickr

Alors j’achète ou j’achète pas ?

On arrive donc à la conclusion de cet article et à la question fatidique: est que, dans le rôle d’un décideur informatique (ce que je suis dans le cadre de mon boulot), j’achèterai cette solution…

Le hardware (Linutop 4) est vraiment de très bonne qualité, le silence total et il ne semble pas trop chauffer même après quelques jours d’utilisation sans extinction. Mais à plus de 400 € (avec livraison), je trouve quand même l’addition un peu salée. Donc à moins de négocier les prix à la baisse (321 € par exemple…) ou bien d’obtenir pour ce prix une configuration plus musclée (au minimum 2 Go de RAM et mémoire Flash plus importante), je regarderai attentivement du coté de la concurrence avant de lancer mes achats.

Donc j’achète le boîtier vierge (sans OS) au prix maximum de 320€.

Concernant l’OS Linutop 5, je suis beaucoup plus sévère. Bien que je comprenne la volonté de fournir aux utilisateurs un système clés en main, je ne trouve pas celui-ci adapté au hardware (XFCE, Firefox, pack logiciel graphique…). De plus, faire payer cet OS (qu’ils soit inclus dans le prix des boîtiers Linutop ou bien 79€) n’est pas constructif: cela limite la participation de la communauté et peut mettre à dos le clan des barbus qui peuvent y voir une vente liée de système GNU/Linux (un comble)…

Je n’achète pas l’OS Linutop 5, et j’utilise sur les boîtiers Linutop des OS GNU/Linux gratuits, léger et alternatifs.

Catégories
Developpement Open-source Planet-libre

Et si on jouait un peu avec Redis et Python ?

Dans la mouvance NoSQL, Redis se classe dans la catégorie « data structure server »  (que l’on peut traduire en Français par « serveur de dictionnaire distant »). C’est  un système permettant de traiter, de manière très performante, des données sous la forme clés/valeurs. Contrairement à des solutions comme MemCache, Redis est capable de gérer la persistance des données en stockant, sur demande, son contenu sur disque.

La clé, qui peut être comparée au nom d’une variable dans un langage de programmation, permet d’identifier de manière unique la donnée. Lors de la création de votre application, vous allez rapidement vous rendre compte que le choix de cette clé n’est pas négligeable. C’est elle qui définira « la structure » de votre base de donnée.

La clé est dans la définition de la clé.

Quant aux valeurs, elles peuvent appartenir aux types suivants:

  • chaînes de caractères (strings)
  • compteurs numériques (note: les données numériques seront stockées dans la base sous la forme de chaîne de caractères) (atomic counters)
  • listes (lists)
  • tableaux (set) et tableaux ordonnés (sorted set)
  • dictionnaires (hashes)

Comme on peut le voir, on retrouve la plupart des structures du langage Python. En étant un fervent admirateur, je me suis donc penché sur l’API Python Redis.

C’est parti pour un peu de bac à sable…

Installation de Redis

Pour mes tests, j’ai fait une installation standard depuis les paquets Ubuntu du serveur Redis, de l’API Python et de la CLI iPython pou illustrer mes exemples:

sudo apt-get install redis-server python-redis ipython

Les commandes de bases

La librairie Python permet d’envoyer des commandes (voir la liste des commandes ici) au serveur.

On commence par se connecter un serveur (local en écoute sur le port TCP par défaut).

J’utilise iPython pour mes tests de la librairie Python mais il est également possible de passer par la CLI Python classique.

# ipython

In [1]: import redis

In [2]: r = redis.Redis('localhost')

Premier exemple clés / valeur (chaîne de caractères):

In [3]: r.set("cles", "valeur")
Out[3]: True

In [4]: r.get("cles")
Out[4]: 'valeur'

Stocker des valeurs numériques:

In [5]: r.set("clesnum", 666)
Out[5]: True

In [6]: r.get("clesnum")
Out[6]: '666'

In [7]: r.incr("clesnum")
Out[7]: 667

In [8]: r.decr("clesnum")
Out[8]: 666

Attention, la méthode get retourne des chaines, il faut les convertir avant de s’en servir comme des entiers.

In [9]: a = 10

In [10]: a + r.get("clesnum")
---------------------------------------------------------------------------
TypeError                                 Traceback (most recent call last)
/home/nicolargo/<ipython-input-10-06c75e85d988> in <module>()
----> 1 a + r.get("clesnum")

TypeError: unsupported operand type(s) for +: 'int' and 'str'

In [11]: a + int(r.get("clesnum"))
Out[11]: 676

Des listes comme valeurs:

In [12]: r.rpush("clesliste", "a")
Out[12]: 1L

In [13]: r.rpush("clesliste", "b")
Out[13]: 2L

In [14]: r.rpush("clesliste", "c")
Out[14]: 3L

In [15]: r.lrange("clesliste", 0, -1)
Out[15]: ['a', 'b', 'c']

In [16]: r.lindex("clesliste", 2)
Out[16]: 'c'

In [17]: r.llen("clesliste")
Out[17]: 3

In [22]: r.lpush("clesliste", "z")
Out[22]: 4L

In [23]: r.lrange("clesliste", 0, -1)
Out[23]: ['z', 'a', 'b', 'c']

Pour des listes avec des valeurs uniques (set), il faut utiliser les méthodes sadd (pour ajouter) et smembers (pour récupérer le set).

In [27]: r.sadd("clesset", "a")
Out[27]: True

In [28]: r.sadd("clesset", "b")
Out[28]: True

In [29]: r.sadd("clesset", "c")
Out[29]: True

In [30]: r.sadd("clesset", "a")
Out[30]: False

In [31]: r.smembers("clesset")
Out[31]: set(['a', 'c', 'b'])

Une autre structure de liste intéressante est la liste avec des valeurs uniques et ordonnées. On ajoute un troisième champs à notre couple clés/valeur qui s’appelle score (3em paramètre dans la méthode zadd). C’est ce score qui va déterminer l’ordre de la liste:

In [32]: r.zadd("clessetsort", "a", 4)
Out[32]: True

In [33]: r.zadd("clessetsort", "b", 1)
Out[33]: True

In [34]: r.zadd("clessetsort", "c", 3)
Out[34]: True

In [35]: r.zadd("clessetsort", "a", 5)
Out[35]: False

In [36]: r.zrange("clessetsort", 0, -1, withscores = True)
Out[36]: [('b', 1.0), ('c', 3.0), ('a', 5.0)]

In [37]: r.zrange("clessetsort", 0, -1)
Out[37]: ['b', 'c', 'a']

Pour stocker un dictionnaire, c’est également très simple:

In [38]: r.hset("cleshash", "a", "A")
Out[38]: 1L

In [39]: r.hset("cleshash", "b", "B")
Out[39]: 1L

In [40]: r.hset("cleshash", "c", "C")
Out[40]: 1L

In [41]: r.hgetall("cleshash")
Out[41]: {'a': 'A', 'b': 'B', 'c': 'C'}

In [42]: r.hget("cleshash", "b")
Out[42]: 'B'

Gérer l’expiration de vos données

… importance du garbage…

In [3]: r.set("key", "value")
Out[3]: True

In [4]: r.exists("key")
Out[4]: True

In [5]: r.expire("key", 10)
Out[5]: True

In [6]: r.exists("key")
Out[6]: True

Attendre 10 secondes ou plus...

In [7]: r.exists("key")
Out[7]: False

Egalement de manière statique avec la méthode expireat (http://redis.io/commands/expireat).

Pour être plus fin, il est aussi possible d’utiliser les « scores » avec les méthodes z* (zadd, zrangebyscore) pour supprimer les données qui ont des valeurs de clés les plus faibles (ou forte selon votre structure).  Par exemple pour supprimer les données de plus faible score (< 3) de notre liste « clesetsort » créée dans le chapitre précédant:

In [37]: r.zrange("clessetsort", 0, -1)
Out[37]: ['b', 'c', 'a']

In [60]: r.zremrangebyscore("clessetsort", 0, 3)
Out[60]: 2

In [61]: r.zrange("clessetsort", 0, -1)
Out[61]: ['a']

 

Les pipelines

Si Redis vous intéresse, c’est que vous avez à gérer un volume important de données. Les commandes que nous venons de voir dans le chapitre précédant sont unitaires. C’est à dire que pour une exécuter une commande, une requête (TCP) est faite au serveur Redis. Pour optimiser les performances et donc réduire le nombre de requêtes fait au serveur, nous disposons des Pipelines (lire ce billet comparatif sur le sujet).

Par exemple pour entrer 100.000 clés/valeurs dans votre serveur, il faut environ 11 secondes sur mon PC de test:

import time
import redis

_MAX_ITER = 100000

r = redis.Redis('localhost')

print "Start bench without Pipeline"
start=time.clock()
for i in range(_MAX_ITER):
   r.set("cles%d" % i, i)
stop=time.clock()
print "Result: %s" % str(stop-start)

alors qu’il faut un peu de plus de 4 secondes en utilisant une pipeline (soit un gain de plus de 50%):

import time
import redis

_MAX_ITER = 100000

r = redis.Redis('localhost')

print "Start bench with Pipeline"
start=time.clock()
p = r.pipeline()
for i in range(_MAX_ITER):
   p.set("cles%d" % i, i)
p.execute()
stop=time.clock()
print "Result: %s" % str(stop-start)

Ressources:

 

Catégories
Open-source Planet-libre Web

Installer facilement NodeJS et NPM sur une Debian Stable

A l’heure actuelle, il n’existe pas de dépôt officiel pour installer NodeJS et NPM sur une distribution Debian Stable. Voici donc un nouveau script d’installation automatique qui va installer sur votre système Debian:

  • la dernière version de NodeJS (depuis le GitHub officiel)
  • la dernière version de NPM  (Node Package Manager)

Comme toujours, mon script est hébergé sur GitHub. C’est à partir de là que vous pouvez me remonter vos questions et remarques…

Procédure à suivre

Le plus simple est de saisir les commande suivantes dans un terminal:

cd /tmp
wget https://raw.github.com/nicolargo/nodeautoinstall/master/nodeautoinstall.py
sudo python ./nodeautoinstall.py -d

Le script va normalement se dérouler sans problème en installant le tout dans le répertoire /opt/node (qu’il est possible de modifier avec l’option -o du script).

L’option -d permet de générer un fichier de log de l’exécution du script (à consulter en cas de problème…) dans le fichier /tmp/nodeautoinstall.log.

Pour que votre/vos utilisateurs puisse utiliser node, il faut également qu’ils ajoutent les lignes suivantes au fichier .profile:

# --- NodeJS
export PATH=$PATH:/opt/node/bin
export NODE_PATH=/opt/node:/opt/node/lib/node_modules
# ---

Le résultat…

Vous devriez alors disposer des dernières versions des deux composants:

Il ne vous reste plus qu’à suivre mon billet d’introduction à NodeJS en passant le chapitre sur l’installation que vous venez de faire automatiquement dans ce billet:)

Catégories
Open-source Planet-libre Systeme

Des outils de test pour stresser votre système

Le développement logiciel nécessite des phases de test et de validation qui sont souvent menées sur des machines non chargées. Je vous propose donc de découvrir, dans ce billet, une série de petits logiciels permettant de simuler une charge sur votre système et qu’il faudra donc lancer en parallèle de vos applications à valider. J’ai uniquement sélectionné des logiciels libres, légers, en ligne de commande et disponible dans les dépôts Ubuntu standards.

Comment stresser une machine ?

Plusieurs leviers permettent de « stresser » une machine:

  • consommation CPU
  • utilisation de la mémoire MEM
  • entrée/sortie IO
  • lecture/écriture disque DISK
  • entrée/sortie réseau NET

L’utilisation conjointe de ces leviers permet de simuler une charge sur une machine cible. L’amplitude des paramètres appliquées à ces leviers est bien sûr à adapter à votre configuration hardware et système.

Note: l’utilisation des logiciels décrits si-dessous peut entraîner le plantage pure et simple de votre machine (cela m’est arrivé pendant mes tests…). Je vous conseille donc vivement de ne pas les appliquer sur une machine en production…

Fuzz

Le premier logiciel est Fuzz. Contrairement aux autres solutions, ce dernier ne génère pas de « stress » par lui même mais demande à d’autres programmes de le faire.

Ainsi, la ligne de commande suivante:

fuzz grep foo

va lancer 10.000 fois la commande « grep foo » en lui donnant en entrée des données factices. Ainsi votre machine va chercher la chaîne de caractère foo dans un flot de données. Nous pouvons donc voir, grâce à Glances (un peu de pub…),  que la charge CPU (recherche de sous-chaine) et IO (entrée-sortie disque) augmentent.

Le nombre d’exécution (-r par défaut 10.000) et le time-out (-t par défaut 120 secondes) sont bien-sur paramétrable en ligne de commande (voir le man).

Si vous connaissez les applications qui tourneront en parallèle de la votre, il est facile de simuler votre environnement cible. Il manque par contre un peu de finesse pour tester votre application avec des contraintes pré-définies (par exemple avec une charge CPU de 75%).

Spew

Développé par HP et mis à disposition de la communauté, Spew est spécialisé sur le stress par entrée-sortie disque. Il permet d’écrire et/ou de lire des fichiers de test sur votre disque.

Pour générer un fichier de 5 Go nommé /tmp/bibi:

$ spew 5G /tmp/bibi
WTR:    90320.56 KiB/s   Transfer time: 00:00:58    IOPS:   180641.12

La même commande mais en forçant la relecture du fichier à la fin de l’écriture:

$ spew --read-after-write 5G /tmp/titi
WTR:    74740.25 KiB/s   Transfer time: 00:01:10    IOPS:   149480.49
RTR:  1761227.45 KiB/s   Transfer time: 00:00:02    IOPS:  3522454.90
On peut voir une montée en charge globale de la machine (LOAD) mais juste avec des entrées/sorties (IO):

Note: pensez à supprimer vos fichiers de test (/tmp/bibi)…

Stress et StressAppTest

Deux logiciels qui font fonctionnellement la même chose (jouer sur l’ensemble des leviers permettant de stresser une machine) mais de manière différente…

Stress est une application permettant de générer des processus (worker) ayant des caractéristiques communes:

  • CPU (consommation de la CPU grâce à l’exécution de la commande sqrt)
  • MEM (avec exécution des commandes malloc et free)
  • IO (avec execution de la commande sync)
  • DISK (execuiyon des commandes read et write)

Avec la commande suivante:

stress -m 10 --vm-bytes 512000000 -t 30

On se retrouve donc avec 10 processus consommant chacun 512 Mo:

Contrairement à Stress, StressAppTest ne génère par défaut qu’un seul processus qui va regrouper les caractéristiques de stress souhaitées.

Ainsi, la commande:

$ stressapptest -s 30 -M 256 -m 8 -C 8 -W

Log: Commandline - stressapptest -s 30 -M 256 -m 8 -C 8 -W
Stats: SAT revision 1.0.3_autoconf, 64 bit binary
Log: buildd @ allspice on Wed Jan 11 17:38:51 UTC 2012 from open source release
Log: 1 nodes, 4 cpus.
Log: Prefer plain malloc memory allocation.
Log: Using memaligned allocation at 0x7f9e9f157000.
Stats: Starting SAT, 256M, 30 seconds
Log: Region mask: 0x1
Log: Seconds remaining: 20
Log: Seconds remaining: 10
Stats: Found 0 hardware incidents
Stats: Completed: 458960.00M in 31.10s 14756.72MB/s, with 0 hardware incidents, 0 errors
Stats: Memory Copy: 458960.00M at 15298.83MB/s
Stats: File Copy: 0.00M at 0.00MB/s
Stats: Net Copy: 0.00M at 0.00MB/s
Stats: Data Check: 0.00M at 0.00MB/s
Stats: Invert Data: 0.00M at 0.00MB/s
Stats: Disk: 0.00M at 0.00MB/s
Status: PASS - please verify no corrected errors

Donne:

Je vous invite à consulter la documentation officielle du projet pour y découvrir les nombreuses options.

Pour finir…

Cette liste est très loin d’être exhaustive. L’idée étant de partager votre savoir…

Quel logiciel utilisez vous pour faire vos test de performances sur des machines chargées ?

Avez-vous des solutions multi-plateforme ?

A vos claviers 🙂