Affichage des articles dont le libellé est MONITORING. Afficher tous les articles
Affichage des articles dont le libellé est MONITORING. 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 :
L’objectif de cet outil et de réaliser des captures de métrique MBean via JMX sur des instances Weblogic d’un domaine.
On établit un ensemble de métrique Weblogic avec une fréquence de capture et l’outil se connecte collecte et historise ceux-ci pour l’ensemble des instances d’un domaine dans des fichiers CSV.
Il permet également de visualiser ces métriques graphiquement en temps réel. Il apporte une vue agrégée par instance par rapport aux autres outils de monitoring comme la Jconsole ou Jrockit Mission Control ont l’extension de console Weblogic.
Il permet également de réaliser un paramétrage rapide en précisant les types et attributs de Mbean a capturer
ThreadPoolRuntime=HoggingThreadCount,PendingUserRequestCount,QueueLength,Throughput,ExecuteThreadTotalCount
JTARuntime=TransactionRolledBackTotalCount
JDBCDataSourceRuntime=ActiveConnectionsCurrentCount,ActiveConnectionsHighCount,CurrCapacity
JDBCOracleDataSourceRuntime=ActiveConnectionsCurrentCount
JMSDestinationRuntime=MessagesPendingCount,MessagesCurrentCount
JMSServerRuntime=MessagesPendingCount,MessagesCurrentCount
WebAppComponentRuntime=OpenSessionsCurrentCount,OpenSessionsHighCount
WorkManagerRuntime=PendingRequests,StuckThreadCount
ExecuteQueueRuntime=ExecuteThreadCurrentIdleCount,PendingRequestCurrentCount,ExecuteThreadTotalCount
JVMRuntime=HeapFreeCurrent
JRockitRuntime=HeapFreePercent,UsedPhysicalMemory,AllProcessorsAverageLoad,JvmProcessorLoad,TotalNumberOfThreads
ServerRuntime=OpenSocketsCurrentCount
ClusterRuntime=MulticastMessagesLostCount
EJBPoolRuntime=BeansInUseCurrentCount
Vous pouvez télécharger cet outil via l’URL suivante.
(attention, problème sous IE pour les téléchargement)
vendredi 28 janvier 2011
OBJECTIF
L’objectif et de mettre en place une remonté d’alerte sur la présence de threads en blocage sur la plateforme Weblogic/OSB. Pour cela on peut utiliser le module WLDF de Weblogic en remontant l’information par mail.
La procédure consiste à paramétrer Weblogic pour dire au bout de combien de temps on considère qu’un thread est en blocage pour pouvoir remonter l’information dans le log Weblogic (Message ID=BEA-320068). Cette information sera ensuite capturée par une configuration WLDF pour remonter l’information via Mail ou JMS.
L’avantage de cette méthode est que l’on n’est pas obligé de monitorer l’ensemble des WorkManager pour détecter les StuckThreads car quelque soit l’application responsable elle lèvera une notification dans le log Weblogic. L’inconvenant c’est que l’on n’aura pas la finesse de l’information sur la provenance du StuckThread.
Un thread est considéré en blocage s’il prend du temps à s’exécuter (en attente ou en exécution). Il faut donc préciser un temps au bout duquel on considère que le thread en activité est en blocage.
Pour cela, il faut préciser à Weblogic le TIMEOUT au bout duquel on marque le thread en STUCK, ainsi que la fréquence de recherche de threads en STUCK.
Pour le paramétrage du TIMEOUT, il faut se connecter à la console d’administration du domaine et de paramétrer chaque instance de la façon suivante :
${domaine}àEnvironmentàServersà${instance}àConfigurationàTuning
Stuck Thread Max Time | Le temps au bout duquel on considère que le thread est bloqué |
Stuck Thread Timer Interval | La fréquence de contrôle |
Changer la valeur de Stuck Thread Max Time en diminuant la valeur par défaut (si besoin) qui est de 10 minutes.
Exemple d’un log Weblogic sur un StuckThread
####<23 juil. 2009 03 h 14 VET> <[ACTIVE] ExecuteThread: '72' for queue: 'weblogic.kernel.Default (self-tuning)'> <> <> <> <1248335056672> <[STUCK] ExecuteThread: '64' for queue: 'weblogic.kernel.Default (self-tuning)' has been busy for "44" seconds working on the request "weblogic.servlet.internal.ServletRequestImpl@b5839e[
GET /TestFreez/Freez.jsp HTTP/1.1
Accept: */*
Referer: http://localhost:7001/console/console.portal?_nfpb=true&_pageLabel=WebAppApplicationTestingPage&handle=
com.bea.console.handles.AppDeploymentHandle%28%22com.bea%3AName%3DTestFreez%2CType
%3DAppDeployment%22%29
Accept-Language: fr
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.04506.30; .NET CLR 3.0.04506.648)
Connection: Keep-Alive
]", which is more than the configured time (StuckThreadMaxTime) of "30" seconds. Stack trace:
Thread-79 "[STUCK] ExecuteThread: '64' for queue: 'weblogic.kernel.Default (self-tuning)'" {
java.lang.Thread.sleep(Thread.java:???)
jsp_servlet.__freez._jspService(__freez.java:61)
weblogic.servlet.jsp.JspBase.service(JspBase.java:34)
weblogic.servlet.internal.StubSecurityHelper$ServletServiceAction.run(StubSecurityHelper.java:224)
weblogic.servlet.internal.StubSecurityHelper.invokeServlet(StubSecurityHelper.java:108)
weblogic.servlet.internal.ServletStubImpl.execute(ServletStubImpl.java:198)
weblogic.servlet.internal.ServletStubImpl.execute(ServletStubImpl.java:175)
weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.run
(WebAppServletContext.java:3468)
weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:308)
weblogic.security.service.SecurityManager.runAs(Unknown Source)
weblogic.servlet.internal.WebAppServletContext.securedExecute(WebAppServletContext.java:2116)
weblogic.servlet.internal.WebAppServletContext.execute(WebAppServletContext.java:2038)
weblogic.servlet.internal.ServletRequestImpl.run(ServletRequestImpl.java:1372)
weblogic.work.ExecuteThread.execute(ExecuteThread.java:198)
weblogic.work.ExecuteThread.run(ExecuteThread.java:165)
}
>
WLDF
Création d’un module WLDF pour la remontée d’alerte. Il faut pour cela :
- Créer un module WLDF pour y créer des ressources associées au monitoring.
- Créer des sources de Notifications pour pouvoir remonter les informations (Mail, JMS, etc …)
- Créer des règles de remontées d’alerte (Watchs) à associer aux sources de Notification.
Il faudra paramétrer la sévérité d’observation pour remonter les problèmes.
WLDF MODULE
La création d’un module est nécessaire pour la suite. Elle ne sert qu’a organiser et rassembler les ressources que l’on va créer par la suite.
Lock & Edit
${domaine}àEnvironmentàDiagnosticsàDiagnostic ModulesàNew
Name : Module
Description : Module de Monitoring
Ok
Activate Changes
Penser à le targer sur l’instance.
CREATION DES NOTIFICATIONS
Plusieurs sources de notifications sont possibles :
- SMTP Via une session mail
- JMS Sur une file de messages
- Diagnostique Image Dans un fichier de diagnostic
- SNMP Via une remontée SNMP
PREREQUIS
Pour une notification mail, il faut d’abord créer une Session Mail.
${domaine}àServicesàMail SessionsàDiagnostic ModulesàNew
Pour une notification JMS, il faudra créer une file de messages
${domaine}àServicesàMessagingàJMS Modulesà${module}à${queue}/${factory}
Pour une notification par trap SNMP, il faut activer l’agent dans Weblogic et paramétrer l’outil externe pour récupérer la notification.
${domaine}àDiagnosticsàSNMPàAgentsà${nom de domaine}àEnabled
CREATION DE LA SOURCE DE NOTIFICATION
Lock & Edit
Aller sous le module
${domaine}àDiagnosticsàDiagnostic Modulesà${module}àConfigurationàWatches and NotificationàNotificationsàNew
Donner un nom logique au service et son type :
Renseigner les informations associées à la source (le destinataire et le contenu du mail)
Finish
Activate Changes
CREATION DE L’ALERTE
On définit ici la règle qui déclenche l’alerte, ainsi que la source pour la remonter.
CREATION DE L’ALERTE
Lock & Edit
${domaine}àEnvironmentàDiagnosticsàDiagnostic Modulesà${module}àConfigurationàWatches and NotificationàWatchesàNew
Préciser un nom logique de la notification.
Watch Name Nom logique
Watch Type Server Log
Définition de la règle d’activation de l’alerte sur l’entrée dans le log par rapport à un Message ID particulier.
Add Expressions
Finish
ASSOCIATION DE L’ALERTE A LA DESTINATION
Se repositionner dans l’alerte définie pour lui associer une destination (Mail)
Notitication
Sélectionner la notification créée précédemment
Activate Changes
Penser à régler la sévérité pour pouvoir remonter l’information correctement
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
