Catégorie : Supervision

Utiliser JMeter pour superviser un serveur Tomcat

Voici une nouvelle version du tutoriel JMeter pour superviser un serveur Tomcat. On passe à la version 7 de Tomcat et avec un JMeter en français.

Nous allons donc utiliser JMeter pour supervision le fonctionnement d’un serveur Tomcat à travers son interface de statut.

Le pré-requis est bien entendu d’avoir à disposition un serveur Tomcat (sous Unix/Linux ou Windows) tournant sur un Java JDK.

On va commencer par « ouvrir » le service de statut du Tomcat. Pour cela, Continuer la lecture de Utiliser JMeter pour superviser un serveur Tomcat

Envoyer un email avec JMeter via son élément Requête SMTP

Ce billet est un petit « howto » pour vous montrer comment utiliser JMeter pour envoyer un email (courriel), ici en utilisant le serveur de messagerie SMTP de Google Mail.

Pour rappel, le SMTP (Simple Message Transfer Protocol) est le protocole normalisé d’échange de message électronique (email). Dans JMeter depuis la version 2.4, un nouvel échantillon appelé Requête SMTP a été ajouté pour avoir un client SMTP qui envoi donc un email.

Bien entendu, JMeter étant un outil de test de charge, avec cet échantillon, on peut faire un test de charge sur un serveur de messagerie franchement installé pour vérifier sa tenue de charge et robustesse (ce qui est mon cas), on peut aussi utiliser cet échantillon SMTP pour par exemple s’envoyer un email de rapport à la fin d’un test de charge « long » (qui dure plusieurs heures ou jours), ou tout simplement dans le cadre de la mise en place d’un système d’alerte en cas de temps de réponse dégradé d’un site web (par exemple) avec un script qui s’exécute toutes les x minutes ou heures.

Revenons à notre sujet, voici notre arbre JMeter tout simple pour ce test :

Continuer la lecture de Envoyer un email avec JMeter via son élément Requête SMTP

[Linux] Exécuter une commande avec un utilisateur normal en tant que root à distance sans mot de passe et en SSH

Comment exécuter une commande root avec un utilisateur normal, à distance et sans saisir de mot de passe, le tout en SSH entre deux machines Linux ?

Voici une réponse :

Pour répondre à la problématique du « à distance sans saisir de mot de passe avec SSH », nous allons utiliser la notion de clé SSH.

Sur le poste de travail Linux (le poste qui va lancer la commande à distance), nous allons générer la clé SSH avec la commande suivante :

ssh-keygen -t dsa -f $HOME/.ssh/MON_LOGIN

Puis nous allons transférer la partie publique de la clé, en utilisant l’utilitaire ssh-copy-id :

ssh-copy-id MON_LOGIN@192.168.1.1

Redbooks : Linux Performance and Tuning Guidelines

Linux ayant une place importante dans mon utilisation informatique, il est bien normal d’être à l’affût de bons documents dessus. IBM via son site de publications Redbooks nous propose un excellent document sur les performances et l’optimisation de Linux (il s’agit en réalité d’une mise à jour d’un document déjà sorti en juillet 2007).

Redbooks : Linux Performance and Tuning Guidelines

Ce livre nous propose ainsi une large introduction au fonctionnement interne de Linux au niveau de la gestion des processus, les architectures mémoire (en particulier les différences entre systèmes 32 bits et 64 bits), les systèmes de fichiers (ext3, ext2, etc.), la gestion des entrées / sorties et la gestion du réseaux. C’est extrémement instructif.

La suite est un panorama des outils disponibles sur les distributions Linux pour la supervision et le benchmark. Chaque outil est expliqué, en particulier l’interprétation des données affichées.

Les deux derniers chapitres nous montrent d’une part les méthodes d’identifications des goulots d’étranglements (bootlenecks) au niveau CPU, mémoire, disques et réseaux. Et d’autre part des techniques d’optimisation de sa machine Linux (orienté serveur).

Pour résumé, ce document doit être une référence pour tout bon administrateur système qui s’occupe de serveurs Linux ou tout personne soucieuse (comme moi) des performances des bécanes !

Bon lecture.
./

Utilisation de NDC de Apache Log4J pour tracer et suivre l’exécution d’une application Java

Un fonctionnalité pratique du framework de logging Apache Log4J est le NDC (pour Nested Diagnostic Contexts). Ce dernier permet de tracer et suivre plusieurs instances d’un même traitement dans un seul fichier de log. Une utilisation typique est le fichier de log d’une application web s’exécutant sur un serveur d’applications, car plusieurs instances d’une même servlet (et de plusieurs servlets) s’exécutent en même temps pour servir les utilisateurs.

La fonctionnalité permet donc de mieux comprendre le déroulement d’un traitement, en particulier lors qu’un problème survient lors d’un tir de charges ou sur un environnement en production. Et imaginons que ce problème ‘ne se reproduit pas’ en environnement de recette / développement, et donc l’origine pourrait être ces accès multiples en même temps… Continuer la lecture de Utilisation de NDC de Apache Log4J pour tracer et suivre l’exécution d’une application Java

Tir de charges : Quand les problèmes ne viennent pas du serveur d’applications

Pour les « grands » tirs de charges dont l’objectif est de tester une nouvelle application J2EE (ou JEE) avant sa mise en production, et afin d’éviter les crashs le jour du lancement, on mobilise en général une équipe des différents « corps de métier » informatiques.

On aura ainsi :

  • les « tireurs » ceux qui vont faire le tir de charges avec un outil dédié,
  • les fonctionnels qui assistent les tireurs pour la scénarisation du tir,
  • les préparateurs de données qui sont chargés de fournir des données aux injecteurs pour le tir,
  • les gens du réseau pour la surveillance du trafic et de la bande passante,
  • les DBA pour la surveillance de l’activité de la base de données,
  • les superviseurs des serveurs d’applications pour monitorer l’activité de l’application,
  • l’équipe de développement de l’application qui croisent les doigts,
  • et bien sur les chefs du fonctionnel et les chefs de la technique

Tout cela fait beaucoup de monde, on ajoutera en général un responsable général, chargé entre autre de synchroniser toutes les actions, et donner le GO du lancement.

Une fois que le tir lancé et terminé, l’expérience montre que c’est en général du coté du serveur d’applications J2EE que les problèmes sont visibles. Où s’ils ne sont pas visibles, on pense à lui en premier car c’est lui qui supporte l’application. Alors quand c’est vous le responsable de la supervision du cluster de serveurs d’applications, tout ce beau monde se retourne vers vous pour avoir l’explication, le comment du pourquoi, afin de comprendre la raison du non succès du tir de charge…

Pourtant vous avez fait une configuration des serveurs d’applications clustérisés aux petits oignons :

  • configuration de la taille minimum et maximum idéale pour ce type d’application
  • modification des paramètres de JVM pour avoir notamment un fonctionnement du Garbage Collector en (quasi) parallèle (Concurrent Mark Sweep)
  • réglage des unités d’exécution min et max, temps d’inactivité
  • réglage du pool de connexions à la base de données, avec activation du cache des requêtes SQL préparées
  • réglage du gestionnaire de sessions
  • activation du monitoring,
  • et d’autres petits réglages de derrière les fagots : taille des files d’attente TCP, nombre des requêtes keep-alive, etc

Alors avec ce tunning de folie, difficile de comprendre pourquoi le serveur d’applications souffre lors du tir de charges… Continuer la lecture de Tir de charges : Quand les problèmes ne viennent pas du serveur d’applications

[Tutorial] Superviser un serveur Tomcat avec JMeter

JMeter est un outil qui sait faire des petites choses sympas. La supervision d’un serveur Apache Tomcat par JMeter en fait partie.

JMeter à travers la servlet de statut fournie avec le serveur Tomcat peut afficher sous forme d’un graphique le nombre d’unités d’exécution actives, la mémoire JVM utilisée, et la charge (calculée) du serveur Tomcat. JMeter peut même le faire sur plusieurs serveurs Tomcat en même temps.

Voici donc un petit tutorial pour découvrir cette fonctionnalité de JMeter. Pour cela, on utilise un serveur Tomcat version 6.0 et un JMeter 2.3.

Bonne découverte.