Affichage des articles dont le libellé est MBEAN. Afficher tous les articles
Affichage des articles dont le libellé est MBEAN. Afficher tous les articles
mercredi 13 février 2013
03:25 | 
Publié par
Jean FRANCOIS |
PRINCIPE
La notion de WorkManager permet de gérer la distribution des threads sur le requetâge d’une
ressource ou d’une application. Le pool de thread est unique pour l’instance Weblogic et le WorkManager régule la demande de thread sur ce pool
fonction de contraintes et politiques.
Afin de monitorer l’allocation de ces threads, il est primordial de tracer
l’évolution des métriques du pool de thread et des WorkManager associées aux applications. Il faut
cependant connaitre les métriques à capturer et comprendre leur signification.
Une petite application test a été développée pour l’occasion afin de découvrir
le comportement du WorkManager et de ces métriques associées.
DOMAINE
Un domaine mono instance a été utilisé pour déployer l’application et le
client requête cette instance unique pour simuler la charge. Un WorkManager de nom test_workmanager a été déployé sur l’instance avec une
contrainte Max.
Lorsque le client requête l’application, celui-ci fait appel au test_workmanager pour récupérer des threads et exécuter la
requête client.
MONITORING
Lors des tests, nous allons monitorer les types suivants :
com.bea:ServerRuntime=AdminServer,Name=ThreadPoolRuntime,Type=ThreadPoolRuntime
|
|
PendingUserRequestCount
|
The number of pending user
requests in the priority queue. The priority queue contains requests from
internal subsystems and users. This is just the count
of all user requests.
|
com.bea:ServerRuntime=AdminServer,Name=test_workmanager,ApplicationRuntime=
Worker,Type=WorkManagerRuntime
|
|
PendingRequests
|
The number of waiting requests
in the queue.
|
com.bea:ServerRuntime=${server},Name=MaxThreadsConstraint-3,Type=MaxThreadsConstraintRuntime
|
|
DeferredRequests
|
Number of requests that are
denied a thread for execution because the constraint is exceeded.
|
ExecutingRequests
|
Number of requests that are
currently executing.
|
Synthèse
ThreadPoolRuntime=PendingUserRequestCount,QueueLength
WorkManagerRuntime=PendingRequests
MaxThreadsConstraintRuntime=DeferredRequests,ExecutingRequests
MONITORING
Nous allons réaliser des charges successives de 1 à 5 clients simultanés
qui appel l’application associé au WorkManager de nom test_workmanager. Ce WorkManager est paramétré avec une contrainte Max à 3 threads.
Nous allons monitorer les paramètres pending sur le pool de thread et sur le WorkManager, ainsi que sur le Mbean de la contrainte du WorkManager.
Le paramètre de Worker
et la valeur retournée du singleton de l’application qui nous indique le nombre
de requêtes simultané en cours d’exécution.
Sur un test a 1 client, nous pouvons
observer que le paramètre Pending du WorkManager représente le
nombre de threads en cours d’exécution, et non pas en attente comme nous
l’indique la documentation (The number of
waiting requests in the queue).
Au fur et à mesure que l’on augmente le
nombre de clients, le nombre de Worker
augmente proportionnellement jusqu’à la valeur maximum définie dans la
contrainte.
Arrivés à 4, nous constatons que la
métrique Pending du pool de thread
augmente. Ce qui correspond bien à des requêtes en attente d’un Threads.
Si le WorkManager ne nous permet pas de dissocier le nombre
de requêtes en attente du nombre de requête en cours, le Mbean de la contrainte associée nous permet de
faire le distinguo.
TEST MULTI APPLICATION
Ajoutons une 2 e application associée au même WorkManager, avec une deuxième charge client de nom bis. Dans ce cas de figure, nous doublons le
nombre de requête sur le WorkManager.
En regard des chiffres ci-dessous, nous pouvons constater que les
paramètres attribués au WorkMager sont globalisé sur l’ensemble des applications associées. La contrainte
d’un Max à 3 est appliquée sur
la somme des requêtes de 2 EJB
associé au WorkManager.
Libellés :
jeudi 27 janvier 2011
Présenté dans cet article les différentes façons de récupérer des métriques MBean via JMX dans un contexte Weblogic Server.
Vous pouvez lancer Weblogic avec les JVM Sun, JRockit et AIX. Les métriques peuvent être requêtées de façon native dans Weblogic (Console ou WLST) ou via des outils externes (jconsole SUN, Mission Control Jrockit). Les types de métriques exploitables sont décrits dans l’article suivant : MONITORING & MÉTRIQUES http://j-francois.blogspot.com/2010/03/monitoring-metriques.html)
WEBLOGIC console
La console Weblogic permet de récupérer les métriques et les afficher graphiquement (Voir l’article suivant : WEBLOGIC : EXTENTION DE CONSOLE http://j-francois.blogspot.com/2010/04/weblogic-extention-de-console.html )
WEBLOGIC WLDF
Weblogic Diagnostic Framework intégré dans Weblogic permet de collecter des métriques en interne de l’instance et les historiser dans des fichiers ou en base. L’exploitation de ces métriques doit être réalisée manuellement (pour plus d’information, reportez-vous à la documentation Weblogic).
DiagnosticsàDiagnosticsModulesàNew(‘Module’)
Préciser le target du modul (ActiveConnectionsCurrentCount du datasource de nom ORACLE dans l’exemple présenté)
Diagnosticsà DiagnosticsModulesà${Module}àTarget
Ajouter des métriques à collecter
Diagnosticsà DiagnosticsModulesà${Module}àCollected MetricsàNewàServerRuntimeàMBean Type
Attributes=ActiveConnectionsCurrentCount
Instance ORACLE (pour l’exemple, mon DataSource ORACLE)
Pour visualiser les informations,
DiagnosticsàDiagnosticsModulesàLog Filesà HarvestedDataArchiveàView
Via le scripting Weblogic WLST vous pouvez parcourir l’arbre des MBean et récupère leurs attributs.
Lancer WLST
@CLS
@echo OFF
@SETLOCAL
@call "${WL_HOME}\server\bin\setWLSEnv.cmd" 2> C:\temp\null
"%JAVA_HOME%\bin\java" -Dprod.props.file="%WL_HOME%\.product.properties" weblogic.WLST %
Récupération de l’attribut d’un DataSource de nom ORACLE
connect('weblogic','weblogic1','t3://localhost:7001')
serverRuntime()
cd(‘serverRuntime:/JDBCServiceRuntime/AdminServer/JDBCDataSourceRuntimeMBeans/ORACLE’)
cmo.getActiveConnectionsCurrentCount()
Ou via Jython directement l’API JMX et le nom long du MBean.
from java.util import Hashtable
from javax.management import ObjectName
from javax.management.remote import JMXConnectorFactory
from javax.management.remote import JMXServiceURL
serviceURL= JMXServiceURL("t3", "localhost", 7001, "/jndi/weblogic.management.mbeanservers.runtime")
h= Hashtable()
h.put("java.naming.security.principal", "weblogic")
h.put("java.naming.security.credentials", "weblogic1")
h.put("jmx.remote.protocol.provider.pkgs", "weblogic.management.remote")
connector = JMXConnectorFactory.connect(serviceURL, h)
connection = connector.getMBeanServerConnection()
mbeanName= "com.bea:ServerRuntime=AdminServer,Name=ORACLE,Type=JDBCDataSourceRuntime"
mbeanObjName=ObjectName(mbeanName)
attributeName="ActiveConnectionsCurrentCount"
attributeValue = connection.getAttribute(mbeanObjName, attributeName)
print "%(mbeanName)s.%(attributeName)s -> %(attributeValue)s" % vars()
Ou JAVA
import java.util.Hashtable;
import javax.management.ObjectName;
import javax.management.remote.JMXConnectorFactory;
import javax.management.remote.JMXServiceURL;
import javax.naming.Context;
import javax.management.MBeanServerConnection;
import javax.management.remote.JMXConnector;
class Test {
public static void main(String[] args) {
Hashtable h = new Hashtable();
h.put(Context.SECURITY_PRINCIPAL , "weblogic");
h.put(Context.SECURITY_CREDENTIALS, "weblogic1");
h.put(JMXConnectorFactory.PROTOCOL_PROVIDER_PACKAGES, "weblogic.management.remote");
try {
JMXServiceURL serviceURL= new JMXServiceURL("t3", "localhost", 7001, "/jndi/weblogic.management.mbeanservers.runtime");
JMXConnector connector = JMXConnectorFactory.connect(serviceURL, h);
MBeanServerConnection connection = connector.getMBeanServerConnection();
String mbeanName= "com.bea:ServerRuntime=AdminServer,Name=ORACLE,Type=JDBCDataSourceRuntime";
ObjectName mbeanObjName= new ObjectName(mbeanName);
String attributeName="ActiveConnectionsCurrentCount";
Object attributeValue = connection.getAttribute(mbeanObjName, attributeName);
System.out.println("ActiveConnectionsCurrentCount -> "+attributeValue);;
} catch (Exception exc) {
exc.printStackTrace();
}
}
}
JRockit Mission Control
Mission Control possède une vue MBean via sa console. Pour afficher les métriques Weblogic, il faut cocher les métriques suivantes dans la console et ajouter un properties JAVA sur l’instance à monitorer.
${domain name}àConfigurationàGeneralàAdvanced
Platform MBean Server Enabled (check)
Platform MBean Server Used (check)
Properties JAVA à ajouter dans le scripte de démarrage de l’instance à monitorer
-Djavax.management.builder.initial=weblogic.management.jmx.mbeanserver.WLSMBeanServerBuilder
Une fois redémarrée l’instance avec ces paramétrages, lancer l’outil JRockit et connecter vous à l’instance :
%JAVA_HOME%\bin\jrcmd.[exe/sh]
DiscoveredàLocalàWeblogic Server (cas d’une instance local à l’outil)
com.bea.AdminServer.ORACLE.JDBCConnectionPoolRuntime.ActiveConnectionCurrentCount
Vous pouvez également faire une recherche par type de MBean (JDBCConnectionPoolRuntime)
Et visualiser via un graphique.
JConsole/Visual VM
La console du JDK permet de visualiser les métriques (Voir l’article suivant : Weblogic MBean JConsole http://j-francois.blogspot.com/2010/03/weblogic-mbean-jconsole.html ). Vous pouvez utiliser le même paramétrage que présenté ci-dessus et lancer la JConsole
Platform MBean Server Enabled (check)
Platform MBean Server Used (check)
-Djavax.management.builder.initial=weblogic.management.jmx.mbeanserver.WLSMBeanServerBuilder
${JAVA_HOME}\bin\jconsole.exe
Ou via Visual VM
${JAVA_HOME}\bin\jvisualvm.exe
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
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 …
Inscription à :
Articles (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
