mercredi 24 mars 2010

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

Le pool de thread principal est intéressant à observer, car il remonte l’activité de la JVM sur le code exécuté.
                                                                                                                           
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 …




2 commentaires:

evernat a dit…

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

Jean FRANCOIS a dit…

merci pour cette info

AUTEUR

Ma photo
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

LABEL 3D

Blogumulus by Roy Tanck and Amanda Fazani

LABEL CLOUD

MAP

Locations of visitors to this page

AUTRES BLOG

LIVRES

MEMBRES