vendredi 23 décembre 2011
02:57 | 
Publié par
Jean FRANCOIS |
Le log est une ressource primordiale pour les environnements de production, car il permet d’historiser, et analyser les incidents et observer la bonne santé de la plateforme.
L’inconvénient est que si celle-ci est mal paramétrée, elle est souvent inexploitable et laissée de côté.
Plusieurs types de log sont gérés dans un environnement Weblogic et OSB.
ü Sortie standard de la JVM.
ü Log Weblogic et OSB.
ü Log applicative.
ü Log issue des GC de la JVM.
ü Log issue de certains framework open source et éditeur (SOA Suite).
Les principaux paramètres à gérer sont :
ü Les types de rotation.
ü Le format d’affichage.
ü L’emplacement
ü Le nom de fichier.
ü L’historisation.
Les recommandations associées à ces fichiers sont de :
ü Exposer le paramétrage accessible hors de l’application (fichier externe)
ü Pouvoir gérer dynamiquement la sévérité d’affichage indépendamment du log.
ü Pouvoir centraliser les fichiers.
ü Pouvoir uniformiser le contenu.
ü Pouvoir donner une convention au nom de fichier.
ü Trouver une politique de rotation et d’archivage commun.
ü Trouver des outils afin d’exploiter ces fichiers.
STARTEGIE
Vous pouvez utiliser plusieurs stratégies de routage de logs selon les composants (Weblogic, OSB, Pojo), les facteurs de décision étant :
ü Regroupement Regroupement d’informations dans un même fichier pour l’unicité et la séquentialité des événements.
ü Éclatement Afin de dissocier le type de contenu et maitriser la volumétrie selon le type de sévérité choisie et de composant applicatif.
Deux types de logs pour l’application à choisir selon les composants.
Avantage | Inconvénient | |
Log4J | Possibilité de dissocier les logs par fichier fonction des classes/package. Possibilité de centralisation via paramétrage selon besoin. | Peu de possibilité de rotation avec historisation dans des répertoires différents. Gestion partielle d’ID de corrélation et manuel. |
Weblogic | Gestion d’un ID de corrélation automatique (via paramétrage), et rotation par temps ou volumétrie avec répertoire de backup dissocié. Centralisation dans une seule source pour analyse avec séquentialité d’évènements. | Centralisation dangereuse en cas de positionnement de sévérité trop verbeuse. Pas de possibilité de dissociation en plusieurs fichiers selon les composants. |
Présenter ci-dessous les différentes possibilités de combinaison avec leurs avantages et inconvénients. Les tiers d’application étant les logs associés à Weblogic, les logs issus du framework OSB et ceux générés dans les Pojo JAVA appelés par OSB.
Weblogic | OSB | Pojo JAVA | Avantage | Inconvénient | Usage |
WLS | WLS | WLS | Centralisation des logs. | Gros fichier si debug | Dans le cas ou l’on souhaite la centralisation et sequentialité. |
WLS | WLS | LOG4J | Déport de logs technique. | Double paramétrage à gérer. | Dissociation du code éditeur du code spécifique applicatif et technique. |
WLS | LOG4J | LOG4J | Dissociation par composants. Ajout de sévérité supplémentaire (associé à Log4J) pour OSB. | Nécessite un codage particulier pour les logs OSB. | Dissociation par composant technique et ajout de plus de sévérité côté OSB. |
LOG4J | LOG4J | LOG4J | Centralisation des logs | Perte des fonctionnalités de rotation et d’ID de contexte | Inutile sauf dans le cas d’outil spécifique d’analyse des logs Log4J. |
ORGANISATION
Il faudra prévoir une centralisation de ces fichiers dans un filesystem dédié pour l’ensemble des instances d’une machine afin de garantir le bon fonctionnement lors de dépassement de capacité de cette ressource. Il faudra prévoir des mécanismes d’expansion de cette ressource en cas de problème et un système de backup régulier en concordance avec la politique de rotation.
Il faudra définir une politique de rotation uniforme avec éventuellement un répertoire de backup différent pour ne garder que les logs courants dans le répertoire principal. On pourra de cette façon appliquer une sauvegarde différente par rapport au log journalier de l’historiation.
Il faudra essayer de conserver la même forme de présentation dans le contenu afin d’y voir figurer :
ü Un formalisme unifié pour essayer de faire apparaitre les mêmes types de champs avec des séparateurs identiques (exploitable dans des outils).
ü La date et heure à la milliseconde pour observer les événements dans le temps.
ü Un identifiant de corrélation pour unifier les fichiers de nature différente dans le cas de recherche.
On pourra choisir un répertoire de centralisation exposé par la variable.
export LOGS_HOME=
On pourra choisir un répertoire de centralisation des logs historisé exposé par la variable.
export LOGS_HISTO_HOME=
Prendre un format de date unique à la milliseconde avec un affichage compatible avec un tri alphabétique (si besoin). Reporter ce format sur l’ensemble des logs.
yyyy/MM/dd_HH:MM:ss.SSS_z
ce qui nous donner : 2011/12/16_15:12:37.930_CET
Utiliser également un format de date en suffixe pour les historisation de fichier.
DATE="`date '+%Y_%m_%d.%H_%M_%S'`"
mv $LOG_STDOUT $LOGS_HISTO_HOME/$INSTANCE_NAME/$INSTANCE_NAME.stdout.$DATE.log
JVM
Les logs de JVM sont représentés par la sortie standard (stdout/stderr) et log GC. Ces logs ne sont pas gérés par l’infrastructure weblogic (car positionné en dessous de l’architecture) et doivent être pris en compte dans les scriptes de démarrage. Il faudra assurer leurs limitations en taille, rotation et backup.
On pourra s’appuyer sur LogRotate sous linux pour prendre en charge la rotation ou assurer celle-ci par une rotation lors du redémarrage des instances (ou une crontab).
STDOUT/STDERR
La sortie standard est associée à tous les événements de log non géré par les composants qui tournent sur celle-ci (Exception, affichage de l’application avec des System.out.println, etc … ). Le principe est de n’avoir aucune information dans celle-ci et de router les événements de log maitrisé dans des fichiers distincts. On pourra par contre dans certains cas y paramétrer tous les logs afin de router l’ensemble des informations vers celle-ci afin d’unifier l’ensemble et d’avoir la séquentialité d’affichage quelque soit les événements (besoin de debug).
Le paramétrage se fait dans le scripte de démarrage de l’instance avec une redirection sortie et erreur standard.
( nohup $HOME_DOMAINE/startWebLogic.sh 2>&1 ) > $LOGS_HOME/$INSTANCE_NAME/$INSTANCE_NAME.stdout.log &
(trap "" HUP; tail -f $LOGS_HOME/$INSTANCE_NAME/$INSTANCE_NAME.stdout.log)
Pour la rotation, on pourra mettre en place LogRotate ou une rotation à chaque redémarrage (voir un script activable via une crontab).
if [ -f $LOG_STDOUT ]
then
DATE="`date '+%Y_%m_%d.%H_%M_%S'`"
mv $LOG_STDOUT $LOGS_HISTO_HOME/$INSTANCE_NAME /$INSTANCE_NAME.stdout.$DATE.log
fi
L’analyse de log est relativement simple. Il ne doit y avoir aucune entrée. S’il y en a, il faudra investiguer sur les informations que l’on peut y trouver. On ne pourra pas s’appuyer sur des outils d’analyse, car il n’y a pas réellement de formalisme d’affichage.
LOG/GC
Les logs GC permettent de voir dans le temps la consommation mémoire de la JVM et de vérifier si cette ressource est correctement positionnée. Ils permettent également de voir si le temps passé dans les GC n’est pas trop impactant pour l’application.
L’analyse pourra se faire via GCViewer côté SUN. Côté JRockit, on pourra également utiliser les outils MissionControl avec les JRA Recording.
JRockit
set USER_MEM_ARGS = -verbose:gc -Xverbosetimestamp -Xverboselog:GC.%SERVER_NAME%.log %USER_MEM_ARGS%
SUN
Déclaration du log GC
set USER_MEM_ARGS= -verbose:gc -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -Xloggc:GC.%SERVER_NAME%.log %USER_MEM_ARGS%
Paramètre optionnel
set USER_MEM_ARGS=-XX:+PrintTenuringDistribution -XX:+PrintGCApplicationStoppedTime -XX:+PrintGCApplicationConcurrentTime -XX:TraceGen0Time -XX:TraceGen1Time %USER_MEM_ARGS%
WEBLOGIC
Les logs Weblogic sont basés sur le framework de log issu du JDK. Ils sont paramétrables via la console ou WLST. Plusieurs logs sont accessibles (on ne pourra garder que les logs Weblogic).
ü Log Weblogic Les informations de log spécifique au code de Weblogic.
ü Log Access Le requêtage Web sur l’instance (que l’on peut désactiver si pas utilisé).
ü Log Domain Weblogic remonte un certain nombre d’événements des instances managées centralisé par l’instance d’administration (fichier unique) (On pourra désactiver, car pas utiliser lors des analyses).
PARAMETRAGE
EnrironmentàServersà{instances}àLogging
· Mettre les logs Weblogic en Warning (on pourra router les logs de sortie standard dans les logs Weblogic si besoin).
· Désactiver la redirection des logs Weblogic dans la sortie standard (redondant sauf si on veut voir apparaître les informations de façon séquentielle dans un même fichier).
· Désactiver les logs du domaine, car redondant avec les logs de chaque instance.
· Désactiver les access logs du domaine s’ils ne sont pas utilisés.
CUSTOMISATION
· Pour modifier le format de date, on pourra utiliser le paramètre de JVM suivant dans le scripte de démarrage des instances pour la version Weblogic 10/11 :
-Dweblogic.log.DateFormatPattern= yyyy/MM/dd_HH:MM:ss.SSS_z
(Pour la version Weblogic 11, on pourra passer par la console Weblogic)
Consoleà${domaine}àEnvironmentàServersà${instance}àLoggingàAdvancedàDate Format Pattern
· Pour router les logs Weblogic vers le répertoire centralisé passé par la console:
Consoleà${domaine}àEnvironmentàServersà${instance}àLoggingàLog file name
$LOG/$SERVER_NAME/$SERVER_NAME.wls.yyyy%_%MM%_%dd%.log
· Pour l’historiation des logs en rotation, vous pouvez définir un répertoire dédié pour n’avoir que les logs du jour à la racine.
Consoleà${domaine}àEnvironmentàServersà${instance}àLoggingàLog file rotation directory
$LOG_HISTO/$SERVER_NAME
· Pour suffixer les logs en rotation par la date et l’heure, vous pouvez utiliser le paramétrage suivant. Modifier dans la console le Server File Name en ajoutant l’extension suivante : _%yyyy%_%MM%_%dd%
Exemple :
/var/weblogic/log/etoile/WLS-01-ETOILE8_%yyyy%_%MM%_%dd%.log
To include a time or date stamp in the file name when the log file is rotated, in the File Name field, add java.text.SimpleDateFormat variables to the file name. Surround each variable with percentage (%) characters.
For example, if you enter the following value in the File Name field:
access_%yyyy%_%MM%_%dd%_%hh%_%mm%.log
access_%yyyy%_%MM%_%dd%_%hh%_%mm%.log
the virtual host's HTTP log file will be named:
access_yyyy_MM_dd_hh_mm.log
access_yyyy_MM_dd_hh_mm.log
When the server instance rotates the HTTP log file, the rotated file name contains the date stamp. For example, if the server instance rotates the log file on 2 April, 2003 at 10:05 AM, the log file that contains the old log messages will be named:
access_2003_04_02_10_05.log
access_2003_04_02_10_05.log
If you do not include a time and date stamp, the rotated log files are numbered in order of creation filenamennnn, where filename is the name configured for the log file. For example: access.log0007.
· Vous pouvez effectuer une rotation par jour jusqu’a 7 jours pour une investigation par jour (attention au dépassement si log trop verbeux).
CONTEXT
L’activation de l’option de contexte permet de mettre en place dans Weblogic l’injection d’un identifiant de contexte pour le flux et de pouvoir récupérer celui-ci dans son propre code via l’interface suivante :
import weblogic.diagnostics.context.DiagnosticContextHelper;
DiagnosticContextHelper.getContextId()
Via la console d’administration Weblogic ou un scripte WLST, effectuer les actions suivantes sur le domaine (l’ensemble des instances mises en jeux).
Activer l’option de Diagnostic Context
Diagnostic à Context à ${server name}àEnable
Cet identifiant est géré par Weblogic et permet d’identifier le flux utilisateur parmi l’ensemble des flux générés. Il réinjecte cet identifiant sur l’ensemble des interfaces JEE (JMS/EJB/Servlet) afin de pouvoir suivre la trace du flux même avec rebond de Protocol.
####<2011/12/16_16:12:58.797_CET> <Warning> <Server> <JFRANCOI-FR> <AdminServer> <DynamicListenThread[Default[4]]> <<WLS Kernel>> <> <57fc4fbbaf008409:-55efc0b9:1344786aa8c:-8000-000000000000000a> <1324050058797> <BEA-002611> <Hostname "JFRANCOI-FR", maps to multiple IP addresses: 172.30.102.136, 192.168.166.1, 192.168.56.1, 0:0:0:0:0:0:0:1>
SEVERITE
La sévérité permet d’ajuster la verbosité du log selon les besoins. Quand vous positionnez un mode debug, il faudra impérativement activer les logs dans cette sévérité. La plupart du temps, nous nous limiterons à Info voir Warning afin de limité la taille (surtout en rotation journalière).
Plusieurs niveaux de sévérité sont définis dans la gestion de log Weblogic (du plus verbeux ou plus critique). Le message de la sévérité associé est affiché s’il est de niveau inférieur à la sévérité d’affichage défini pour le logger. Par exemple si le niveau est défini en WARNING, seules les sévérités de WARNING, ERROR, CRITICAL, MERGENCY et ALERT seront affichées.
TRACE | Used for messages from the Diagnostic Action Library. Upon enabling diagnostic instrumentation of server and application classes, TRACE messages follow the request path of a method. See “Diagnostic Action Library” in Configuring and Using the Weblogic Diagnostic Framework. |
DEBUG | A debug message was generated. |
INFO | Used for reporting normal operations; a low-level informational message. |
NOTICE | An informational message with a higher level of importance. |
WARNING | A suspicious operation or configuration has occurred but it might not affect normal operation. |
ERROR | A user error has occurred. The system or application can handle the error with no interruption and limited degradation of service. |
CRITICAL | A system or service error has occurred. The system can recover but there might be a momentary loss or permanent degradation of service. |
ALERT | A particular service is in an unusable state while other parts of the system continue to function. Automatic recovery is not possible; the immediate attention of the administrator is needed to resolve the problem. |
EMERGENCY | The server is in an unusable state. This severity indicates a severe system failure or panic. |
CONTENU
Attribute | Description |
Locale-formatted Timestamp | Time and date when the message originated, in a format that is specific to the locale. The Java Virtual Machine (JVM) that runs each WebLogic Server instance refers to the host computer operating system for information about the local time zone and format. |
Severity | Indicates the degree of impact or seriousness of the event reported by the message |
Subsystem | Indicates the subsystem of WebLogic Server that was the source of the message; for example, Enterprise Java Bean (EJB) container or Java Messaging Service (JMS). |
Machine Name Server Name Thread ID | Identifies the origins of the message: • Server Name is the name of the WebLogic Server instance on which the message was generated. • Machine Name is the DNS name of the computer that hosts the server instance. • Thread ID is the ID that the JVM assigns to the thread in which the message originated. Log messages that are generated within a client JVM do not include these attributes. For example, if your application runs in a client JVM and it uses the WebLogic logging services, the messages that it generates and sends to the WebLogic client log files will not include these attributes.container or Java Messaging Service (JMS). |
User ID | The user ID under which the associated event was executed. To execute some pieces of internal code, WebLogic Server authenticates the ID of the user who initiates the execution and then runs the code under a special Kernel Identity user ID. Java EE modules such as EJBs that are deployed onto a server instance report the user ID that the module passes to the server. Log messages that are generated within a client JVM do not include this field |
Transaction ID | Present only for messages logged within the context of a transaction. |
Diagnostic Context ID | Context information to correlate messages coming from a specific request or application. |
Raw Time Value | The timestamp in milliseconds. |
Message ID | A unique six-digit identifier. All message IDs that WebLogic Server system messages generate start with BEA- and fall within a numerical range of 0-499999. Your applications can use a Java class called NonCatalogLogger to generate log messages instead of using an internationalized message catalog. The message ID for NonCatalogLogger messages is always 000000. See "Writing Messages to the WebLogic Server Log" in Using WebLogic Logging Services for Application Logging. |
Message Text | A description of the event or condition |
####<2011/12/16_19:12:58.566_CET> <Info> <HTTP> <JFRANCOI-FR> <AdminServer> <[ACTIVE] ExecuteThread: '2' for queue: 'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <> <> <1324058578566> <BEA-101135> <AdminServer is the default Web server.>
OSB
OSB est une surcharge de Weblogic avec une implémentation de type framework JEE. Les logs seront donc routés vers les logs Weblogic.
PARAMETRAGE
Coté OSB, le niveau et l’activation se fait via la console OSB. Nous pouvons activer ou désactiver les logs OSB globalement via l’entrée suivante.
OSB consoleàOpertationsàConfigurationàGlobal SettingsàLogging
Par défaut, tout est activé. Vous pouvez régler la sévérité par Proxy via l’entrée suivante.
OSB consoleàProjet ExploreràProjetsà${le projet}à${le proxy}àOperational Settings
SEVERITE
Le mode de sévérité est plus restreint que celle de Weblogic. Le schéma ci-dessous positionne la sévérité OSB par rapport à celle de Weblogic.
CONTENU
Même affichage que ceux de Weblogic avec comme SubSystem ALSB Logging. Dans le contenu et affiché non pas le numéro de ligne, mais une indication du lieu de remontée de log, ainsi que le message lui-même.
Manque le nom du Proxy qui a généré ce log. Il faudra donc placer ce nom de Proxy systématiquement en début de message.
####<2011/12/16_19:12:31.804_CET> <Info> <ALSB Logging> <JFRANCOI-FR> <AdminServer> <[ACTIVE] ExecuteThread: '6' for queue: 'weblogic.kernel.Default (self-tuning)'> <<anonymous>> <> <86f1a03c96a033cb:52d2d99d:134480a978d:-8000-000000000000002b> <1324059031804> <BEA-000000> < [PipelinePairNode1, PipelinePairNode1_request, stage2, REQUEST] PS_Test :INFO MODE: >
JAVA/ Log4J
OSB embarque du code JAVA qui n’est pas pris en compte par les logs Weblogic. C’est donc le framework Log4J qui prend en charge cette partie. Il faudra paramétrer ces logs de la même façon que celle de Weblogic afin d’uniformiser le contenue.
PARAMETRAGE
Log4J à besoin d’un fichier de paramétrage afin de définir le mode de log, nom de fichier, emplacement et type de rotation. Dans l’exemple présenté ci-dessous, nous définissons un formalisme de contenu de log type Weblogic avec le WeblogicPattern.
Les variables utilisées dans ce fichier de paramétrage sont déclarées de la façon suivante ${nom de variables} et sont issues des porperties JAVA passés en argument de la JVM ou interne à Weblogic.
La variable WeblogicDiagnosticContext est une variable issue de JAVA log4J introduit dans le code afin d’ajouter un identifiant de flux en corrélation avec l’identifiant de contexte de Weblogic. Le code JAVA introduit cette variable (choisi par le développer) par le code suivant
String diagnosticContexID = DiagnosticContextHelper.getContextId();
if( diagnosticContexID != null ) MDC.put("WeblogicDiagnosticContext", diagnosticContexID);
et termine avec
if( diagnosticContexID != null ) MDC.remove("WeblogicDiagnosticContext");
Entre ces deux lignes, toute action de log introduira via la variable WeblogicDiagnosticContext, la valeur de DiagnosticContextHelper.getContextId qui n’est autre que l’ID de contexte de Weblogic présent dans les chapitres précédents. Via cet identifiant, nous pourrons faire des corrélations de logs avec celle de Weblogic et OSB et observer les traces d’un même flux parmi une charge.
log4j.properties
log4j.rootLogger = DEBUG
WeblogicPattern=####<%d{${weblogic.log.DateFormatPattern}}> <%p> <Log4J Logging> <${user.name}-${user.country}> <${weblogic.Name}> <%t> <%c> <%X{WeblogicDiagnosticContext}> <> <> <%m>%n
# rotation par taille
#log4j.appender.rollingFilePojo=org.apache.log4j.RollingFileAppender
#log4j.appender.rollingFilePojo.File=${logs_home}/${weblogic.Name}/${weblogic.Name}.logj.log
#log4j.appender.rollingFilePojo.MaxFileSize=2MB
#log4j.appender.rollingFilePojo.MaxBackupIndex=7
#log4j.appender.rollingFilePojo.layout = org.apache.log4j.PatternLayout
#log4j.appender.rollingFilePojo.layout.ConversionPattern=${WeblogicPattern}
# rotation par jour
#log4j.appender.rollingFilePojo=org.apache.log4j.DailyRollingFileAppender
#log4j.appender.rollingFilePojo.File=${logs_home}/${weblogic.Name}/${weblogic.Name}.lo#g4j.log
#log4j.appender.rollingFilePojo.DatePattern='.'yyyy-MM-dd-HH
#log4j.appender.rollingFilePojo.layout = org.apache.log4j.PatternLayout
#log4j.appender.rollingFilePojo.layout.ConversionPattern=${WeblogicPattern}
log4j.logger.test.Test=INFO, rollingFilePojo
Les autres variables sont issues des Properties passés en paramètre de l’instance Weblogic.
@set USER_MEM_ARGS=-Dlog4j.configuration=file:///%PARAM_HOME%/log4j.properties -Dweblogic.log.DateFormatPattern=yyyy/MM/dd_HH:MM:ss.SSS_z -Dlogs_home=%LOGS_HOME%
(On peut remarqué que le format de date utilisé par Weblogic avec la variable weblogic.log.DateFormatPattern et re injecté dans le paramétrage Log4J de façons a garder le même formalisme. On pourra également noter que la variable WeblogicPattern introduit un affichage proche de celui des logs Weblogic)
Son présent nativement dans Weblogic les properties suivant utilisé and la variable WeblogicPattern (présenté ci-dessous le log Weblogic en mode info recensant ces variables internes, dont celle passée en paramètre de la JVM).
####<2011/12/16_19:12:01.504_CET> <Info> <Management> <JFRANCOI-FR> <AdminServer> <[ACTIVE] ExecuteThread: '2' for queue: 'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <> <> <1324058581504> <BEA-141187> <Java system properties are defined as follows:
awt.toolkit = sun.awt.windows.WToolkit
common.components.home = D:\PRODUCT\MIDDLE~1\SOA\SOA_11~1.5\FMW_11~1.5\ORACLE~1
domain.home = D:\DOMAINE\TEST\@OSB\OSB_LO~1\DOMAINES\BASE_D~1
file.encoding = Cp1252
file.encoding.pkg = sun.io
weblogic.Name = AdminServer
weblogic.threadpool.MinPoolSize = 25
wls.home = D:\PRODUCT\MIDDLE~1\SOA\SOA_11~1.5\FMW_11~1.5\WLSERV~1.3\server
>
En final, nous aurons deux logs. Celle de Weblogic et de OSB avec l’identifiant de contexte.
Trace de Weblogic
####<2011/12/16_19:12:31.804_CET> <Info> <ALSB Logging> <JFRANCOI-FR> <AdminServer> <[ACTIVE] ExecuteThread: '6' for queue: 'weblogic.kernel.Default (self-tuning)'> <<anonymous>> <> <86f1a03c96a033cb:52d2d99d:134480a978d:-8000-000000000000002b> <1324059031804> <BEA-000000> < [PipelinePairNode1, PipelinePairNode1_request, stage2, REQUEST] INFO MODE: >
####<2011/12/16_19:12:31.804_CET> <Warning> <ALSB Logging> <JFRANCOI-FR> <AdminServer> <[ACTIVE] ExecuteThread: '6' for queue: 'weblogic.kernel.Default (self-tuning)'> <<anonymous>> <> <86f1a03c96a033cb:52d2d99d:134480a978d:-8000-000000000000002b> <1324059031804> <BEA-000000> < [PipelinePairNode1, PipelinePairNode1_request, stage2, REQUEST] WARNING MODE: >
####<2011/12/16_19:12:31.804_CET> <Error> <ALSB Logging> <JFRANCOI-FR> <AdminServer> <[ACTIVE] ExecuteThread: '6' for queue: 'weblogic.kernel.Default (self-tuning)'> <<anonymous>> <> <86f1a03c96a033cb:52d2d99d:134480a978d:-8000-000000000000002b> <1324059031804> <BEA-000000> < [PipelinePairNode1, PipelinePairNode1_request, stage2, REQUEST] ERROR MODE: >
####<2011/12/16_19:12:31.829_CET> <Info> <ALSB Logging> <JFRANCOI-FR> <AdminServer> <[ACTIVE] ExecuteThread: '6' for queue: 'weblogic.kernel.Default (self-tuning)'> <<anonymous>> <> <86f1a03c96a033cb:52d2d99d:134480a978d:-8000-000000000000002b> <1324059031829> <BEA-000000> < [PipelinePairNode1, PipelinePairNode1_request, stage1, REQUEST] >
####<2011/12/16_19:12:31.922_CET> <Info> <ALSB Logging> <JFRANCOI-FR> <AdminServer> <[ACTIVE] ExecuteThread: '6' for queue: 'weblogic.kernel.Default (self-tuning)'> <<anonymous>> <> <86f1a03c96a033cb:52d2d99d:134480a978d:-8000-000000000000002b> <1324059031922> <BEA-000000> < [PipelinePairNode1, PipelinePairNode1_request, stage1, REQUEST] RESULT: [null]>
Et le log des POJO OSB avec un formalisme proche et l’identifiant de contexte réinjecté pour les corrélations de logs avec ceux d’OSB et Weblogic.
Traces de Log4J
####<2011/12/16_19:12:31.920_CET> <WARN> <Log4J Logging> <JFRANCOI-FR> <AdminServer> <[ACTIVE] ExecuteThread: '6' for queue: 'weblogic.kernel.Default (self-tuning)'> <test.Test> <86f1a03c96a033cb:52d2d99d:134480a978d:-8000-000000000000002b> <> <> <WARN : test( String null )>
####<2011/12/16_19:12:31.921_CET> <INFO> <Log4J Logging> <JFRANCOI-FR> <AdminServer> <[ACTIVE] ExecuteThread: '6' for queue: 'weblogic.kernel.Default (self-tuning)'> <test.Test> <86f1a03c96a033cb:52d2d99d:134480a978d:-8000-000000000000002b> <> <> <INFO : test( String null )>
####<2011/12/16_19:12:31.921_CET> <ERROR> <Log4J Logging> <JFRANCOI-FR> <AdminServer> <[ACTIVE] ExecuteThread: '6' for queue: 'weblogic.kernel.Default (self-tuning)'> <test.Test> <86f1a03c96a033cb:52d2d99d:134480a978d:-8000-000000000000002b> <> <> <ERROR : test( String null )>
####<2011/12/16_19:12:31.921_CET> <FATAL> <Log4J Logging> <JFRANCOI-FR> <AdminServer> <[ACTIVE] ExecuteThread: '6' for queue: 'weblogic.kernel.Default (self-tuning)'> <test.Test> <86f1a03c96a033cb:52d2d99d:134480a978d:-8000-000000000000002b> <> <> <FATAL : test( String null )>
WLSLogReport
Afin d’analyser ces logs, vous pouvez utiliser l’outil WLSLogReport qui permet de faire des rapports synthétique de logs. Vous devez juste faire des adaptations par rapport au format de date. Le DateFormat permet de prendre en compte le format imposé dans les logs Weblogic (DateFormatEnforce est nécessaire car le changement de format de date n’est pas effectif tout de suite et les quelques lignes de log non customisé doivent être prise en compte).
java -jar %WLSLOGREPORT_HOME%\lib\WlsLogReport.jar input=%INPUT% output=%OUTPUT% version=%VERSION% debug="false" exact_match="false" DateFormat="yyyy/MM/dd_HH:MM:ss.SSS_z" DateFormatEnforce="dd MMM yyyy HH 'h' mm z" DateCountryEnforce="FR" DateLanguageEnforce="fr"
Grâce au formalisme imposé dans le Log4J, vous pouvez utiliser ce même outil pour les logs Log4J.
WeblogicPattern=####<%d{${weblogic.log.DateFormatPattern}}> <%p> <${user.name}-${user.country}> <${weblogic.Name}> <%t> <%c> <%X{WeblogicDiagnosticContext}> <> <> <%m>%n
IMPLEMENTATION
Le mode d’affichage imposé par OSB se présente de la façon suivante (dans Weblogic) :
####<2012/01/06_09:01:15.311_CET> <Info> <ALSB Logging> <JFRANCOI-FR> <AdminServer> <[ACTIVE] ExecuteThread: '6' for queue: 'weblogic.kernel.Default (self-tuning)'> <<anonymous>> <> <08b856e43ab126ee:-7fd9076a:134b21c7a47:-8000-0000000000000092> <1325838675311> <BEA-000000> < [Pipeline_FULL_WLS, Pipeline_FULL_WLS_request, stage_OSB_WLS, REQUEST] PS_FULL_WLS : INFO MODE: >
Pour étendre les logs OSB (avoir plus de sévérité et maitriser le message affiché) nous pouvons passer par une classe JAVA où nous pourrons prendre un affichage en renseignant en plus le nom du proxy et un libelle supplémentaire au texte du message au cas ou.
String position = "Proxy[" + proxyName + "] Pipeline[" + pipelineName + "] Request/Response["+request_response+"] Stage["+stageName+"] ["+other+"]";
Ce qui nous donnera dans le log l’affichage suivant :
Dans la construction de cette classe JAVA spécifique pour l’affichage de log d’OSB, nous pourrons exposer des méthodes par sévérité en suffixant par request/response afin d’exposer explicitement ces informations (si cela est trop contraignant lors de la saisie dans l’IDE d’OSB on pourra les rajouter en paramètres et n’avoir qu’une méthode afin de faire des copier/coller).
public static void [Request/Response]( String proxyName, String pipelineName, String stageName, String other, String libelle )
Exemple
public static void debugRequest( String proxyName, String pipelineName, String stageName, String other, String libelle )
public static void debugResponse( String proxyName, String pipelineName, String stageName, String other, String libelle )
Pour les logs dans le POJO, le principe est le même, sauf que l’utilisation se fait dans le code JAVA.
public void ( Object o ) { logger.(o.toString()); }
####<2012/01/06_10:01:59.794_CET> <Notice> <OSBJavaCallOutWLS> <JFRANCOI-FR> <AdminServer> <[ACTIVE] ExecuteThread: '6' for queue: 'weblogic.kernel.Default (self-tuning)'> <<anonymous>> <> <08b856e43ab126ee:-7fd9076a:134b21c7a47:-8000-00000000000000b5> <1325841719794> <BEA-000000> <NOTICE : test( String PS_FULL_WLS )>
WEBLOGIC[WLS] / OSB[WLS] / POJO[WLS] : PS_FULL_WLS
Dans ce cas de figure, peut de modification sont nécessaire, car OSB trace nativement dans les logs WLS.
####<2012/01/06_09:01:15.311_CET> <Info> <ALSB Logging> <JFRANCOI-FR> <AdminServer> <[ACTIVE] ExecuteThread: '6' for queue: 'weblogic.kernel.Default (self-tuning)'> <<anonymous>> <> <08b856e43ab126ee:-7fd9076a:134b21c7a47:-8000-0000000000000092> <1325838675311> <BEA-000000> < [Pipeline_FULL_WLS, Pipeline_FULL_WLS_request, stage_OSB_WLS, REQUEST] PS_FULL_WLS : INFO MODE: >
Dans le cas ou vous voulez utiliser un POJO pour étendre les logs OSB à ceux de Weblogic, vous devez utiliser le Logger de Weblogic afin de logger dans le même fichier que celui de OSB/WLS.
Utilisation d’un POJO qui récupère le logger de Weblogic
Déclaration du logger de Weblogic.
private static NonCatalogLogger logger = new NonCatalogLogger("OsbLogWLS");
Exemple d’affichage dans le log de Weblogic
####<2012/01/06_09:01:15.543_CET> <Notice> <OsbLogWLS> <JFRANCOI-FR> <AdminServer> <[ACTIVE] ExecuteThread: '6' for queue: 'weblogic.kernel.Default (self-tuning)'> <<anonymous>> <> <08b856e43ab126ee:-7fd9076a:134b21c7a47:-8000-0000000000000092> <1325838675543> <BEA-000000> <Proxy[PS_FULL_WLS] Pipeline[Pipeline_FULL_WLS] Request/Response[Request] Stage[stage_OSB_WLS_extended] []:NOTICE>
Dans cette version, nous avons rajouté le nom du Pipeline et exposé explicitement l’information request/response.
Même recommandation pour les logs dans le POJO.
Récupération du logger.
logger = new NonCatalogLogger("OSBJavaCallOutWLS");
Déclaration d’une méthode d’affichage associé à la sévérité
public void debug( Object o ) { logger.debug(o.toString()); }
Utilisation de la méthode d’affichage dans le POJO.
logger.debug( "DEBUG : test( String "+message+" )" );
WEBLOGIC[WLS] / OSB[WLS] / POJO[LOG4J] : PS_POJO_LOG4J
Vous devez déclarer un Logger Log4J dans le POJO avec un paramétrage spécifique Log4J.
private static JavaCallOutLog4J logger = new JavaCallOutLog4J(Test.class);
Affichage dans le fichier de log Log4J
####<2012/01/06_10:01:34.892_CET> <FATAL> <Log4J Logging> <JFRANCOI-FR> <AdminServer> <[ACTIVE] ExecuteThread: '6' for queue: 'weblogic.kernel.Default (self-tuning)'> <test.Test> <08b856e43ab126ee:-7fd9076a:134b21c7a47:-8000-00000000000000bd> <> <> <FATAL : test( String MESSAGE FROM PS_POJO_LOG4J )>
Avec le PATTERN Log4J
WeblogicPattern=####<%d{${weblogic.log.DateFormatPattern}}> <%p> <Log4J Logging> <${user.name}-${user.country}> <${weblogic.Name}> <%t> <%c> <%X{WeblogicDiagnosticContext}> <> <> <%m>%n
WEBLOGIC[WLS] / OSB[LOG4J] / POJO[LOG4J] : PS_OSB_LOG4J
Vous devez implémenter une méthode JAVA pour externaliser les appels à Log4J et appeler cette méthode dans OSB via des CallOutJava.
private static Logger logger = Logger.getLogger(OsbLog4J.class);
WEBLOGIC[LOG4J] / OSB[LOG4J] / POJO[LOG4J] : PS_FULL_LOG4J
Vous devez paramétrer Weblogic pour utiliser Log4J. Vous perdez par contre les sévérités et Context ID pour les corrélations.
Libellés :
Inscription à :
Publier les commentaires (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
1 commentaires:
I really liked your blog article.Really thank you! Really Cool.
Oracle Web logic training
OSB online training
Enregistrer un commentaire