jeudi 27 janvier 2011
04:50 | 
Publié par
Jean FRANCOIS |
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
Libellés :
lundi 17 janvier 2011
Lors de l’absence d’une ressource déclarée sur une instance managée (JDBC, application), celle-ci démarre dans le statut ADMIN. Ce statut particulier de l’instance correspond à un processus monté avec les données en mémoire, mais ne répondant pas aux sollicitations utilisateur.
Ce fonctionnement permet de ne pas rendre disponible une instance si un de ces composants n’est pas correctement monté, mais cela peut devenir contraignant si la ressource non disponible n’est pas essentielle au bon fonctionnement de l’instance (une instance d’administration non montée avec le mode MSI, ou un nœud cluster DATABASE non présent dans le cas de Oracle RAC et d’un multidatasource).
Pour ne pas passer dans ce mode au démarrage d’une instance avec des ressources non valide, vous pouvez utiliser le paramètre de JVM suivant (à placer dans le scripte de démarrage des instances WLS)
-Dweblogic.deployment.IgnorePrepareStateFailures=true
BSU ou Smart Update est un outil du support qui permet de gérer les PATCH issues du support ORACLE. L’intérêt de cet outil est qu’il offre une interface officielle avec le support (téléchargement de PATCH) et qu’il gère l’installation avec des profiles différents et positionne le correctif automatiquement dans le CLASSPATH des instances sans devoir retoucher aux scriptes de démarrage (importance de la précédence des CLASSPATH dans le code exécuté)
C’est un outil utilisable graphiquement ou en ligne de commande et qui utilise un repository fichier dans un répertoire ou il stocke les JAR PATCH et un fichier XML de configuration.
Le processus d’application de PATCH est en deux temps. Il faut d’abord récupérer les PATCH officiels via le réseau (via le site du support) pour les stockers physiquement dans le répertorie repository, puis les appliquer sur l’installation Oracle avec le bon profile (default pour les PATCH globaux).
OUTIL
BSU est fourni dans la distribution Weblogic sous le répertoire suivant.
${BEA_HOME}\utils\bsu\bin\bsu.[cmd/sh]
Dans le cas d’un environnement non graphique, il faut déclarer la variable d’environnement renseignant le proxy d’entreprise ainsi que le display de redirection pour déporter l’environnement graphique sur un post possédant un serveur X.
export HTTP_PROXY="http://:"
export DISPLAY=<ip du poste qui va afficher l’IHM>:0.0
Il faut installer un serveur X sur le poste qui se charge de l’affichage de l’IHM. Dans le cas de Windows on pourra prendre XMing. Une fois celui-ci installer, il faut modifier le fichier Xming hosts "C:\Program Files (x86)\Xming\X0.hosts" pour y placer l’adresse du serveur linux qui va rediriger la partie graphique (afin d’autoriser le déport du display sur la partie Windows).
X0.hosts
localhost
<ip du poste sur lequel on lance BSU>
Une fois renseigner ces informations et lancé Xming sur le poste Windows lancer l’outil qui offre.
cd ${BEA_HOME}/utils/bsu
export DISPLAY=<ip du poste qui va afficher l’IHM>:0.0
export HTTP_PROXY="http://:"
./bsu.sh
RECUPERAITON DES PATCHS
Cette phase nécessite un accès réseau et Web pour joindre le site du support. On lance l’outil en mode graphique.
[osb@osb bsu]$ cd ${BEA_HOME}/utils/bsu
[osb@osb bsu]$ export DISPLAY=<ip du poste qui va afficher l’IHM>
[osb@osb bsu]$ export http_proxy="http://:"
[osb@osb bsu]$ ./bsu.sh
Renseigner votre identifiant support
Attendre la connexion
Dans le cas ou vous avez cette fenêtre, re préciser le proxy en vous connectant à l’application en mode Offline
Aller sous FileàPreferencesàProxy pour y re spécifier le proxy.
Reconnecter vous avec le compte support
L’IHM divise l’écran en deux parties. La partie gauche représente les produits installés sur la machine et la droite les PATCH installée sur les produits. Nous avons sur l’onglet Manage Patches les PATCH installé et les PATCH téléchargé, mais pas encore déployé. Sur l’onglet Get Patchs la liste des patchs officielles pas encore déployées ni téléchargées.
Pour récupérer un PATCH spécifique, il faut passer par le menu PatchesàRetrieve Private
Et entrer le Patch identifié et le Passcode fourni par le support.
Vous obtenez-en final le PATCH téléchargé dans la fenêtre du bas est dans le répertoire suivant :
${BEA_HOME}/utils/bsu/cache_dir
DEPLOIEMENT DES PATCHS
Pour la gestion des PATCH en mode non graphique vous pouvez utiliser l’outil en ligne de commande pour installer ou enlever un PATCH. Il faut d’abord récupérer le PATCH en mode graphique avec un accès Internet ou récupérer le répertoire cache_dir contenant le PATCH et le copier sous le répertoire bsu (${BEA_HOME}\utils\bsu).
Pour installer un PATCH OSB de nom ALFJ, lancer la commande avec les options suivantes :
[osb@osb bsu]$./bsu.sh -install -patchlist=ALFJ -prod_dir=${BEA_HOME}/osb_10.3
Checking for conflicts..
No conflict(s) detected
Installing Patch ID: ALFJ.
Result: Success
install | commande d’installation |
patchlist | le nom ou la liste des PATCH à installer (déjà présent dans le répertoire cache_dir) |
prod_dir | le répertoire d’installation de Weblogic ou des produits Oracles (OSB/BPEL/etc …) |
Pour vérifier que le PATH est correctement installé, lancer la commande avec l’option report.
./bsu.sh –report
Patch Report
============
Report Info
Report Options
bea_home.................. ### OPTION NOT SET
product_mask.............. ### OPTION NOT SET
release_mask.............. ### OPTION NOT SET
profile_mask.............. ### OPTION NOT SET
patch_id_mask............. ### OPTION NOT SET
Report Messages
BEA Home.................. /home/osb/bea
Product Description
Product Name.............. WebLogic Server
Product Version........... 10.3.0.0
Installed Components...... Core Application Server, Administration Console, Configuration Wizard and Upgrade Framework, Web 2.0 HTTP Pub-Sub Server, WebLogic JDBC Drivers, Third Party JDBC Drivers, WebLogic Server Clients, WebLogic Web Server Plugins, UDDI and Xquery Support, Evaluation Database, Workshop Code Completion Support
Product Install Directory. /home/osb/bea/wlserver_10.3
Java Home................. /home/osb/bea/jdk160_05
Jave Vendor............... Sun
Java Version.............. 1.6.0_05
Patch Directory........... /home/osb/bea/patch_wls1030
…
Patch ID.................. ALFJ
CR(s)..................... 10390024
Description............... OSB 10.3 - STUCK THREADS IN SFTP PROXY SERVICE
Shared archives
Destination............... $ALSB_INSTALL_DIR$/3rdparty/lib/j2ssh-core.jar
Operation................. inject
File...................... com/sshtools/j2ssh/connection/Channel.class
File...................... com/sshtools/j2ssh/connection/ChannelDataWindow.class
L’option remove permet de faire l’inverse.
mardi 14 décembre 2010
Quand vous démarrez une instance Weblogic en mode production et que vous ne spécifiez pas le login et password, la phase de démarrage passe en mode saisie manuelle pour vous demander ces informations. Cela peut poser problème si l’on souhaite lancer les instances automatiquement (lors du démarrage de la machine ou autre).
Un fichier permet de spécifier ces informations et à pour nom boot.properties avec pour contenu :
username=
password=
Lors du 1er démarrage l’instance encrypte son contenu pour masquer le mot de passe.
#Wed Dec 08 07:01:04 CET 2010
password={AES}VWEJOh90VsB1IZJXzNILQk6IW8G3y53dd1+TjTtceQ8\=
username={AES}NhXEE6ZdqYsNVMkZcA9o9AE3RS291sRYarPJJRZ0kUI\=
En version antérieure à la 10 il suffisait de placer ce fichier à la racine du domaine pour que celui-ci soit pris en compte pour l’ensemble des instances déclarées dans le domaine. Il semble que cela ne soit plus vrai en 10.3.3.
Il faut avant chaque 1er démarrage d’une instance créer le répertoire et fichier ${domaine_home}/servers/${instance_name}/security/boot.properties, ce qui est fortement astreignant.
Pour revenir à l’ancien mode, il suffit d’ajouter dans les paramétrages de JVM des instances le properties JAVA suivant avec comme valeur, le PATH ou se trouve le fichier boot.propertis (par exemple, la racine du domaine).
-Dweblogic.system.BootIdentityFile=${domaine_home}/boot.properties
Vous pouvez l’injecter dans les scriptes standards via la variable USER_MEM_ARGS ou le place en dure dans les scriptes génériques.
Lors d’un déploiement d’une application dans un domaine SOA 11G, il faut faire attention au paramétrage du domaine sur lequel on cible le déploiement. En effet SOA Suite utilise le produit Coherence pour propager l’application sur le domaine. Ce produit introduit une notion de cluster différente du cluster Weblogic et utilise une IP et un PORT de dialogue non exposé lors de l’installation du domaine.
Si le domaine ne re spécifie pas ces informations et qu’il partage le réseau avec d’autres domaines SOA, l’application risque de se déployer sur les autres domaines si il n’y a pas d’étanchéifiassions du réseau ou si le paramétrage n’est pas customisé.
Prenons l’exemple de deux domaines déployés sur deux machines différentes avec le même nom de domaine est d’instance sur le même réseau. Le paramétrage par défaut du cluster Coherence est 227.7.7.9 sur le port 9778 (vous pouvez le vérifier dans le log de l’instance en cherchant l’occurrence tangosol.coherence.clusteraddress sur les Java system properties)
Donc s’il on déploie une application sur l’instance Managed 1 du cluster du domaine de la machine A, elle sera également propagé aux instances de la deuxième machine car l’adresse cluster Coherence est la Même (problème si se sont deux environnement différents).
Pour éviter ce problème, il faut soit étanchéifier le réseau entre les deux machines pour que la connexion ne s’effectue pas.
-Dtangosol.coherence.clusteraddress=227.7.7.8
-Dtangosol.coherence.clusterport=9978
Ou éviter les rebonds sur les autres machines avec un Time To Live à 0
-Dtangosol.coherence.ttl=0
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
