Affichage des articles dont le libellé est TROUBLESHOOTING. Afficher tous les articles
Affichage des articles dont le libellé est TROUBLESHOOTING. Afficher tous les articles
vendredi 28 janvier 2011
08:00 | 
Publié par
Jean FRANCOIS |
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
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
mardi 14 décembre 2010
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
mercredi 14 avril 2010
Pour valider une plateforme JEE vous devez vous assurer que toutes les couches traversées fonctionnent correctement. La vérification passe par la validation des versions utilisées, le paramétrage, les testes techniques et fonctionnels, les tests de charges associés. Une architecture sécurisée est avant tout une architecture scalable et redondante afin d’anticiper les charges et incidents.
Une check liste peut être établit afin de ne pas oublier certaines parties de l’architecture ou point technique qui pourrait faire écroulé l’édifice.
ü Socle de version en accord avec le support
ü Validation réseau
ü Tuning OS
ü Tuning JVM
ü Architecture
ü Tuning WLS
ü Monitoring
ü Application
ü Validation des composants externes
ü Bench
ü Formation des équipes en charge de la plateforme
Pour isoler les risques, vous devez passer au préalable par une phase d’industrialisation de plateforme afin de sécuriser tous les éléments que vous allez mettre en place dans votre architecture.
Le fait de définir des briques de développements validés et maitrisés par tous les intervenants peut par exemple rendre plus fluide la phase de validation. De même que l’utilisation de scripting normalisé ou l’utilisation d’une virtualisation peut éviter des erreurs dans la réplication des environnements, etc ….
Il est en général recommandé de prendre les dernières versions pour embarquer un maximum de correctif et d’évolution, mais renseignez-vous sur la stabilité des nouveautés auprès des supports respectifs ou réalisés des POC.
Le plus simple étant d’établir un socle validé en interne dans le cas de l’industrialisation si la structure le permet.
Valider donc cette partie avec un expert Système en prenant en référence le guide de tuning proposé dans les documentations éditeur comme point de départ.
Valider ensuite le sizing mémoire par rapport à la machine et les options de GC à utiliser pour éviter les contentions et dysfonctionnement (GC non approprié, taille mémoire trop petite pour la charge utilisateur ou trop grande par rapport à la mémoire physique de la machine).
Concernant le JIT, toujours utiliser la version serveur qui est dédiée à un environnement de production.
Vérifier en cas d’utilisation de cluster que les composants utilisés par celui-ci fonctionnent correctement et réaliser des testes techniques (validation des load balancing, failover/failback, dialogue cluster, etc …).
On peut par contre jouer sur les pools ou cache pour obtenir des gains en temps de réponse, mais ces temps sont directement imputables au temps d’exécution JAVA du code applicatif et du backend (excepté les situations de lock).
La 1er chose à valider est le mode de fonctionnement Weblogic. Toujours prendre un domaine en mode PRODUCTION, jamais en mode DEVELOPPEMENT. En effet, ce mode spécifique aux modifications répétées de l’application permet de prendre ceux-ci en compte automatiquement. Les mécanismes mis en jeux sont trop couteux pour un environnement de production en charge et peuvent faire écroulé les temps de réponse.
· Le mode de déploiement est également important. Assurer vous que les applications sont précompilées et que le mode de déploiement est adéquat (stage/external stage/side by side)
· Rationaliser les logs générés par le serveur pour éviter trop d’écriture et mieux exploiter leurs contenus.
· Mettre en place des procédures pour être alertes en cas de défaillance de certaines ressources types threads ou datasource.
· Tailler vos pools pour assurer la charge.
· Valider les différends timeout
Fonctionnel | Pour valider que la plateforme réponde bien à la demande fonctionnelle. |
De charge | Pour valider que la plateforme va tenir la charge de production. |
De non-régression | Dans le cas d’une plate-forme mise à jour, valider que celle-ci n’a pas subit régression par rapport à la version d’avant |
Aux limites | Voir jusqu’où on peut aller (capacity planing) |
De vieillissement | Voir s’il n’y a pas de fuite mémoire |
De robustesse | Voir le comportement de la plate-forme en cas de panne ou d’incident dégradant la plate-forme. |
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
