jeudi 18 mars 2010


L’objectif de ce chapitre est de présenter ici un paramétrage idéal type d’une plate-forme Weblogic Server en production. L’objectif étant de n’activer que les logs nécessaires à la récupération d’information, et dans le mode le moins verbeux. Les principes à respecter sont :

ü  Positionner les logs dans un endroit unique (logs//*.log) de façon à centraliser les informations remontées par les instances (log GC, log WLS, log stdout/stderr, log applicative). Ne pas les laisser dans le répertoire temporaire de l’instance, car ce répertoire est susceptible d’être supprimé complètement en cas de problème.

ü  Appliquer une politique de rotation commune afin d’uniformiser le contenu.

ü  Utiliser des identifiants techniques et fonctionnels qui peuvent se retrouver dans l’ensemble des fichiers,  pour effectuer des corrélations inter log (Weblogic Diagnostique Context, etc … ). Préciser un timestamp à la seconde près pour l’ensemble des logs.

ü  Utiliser un framework type log4j pour les logs applicatifs afin d’appliquer la même politique que les logs Weblogic.

ü  Utiliser des outils afin de faciliter l’analyse.

TYPES


Quatre types de logs sont présents sur un domaine WLS :


ü  Weblogic (instance, access, domaine, framework BEA)
ü  Sortie Standard (stdout, stderr)
ü  Applicatif (spécifique)
ü  Log GC

Ces logs doivent être paramétrés pour être généré au même endroit (un répertoire par instance placée hors du répertoire du domaine), de façon a mieux les exploiter et faciliter les sauvegardés. Ils doivent être mis en rotation pour éviter les dépassements de disque et mieux exploiter les données dans le temps (rotation par jour et par semaine avec si possible comme préfixe la date et l’heure de rotation). Il faut les paramétrer de la façon la moins verbeuse possible afin de se concentrer sur les évènements les plus graves, et les exploiter avec un outil d’analyse pour faciliter les investigations.

ü  Les logs Weblogic sont générés par le code Weblogic et se paramètrent dans la console WLS. Ils permettent d’obtenir des informations sur les actions ou incident intervenus dans le code du serveur d’applications.

ü  Les logs de Sortie Standard sont générés par la JVM et correspondent aux événements intervenus dans le code applicatif (ou Weblogic, si une redirection est précisée dans le paramétrage). Ils se paramètrent via le scripte de démarrage des instances WLS.

ü  Les logs applicatifs sont paramétrés et générés par l’application (code spécifique). Il faut que ces logs puissent être mis en rotation dans l’emplacement des logs de l’instance (même politique de rotation que les autres logs). Le formalisme utilisé pour le contenu doit pouvoir être exploité par un outil d’analyse afin de faciliter les recherches (filtre par ID utilisateur, etc … ).

ü  Les logs GC notifient toutes activités GC de la JVM.

 LOG WEBLOGIC


Plusieurs logs sont proposés côté Weblogic :


ü  Log Domaine     Log centralisé sur l’instance d’administration qui notifie certains événements des managées (généralement pas utilisé, donc à désactiver).
ü  Log Weblogic   Log spécifique du code Weblogic
ü  Access Log       Log des accès http sur l’instance, à n’activer que si nécessaire.
ü  Log JDBC           Log de debug JDBC couteux, a n’activer que si problème.

Concernant la politique de rotation des logs,  une rotation par jour et par redémarrage d’instance permet de clarifier les recherches, mais introduit un risque de dépassement de capacité disque si un événement parasitaire grossis ce log durant la journée. La rotation par taille est plus sécurisante, mais nécessite l’utilisation d’un outil pour faciliter son analyse. D’une façon générale prendre une politique de rotation en concordance avec la politique de backup de ces fichiers pour historisation. Appliquer cette politique à l’ensemble des logs pour les corrélations.
  
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.



·         Ne pas activer les logs JDBC car pas de trafic avec la DataBase.

CUSTOMISATION

·         Pour modifier le format de date on pourra utiliser le paramètre de JVM suivant dans le scripte de démarrage des instances :

-Dweblogic.log.DateFormatPattern=dd_MMM_yyyy_HH:mm:ss.SSSS_z

·         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
the virtual host's HTTP log file will be named:
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

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.

·         Pour les acces log, si vous exploitez ce type de log, vous pouvez ajouter des champs comme le temps passé en précisant une première fois dans le log l’information suivante (à rajouter), et en redémarrant l’instance.

DomainàEnvironmentàServersàLoggingàhttpàAdvanced

#Version:   1.0
#Fields:    time cs-method cs-uri sc-status time-taken
#Software:  WebLogic
#Start-Date:      2007-07-20  11:52:56

{domaine}àServersà{instances}àLoggingàJDBC

stdout/stderr SCRIPTE


La sortie standard remonte toutes les erreurs non liées à Weblogic (JVM, application, … ).  Ces logs sont générés par le scripte de démarrage en redirigeant la sortie standard du processus dans un fichier, ou dans un fichier spécifique dans le cas d’un lancement via le node manager. Les logs sont importants à sauvegarder, et donc réaliser un mécanisme de rotation (si pas pris en charge).

stdout commande line

Ces logs sont générés par le scripte de démarrage en redirigeant la sortie standard du processus dans un fichier.

Exemple :
DATE="`date '+%Y_%m_%d.%H_%M_%S'`"

INSTANCE=WEB-VISION-EQUANT-SNET2
ADMIN_IP=10.237.15.10
ADMIN_PORT=2408
FILE=logs/$INSTANCE.log
OLD=logs/old/$INSTANCE.$DATE.log

if [ -r $FILE.log ]
then
        mv $FILE $OLD
fi

( ./startManagedWebLogic.sh $INSTANCE http://$ADMIN_IP:$ADMIN_PORT 2>&1 ) > $FILE  &

tail –f $FILE

On peut dissocier deux flux stdout et stderr dans des fichiers séparés.

java … 1> {log_path}/stdout.log 2> {log_path}/stderr.log

-Dweblogic.Stdout=“{log_path}/stdout.log” -Dweblogic.Stderr=“{log_path}/stderr.log

stdout service

Pour le mode service Windows, il faut préciser des paramètres particuliers dans le scripte d’enregistrement de service pour rediriger ces logs.

-Dweblogic.Stdout="weblogic.stdout.txt"
-Dweblogic.Stderr="weblogic.stderr.txt"
-log:"stdout.txt"

(mis en rotation du –log mais pas du stdout et stderr !!! )

Exemple :
"%WL_HOME%\server\bin\beasvc" -install
-svcname:"%DOMAIN_NAME%_%SERVER_NAME%"
-javahome:"%JAVA_HOME%" -execdir:"%USERDOMAIN_HOME%"
-extrapath:"%WL_HOME%\server\bin" -password:"%WLS_PW%"
-cmdline:%CMDLINE%
-log:"d:\bea\user_projects\domains\myWLSdomain\myWLSserver-stdout.txt"

stdout node manager

Lors du lancement d’une instance via le node manager, celui redirige la sortie standard du processus lancé dans le fichier suivant. Ce log n’est pas limité en taille, mais mis en rotation sans limites de nombre. Il faut donc absolument purger régulièrement ces logs et ne pas rediriger les logs Weblogic dans ce fichier pour éviter un dépassement du file system.

domain_name/servers/<server_name>/logs/server_name.out 

stdout rotation

Pour assurer une rotation de ce log, on pourra utiliser les outils Apache :

Use CustomLog and the rotatelogs program:
CustomLog "| /path/to/rotatelogs /path/to/logs/access_log.%Y-%m-%d 86400" combined

Verbose GC


·         Si l’option verbosegc est activée, diriger le flux vers un fichier spécifique.

-Xloggc:{log_path}/gc.log

1 commentaires:

Tejuteju a dit…

Nice Information keep UpadatingOracle Course

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