Diagnostic d'Applications Distribuées

Guide méthodique pour l'analyse des performances

🔍

Architecture Cible

Cette fiche de diagnostic est conçue pour résoudre les problèmes de ralentissement dans une architecture distribuée composée des éléments suivants:

  • JBoss Domain - Serveurs d'application
  • Apache - Reverse proxy sur serveur dédié
  • MQ - Message broker
  • Oracle Database - Sur serveurs dédiés

Cette méthode vous permettra d'identifier rapidement la source des ralentissements dans votre architecture distribuée, en utilisant uniquement les outils natifs disponibles sur RedHat.

Phase 1: Vue d'ensemble et identification de la zone problématique

Étape 1.1: Vérifier l'expérience utilisateur et collecter des indicateurs précis

Commencez par mesurer le temps de réponse réel depuis un poste client:

time curl -s [URL_application]/[endpoint_critique]

Points à identifier:

  • Notez les temps de réponse et les URLs problématiques
  • Identifiez si le problème est généralisé ou spécifique à certaines fonctionnalités

Étape 1.2: Analyser les logs Apache (point d'entrée) pour les temps de réponse

Sur le serveur Apache, examinez les logs pour identifier les réponses lentes ou en erreur:

tail -n 1000 /var/log/httpd/access_log | grep -v "200" | sort -k 4
grep -E "[5|4][0-9][0-9]" /var/log/httpd/error_log | tail -n 100

Points à rechercher:

  • Codes d'erreur 4xx, 5xx
  • URLs lentes ou en erreur

Étape 1.3: Vérifier les métriques système sur chaque couche

Sur chaque serveur (Apache, JBoss, MQ, Oracle), exécutez les commandes suivantes:

uptime
top -b -n 1 | head -n 12
free -m
df -h
netstat -an | grep ESTABLISHED | wc -l

Comparez les charges entre serveurs pour identifier les points chauds

Phase 2: Analyse de la couche Apache (Reverse Proxy)

Étape 2.1: Analyse des performances Apache

Vérifiez les connexions actives et les processus Apache:

# Connexions actives netstat -an | grep ":80" | grep ESTABLISHED | wc -l netstat -an | grep ":443" | grep ESTABLISHED | wc -l
# Processus Apache et leur consommation ps -eo pid,ppid,cmd,%cpu,%mem --sort=-%cpu | grep httpd
# File d'attente de connexions netstat -an | grep ":80" | grep SYN | wc -l

Points à surveiller:

  • Si >80% des workers Apache sont occupés, le proxy est probablement saturé
  • Recherchez les files d'attente importantes de connexions en SYN_RECV

Étape 2.2: Vérification des temps de réponse backend

# Activez temporairement les logs détaillés si nécessaire grep "proxy_http" /var/log/httpd/error_log | tail -n 100

Analysez les temps de communication entre Apache et JBoss

Phase 3: Analyse de la couche JBoss (Serveurs d'application)

Étape 3.1: Vérification de la santé du domaine JBoss

# Utilisez le CLI JBoss si disponible $JBOSS_HOME/bin/jboss-cli.sh --connect --command="/host=*/server=*/server-state"
# Sinon vérifiez les processus JBoss ps -eo pid,ppid,cmd,%cpu,%mem --sort=-%cpu | grep java

Vérifiez si:

  • Tous les nœuds du domaine sont actifs
  • La répartition de charge entre les instances est équilibrée

Étape 3.2: Analyse des threads JBoss

# Pour chaque PID JBoss ps -T -p [PID_JBoss] | wc -l cat /proc/[PID_JBoss]/status | grep Threads
# Threads en attente potentielle sur les connexions DB ps -T -p [PID_JBoss] | grep -i jdbc
# Threads actifs vs threads en pool cat $JBOSS_HOME/domain/servers/*/log/server.log | grep "thread.*pool"

Un grand nombre de threads actifs peut indiquer des problèmes de ressources ou de connexions

Étape 3.3: Vérification des logs JBoss

# Erreurs critiques grep -E "ERROR|FATAL" $JBOSS_HOME/domain/servers/*/log/server.log | tail -n 100
# Temps d'exécution longs grep -i "execution time" $JBOSS_HOME/domain/servers/*/log/server.log | sort -rn -k 10

Recherchez des exceptions liées à des timeouts ou des rejets de connexion

Phase 4: Analyse de la couche MQ (Messaging)

Étape 4.1: Analyse des files d'attente

# Pour IBM MQ, ActiveMQ, ou autre système - commandes adaptées au type de MQ # Processus MQ ps -eo pid,ppid,cmd,%cpu,%mem --sort=-%cpu | grep -E "mq|activemq|rabbitmq"
# Connexions au broker netstat -an | grep "[port_MQ]" | grep ESTABLISHED | wc -l

Recherchez:

  • Des files d'attente qui croissent continuellement
  • Des messages qui restent bloqués sans être consommés

Étape 4.2: Vérification des logs MQ

# Logs MQ spécifiques à votre broker tail -n 500 /var/log/[mq_system]/[mq_log].log | grep -E "error|warning|timeout"

Recherchez des problèmes de connexion ou de traitement des messages

Phase 5: Analyse de la couche Oracle (Base de données)

Étape 5.1: Analyse du serveur Oracle

# Processus Oracle et consommation ps -eo pid,ppid,cmd,%cpu,%mem --sort=-%cpu | grep oracle
# Connexions à la base de données netstat -an | grep ":1521" | grep ESTABLISHED | wc -l
# Espace disque des tablespaces Oracle (si accès aux outils Oracle) df -h /u01/app/oracle # Ou autre mount point Oracle

Points d'attention:

  • Une utilisation CPU élevée peut indiquer des requêtes non optimisées
  • Un grand nombre de connexions peut indiquer une saturation du pool

Étape 5.2: Vérification des logs Oracle

# Alertes Oracle tail -n 500 $ORACLE_BASE/diag/rdbms/$ORACLE_SID/$ORACLE_SID/trace/alert_$ORACLE_SID.log
# Logs de listener tail -n 200 $ORACLE_HOME/network/log/listener.log

Recherchez des erreurs ORA-, particulièrement ORA-00054 (verrouillages) ou ORA-04031 (mémoire)

Phase 6: Analyse des interactions entre couches

Étape 6.1: Vérification des temps de connexion réseau entre couches

# Du serveur JBoss vers Oracle time nc -zv [IP_Oracle] 1521
# Du serveur JBoss vers MQ time nc -zv [IP_MQ] [Port_MQ]
# Du serveur Apache vers JBoss time nc -zv [IP_JBoss] [Port_JBoss]

Des latences réseau élevées (>10ms en LAN) peuvent indiquer des problèmes réseau

Étape 6.2: Analyse des connexions pool

# Dans les logs JBoss, recherchez les pools de connexion grep -i "pool" $JBOSS_HOME/domain/servers/*/log/server.log | grep -E "jdbc|jms"

Des attentes sur les pools de connexion indiquent généralement un manque de connexions disponibles

Arbres de décision pour diagnostic

1. Si les temps de réponse sont uniformément lents

Apache saturé ?

  • Nombre élevé de connexions simultanées (vérifiez netstat)
  • Processus Apache consommant beaucoup de CPU
  • Si oui : Ajustez les paramètres (MaxClients, KeepAliveTimeout) ou augmentez les ressources

JBoss saturé ?

  • Utilisation CPU élevée sur les nœuds JBoss
  • File d'attente des threads élevée
  • Si oui : Vérifiez le garbage collection, ajustez heap, ou ajoutez des nœuds

Oracle saturé ?

  • Utilisation CPU élevée sur Oracle
  • Grand nombre de sessions actives
  • Si oui : Analysez les requêtes lentes, optimisez indexation

2. Si les temps de réponse sont erratiques

Problèmes réseau ?

  • Latences variables entre composants
  • Paquets perdus
  • Si oui : Vérifiez switches/routeurs, MTU, congestion réseau

Contention MQ ?

  • Files d'attente qui s'accumulent
  • Messages traités lentement
  • Si oui : Optimisez consommation des messages, augmentez les consommateurs

3. Si des fonctionnalités spécifiques sont lentes

Requêtes spécifiques lentes ?

  • Identifiez les URLs/transactions lentes dans les logs Apache
  • Corrélation avec des transactions DB spécifiques
  • Si oui : Optimisez ces requêtes, ajoutez des index ciblés

Rapport de diagnostic structuré

Symptômes observés

  • Temps de réponse précis
  • Fonctionnalités affectées
  • Moment d'apparition du problème

Goulot d'étranglement identifié

  • Composant (Apache, JBoss, MQ, Oracle)
  • Ressource limitante (CPU, mémoire, I/O, réseau, pool de connexions)
  • Métriques prouvant le diagnostic

Cause probable

  • Analyse technique détaillée
  • Facteurs déclenchants identifiés

Actions recommandées

  • Court terme (augmentation ressources, redémarrage ciblé)
  • Moyen terme (optimisation des requêtes/code, réglage des paramètres)
  • Long terme (revue architecture, modifications structurelles)