mercredi 24 mars 2010
15:10 | 
Publié par
Jean FRANCOIS |
POURQUOI
Le monitoring de la plateforme sur les composants structurels du serveur d’applications permet de s’assurer du bon fonctionnement de la plate-forme et d’investiguer sur les problèmes rencontrés. Pour une analyse a posteriori (cold case), il faut historiser les informations. Pour être proactif sur les incidents, il faut être alerté dans le cas de dépassement de seuil. Le monitoring a donc pour objectif de :
ü Validation des paramètres d’une plateforme en BENCH.
ü Validation des paramètres d’une plate-forme de production issue de la plateforme de BENCH.
ü Être alerté sur les problèmes en cours ou avant qu’ils n’interviennent.
ü Analyser et corriger les problèmes intervenus dans le temps.
ü Optimiser l’utilisation des ressources.
ü Faire du capacity planing pour faire évoluer la plateforme sur une charge croissante.
COMMENT
Les métriques JMX sont exploitables via une API et des outils implémentant cette API afin de récupérer les valeurs, les modifier ou exécuter des méthodes.
L’objectif du monitoring est de récupérer certaines valeurs d’attribut de MBean (via JMX) afin de les historiser et alerter en cas de dépassement de seuil. Il faut donc mettre en place des outils de récupération de métrique, établir une liste de métriques à historiser et mettre en place des seuils d’alertes avec des procédures associées pour corriger la défaillance relevée.
Les métriques à collecter sont associées à l’infrastructure mise en place et aux applications déployées. Certaines d’entre elles sont présentes systématiquement.
Les métriques à relever sont de plusieurs types :
ü Performance [PERF] pour mesurer l’activité d’une instance sur une ressource.
ü Seuil [SEUIL] valeur indicative avec un seuil de déclenchement en cas de problème.
ü Composite [COMP] valeur utilisée dans un calcul.
On relève ces métriques pour différentes raisons :
ü Vérifier que le paramétrage est correct par rapport à la charge (post tuning).
ü Vérifier que la plate-forme est saine (sanity check).
ü S’assurer que la plate-forme va tenir dans le temps (capacity planing).
ü Être alerté quand quelque chose ne va pas.
ü Investiguer sur les problèmes intervenus dans le temps.
Les outils qui servent à récupérer ces métriques peuvent être de natures différentes :
ü Des outils d’infrastructure de type PATROL.
ü Des outils plus légers comme ceux proposés par le PerfPack du support BEA ou ceux proposés sur internet.
ü Des outils intégrés au produit comme WLDF.
Une méthodologie (utilisation des outils, définitions des métriques) doit être appliquée afin d’exploiter au mieux ces données et de les interpréter correctement. On pourra par exemple relever les métriques via PATROL avec une fréquence moyenne pour ne pas saturer la plate-forme afin de s’assurer de la bonne santé de la plate-forme et d’analyser dans le temps les problèmes intervenus (avec relevé d’alerte). En cas de problème on pourra brancher les outils PerfPack comme JMXDashbord afin d’avoir une visibilité sur l’ensemble de la plate-forme avec une fréquence de capture plus importante et des métriques plus nombreuse. Et en cas de dysfonctionnement utiliser la capture d’image de WLDF à remonter au support.
Attention à ne pas apporter trop de redondance sur les outils sauf si cette dernière permet de combler des failles de collecte lors des dysfonctionnements.
QUOI
Les métriques à collecter peuvent être catégorisées selon leurs types et leurs qualifications et leur évolution.
Une métrique peut être de type :
ü Variant Fluctuant dans le temps.
ü Croissant En perpétuelle extension (incrément constant). Pour obtenir une variation, il faudra faire la différence entre la valeur précédente et courante collectée.
ü Au plus haut Ce type de valeur correspond à un water mark, c'est-à-dire une valeur atteinte au plus haut des charges.
ü État Représente un statut d’une ressource (OK, KO)
ü Agrégation Une métrique composée d’un calcul issu d’autres métriques.
Elle peut être qualifiée de plusieurs façons :
ü Qualitiatif Démontre une qualité de réaction (temps de réponse, nombre de requêtes traitées)
ü Quantitatif Démontre une occupation d’une ressource (sur une taille ou un nombre).
Une métrique peut donc être interprété selon ces deux axes et la valeur prise qui peut être :
ü En dépassement de seuil (pour des valeurs croissantes ou fluctuantes)
ü A 0 ou pas (comptage des erreurs)
ü Tendant vers 0 (pour de métrique d’espace libre j)
JVM
Observer la taille mémoire de la JVM afin de valider que le paramétrage est bon au que les applications hébergées par celle-ci ne posent pas de problème.
com.bea:ServerRuntime=${server},Name=${server},Type=JVMRuntime | ||
HeapFreeCurrent | Taille mémoire restante | SEUIL |
POOL DE THREAD
com.bea:ServerRuntime=${server},Name=ThreadPoolRuntime,Type=ThreadPoolRuntime | ||
ExecuteThreadIdleCount | Nombre de threads inoccupé (libre) | COMP |
ExecuteThreadTotalCount | Nombre total de threads dans le pool | COMP |
HoggingThreadCount | Nombre de thread utilisé par des requêtes trop lent | |
StandbyThreadCount | Nombre de threads plus utilisé et mise en attente (réserve pour éviter une trop grande activité de création de threads) | COMP |
activeThreadCount | ExecuteThreadTotalCount-(ExecuteThreadIdleCount+StandbyThreadCount) | PERF |
Throughput | PERF | |
PendingUserRequestCount | Nombre de requête utilisateur en attente sur le pool de thread du serveur | SEUIL |
QueueLength | File d’attente des requêtes en utilisateur | SEUIL |
WORK MANAGER
Cette partie permet d’avoir le détail Thread par application avec les Thread bloquées.
com.bea:ServerRuntime=${server},Name=${name},ApplicationRuntime=${ressource name},Type=WorkManagerRuntime | ||
CompletedRequests | Faire le delta entre l’ancienne valeur et la nouvelle pour avoir une variation | PERF |
PendingRequests | Nombre de requêtes en attente pour l’application | SEUIL |
StuckThreadCount | Thread considéré comme bloqué soit pour des raisons d’attente ou des boucles applicatives. | SEUIL |
APPLICATION
Le nombre de sessions est important à monitorer, car il est un indicateur de fréquentation sur une application (il peut également avoir une influence sur la mémoire consommée).
com.bea:ServerRuntime=${server},Name=${server}_/${name},ApplicationRuntime=medrec,Type= WebAppComponentRuntime | |||
OpenSessionsCurrentCount | Nombre de session Web actuellement active pour l’application. | PERF | |
JDBC
L’activité du pool reflète le flux engendré sur la base. Si cette ressource fonctionne mal ou pas du tout, c’est l’application qui est rendue indisponible. Cela permet également de voir si le paramétrage est correct.
com.bea:ServerRuntime=${server},Name=${name},Type=JDBCDataSourceRuntime | ||
ActiveConnectionsCurrentCount | COMP,PERF | |
WaitingForConnectionCurrentCount | SEUIL | |
CurrCapacity | COMP | |
IdleConnections | CurrCapacity- ActiveConnectionsCurrentCount | SEUIL |
AUTRES …
Libellés :
Inscription à :
Publier les commentaires (Atom)
AUTEUR
- Jean FRANCOIS
- Carrières Sur Sein, Yvelines, France
- Consultant Oracle (Ancien consultant BEA depuis 2001), je m’occupe des expertises sur les produits Oracle : SOCLE (Weblogic, Coherence, JRockit) SOA (Service Bus, SOA Suite, BPM)
MON CV
MAP
CULTURES
LIVRES
2 commentaires:
Bonjour Jean-François,
Félicitation, je découvre ici de nombreux articles bien documentés sur weblogic, en particulier pour les configurations ayant un volume élevé de requêtes.
Pour ce qui est du monitoring, un outil peut t'intéresser : http://javamelody.googlecode.com (opensource, en français ou en anglais).
Il inclut des métriques avec historique, certes pas encore les métriques spécifiques à weblogic, mais aussi d'autres qui ne sont pas dans les outils weblogic.
Bonne journée, Emeric
merci pour cette info
Enregistrer un commentaire