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.
  


 Si des Threads sont en blocage, Weblogic les remonte dans son log et le notifier dans le MBean associé au Workmanager de la ressource. Pour le log Weblogic, on a l’entrée suivante :

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


 FREQUENCE DE VERIFICATION

Penser à régler la sévérité pour pouvoir remonter l’information correctement

 



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).


 Créer un Diagnostics Modules

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)


 En final vous devriez avoir cette fenêtre (penser à modifier la fréquence de capture)


Pour visualiser les informations, 

DiagnosticsàDiagnosticsModulesàLog Filesà HarvestedDataArchiveàView


 WLST/Jython



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




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