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”
Ping : Filtrer les logs du serveur WebLogic - EASYTEAM
Les commentaires sont fermés.