Inscrivez-vous à la newsletter

Inscrivez-vous à la newsletter

Abonnez-vous maintenant et nous vous tiendrons au courant.
Nous respectons votre vie privée. Vous pouvez vous désabonner à tout moment.

Comprendre la journalisation d’événements du serveur WebLogic

Les journaux d’événements, plus communément appelés « log », sont des fichiers chronologiques enregistrés par les serveurs. Ils permettent de tracer les événement serveurs et applicatifs.
Les logs ont pour objectif de poser un diagnostic en cas de dysfonctionnement de l’environnement.
Par exemple :

  • Serveur ne démarrant pas
  • Ressources inaccessibles
  • Application ne s’exécutant pas

De précieuses informations qu’il faut savoir exploiter c’est à dire identifier, configurer et déchiffrer !
Cet article explique les fondamentaux de la gestion des logs sur Weblogic :

  • Les logs et leurs usages
  • Localisation
  • Anatomie et lecture d’un log
  • Les niveaux de trace
  • Impacts sur la performance
  • Les différents réglages
  • Les bonnes pratiques

Les logs et leurs usages

Dans un domaine Weblogic, chaque instance de serveur, ressources ou applications produisent leurs propres logs.
Par exemple, les logs générés par un serveur Admin ou Managed :

<server_name>-diagnostic.log Le fichier de diagnostic
<server_name>.log Les traces du serveur
<server_name>.out Le fichier de redirection des sorties standards et des messages d’erreurs
access.log Le fichier d’accès où sont listés chaque appel http

Localisation

Par défaut, les logs sont propres à chaque serveur.
Leur localisation est donc dans le sous-répertoire « log » du domaine auquel il appartiennent.

[DOMAIN_NAME]/servers/[SERVER_NAME]/logs

Anatomie et lecture

Chaque log contient des attributs différents.
Ci-dessous un exemple de trace :

[2010-09-23T10:54:00.206-07:00] [soa_server1] [NOTIFICATION] [] [oracle.mds]
[tid: [STANDBY].ExecuteThread: ‘1’ for queue: ‘weblogic.kernel.Default
(self-tuning)’] [userId: <anonymous>] [ecid: 0000I3K7DCnAhKB5JZ4Eyf19wAgN000001,0]
[APP: wsm-pm] « Metadata Services: Metadata archive (MAR) not found. »

Dont la lecture des des attributs est :

Timestamp, originating Date
Organization ID Serveur
Message Type Type
Component ID Ressource impactée
Thread ID Processus
User ID Utilisateur
Execution Context ID ecid: 0000I3K7DCnAhKB5JZ4Eyf19wAgN000001,0 Supplemental Attribute: APP: wsm-pm
Supplemental Attribute Attribut complémentaire (précise l’origine ; ici WSM Policy Manager)
Message Text Description de l’événement

Niveaux de sévérité

Chaque message de journalisation a un niveau de gravité associé.
Le niveau est un guide sur l’importance d’une trace et l’urgence de son traitement.
Un objet de niveau journal peut spécifier l’une des valeurs suivantes, de TRACE à EMERGENCY, soit du plus petit au plus grand impact et traduit en français :

TRACE, DÉBOGUER, INFORMATION, AVIS, AVERTISSEMENT, ERREUR, CRITIQUE, ALERTE, URGENCE

Un message de gravité inférieure à la valeur spécifiée n’est pas inscrit dans le fichier de journalisation. Par exemple, si le niveau de trace est réglé à WARNING, alors un message de niveau INFO n’est pas inscrit dans le journal.

TRACE Message produit par la librairie Diagnostic Action Library (cf. WLDF – WebLogic Diagnostics Framework Instrumentation)
DEBUG Message de debug (date d’événement, etc.)
INFO Message des opérations normales avec un faible niveau d’information
NOTICE Message d’information avec un plus haut niveau d’importance
WARNING Une opération ou une configuration semble anormale mais ne devrait pas affecter la bonne exécution des processus.
ERROR Une erreur est déclenchée. Le système gère l’erreur et devrait limiter la dégradation de service.
CRITICAL Une erreur système ou de service s’est déclenchée. Le système peut éventuellement la récupérer mais il y a sûrement perte ou dégradation temporaire de service.
ALERT Un service est définitivement perdu et la récupération automatique n’est pas possible. Les autres services continuent de fonctionner. L’intervention immédiate de l’administrateur du système est requise.
EMERGENCY Le serveur est dans un état instable. Ce niveau correspond un perte système sévère.

Impacts sur la performance

Le niveau de trace choisi a un impact direct sur la performance du serveur.

NOTIFICATION, with level 16 Impact minimal sur les performances
TRACE, with level 1 Faible impact, à positionner en production pour débugger un problème
TRACE, with level 16 Impact fort. Exclu en production, sauf cas particulier
TRACE, with level 32 Impact très fort. Proscrit en production

Réglages possibles

Les caractéristiques de journalisation d’un fichier journal local peuvent être modifiées via la console Weblogic :

  • Nom et localisation du fichier sur le disque
  • Règles de rotation
  • Niveau d’information
  • Format du fichier de log (ODL, XML)
  • La ‘localisation’ du système. Attention, joue sur l’encodage des fichiers.


 

Bonnes pratiques

Cet article a posé les bases de la lecture des logs Weblogic.
Plusieurs fonctionnalités non présentées ici sont accessibles : redirection des sorties, filtre sur les logs, …
Enfin, il est très commun de vouloir centraliser les fichiers de journalisation à un endroit unique.
Cet article a été écrit pour un WebLogic Server Version: 10.3.6.0

1 réflexion sur “Comprendre la journalisation d’événements du serveur WebLogic”

  1. Ping : Filtrer les logs du serveur WebLogic - EASYTEAM

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *