Journalisation et trace

Le produit possède un composant de journalisation unifié qui traite les messages écrits par le produit et qui fournit un outil de diagnostic de premier niveau.

De plus, le composant de journalisation capture les messages qui sont écrits dans System.out, System.err, java.util.logging et les journaux OSGi. Il unifie le traitement de ces messages avec d'autres messages écrits par le produit. Il ne peut pas capturer les messages qui sont écrits directement par le processus de machine virtuelle Java, comme la sortie -verbose:gc.

Il existe trois fichiers journaux principaux pour un serveur :
  1. console.log - il contient la sortie standard et l'erreur standard redirigées du processus de machine virtuelle Java. Cette sortie de console est destinée à une utilisation humaine directe. La sortie de la console contient les événements et les erreurs principaux si vous utilisez la configuration consoleLogLevel par défaut. Elle contient également les messages écrits dans les flux System.out et System.err si vous utilisez la configuration copySystemStreams par défaut. La console contient toujours les messages écrits directement par le processus de machine virtuelle Java, par exemple la sortie -verbose:gc. Ce fichier n'est créé que si la commande server start est utilisée et son emplacement peut être modifié uniquement à l'aide de la variable d'environnement LOG_DIR. Pour plus d'informations, voir Administration du profil Liberty depuis la ligne de commande.
  2. messages.log - il contient tous les messages sauf les messages de trace qui sont écrits ou capturés par le composant de journalisation. Tous les messages qui sont écrits dans ce fichier contiennent des informations supplémentaires, par exemple l'horodatage du message et l'ID de l'unité d'exécution à l'origine du message. Il ne contient pas les messages qui sont écrits directement par le processus de machine virtuelle Java.
  3. trace.log - il contient tous les messages qui sont écrits ou capturés par le produit. Il n'est créé que si vous activez la trace supplémentaire. Il ne contient pas les messages qui sont écrits directement par le processus de machine virtuelle Java.

Configuration de la journalisation

Vous pouvez contrôler le composant de journalisation via la configuration de serveur. L'emplacement principal de la configuration de journalisation se trouve dans le fichier server.xml. Parfois, il peut être nécessaire de configurer la trace afin de diagnostiquer un problème qui survient avant le traitement du fichier server.xml. Dans ce cas, les propriétés de configuration équivalentes peuvent être spécifiées dans le fichier bootstrap.properties. Si une propriété de configuration est spécifiée dans le fichier bootstrap.properties ainsi que dans le fichier server.xml, la valeur figurant dans le fichier bootstrap.properties est utilisée jusqu'à ce que le fichier server.xml soit traité. Ensuite, la valeur figurant dans le fichier server.xml est appliquée. Evitez de spécifier des valeurs différentes pour une même propriété de configuration dans le fichier bootstrap.properties et le fichier server.xml.
Tableau 1. Propriétés de journalisation pour le profil Liberty. La colonne 1 contient les attributs qui peuvent être définis dans le fichier server.xml. La colonne 2 contient les propriétés équivalentes utilisables dans le fichier bootstrap.properties. La colonne 3 fournit une description de chaque propriété de journalisation.
Attribut Propriété équivalente Description
logDirectory
com.ibm.ws.logging
.log.directory
Cet attribut définit le répertoire de tous les fichiers journaux, y compris des fichiers journaux de l'outil de diagnostic de premier niveau, en excluant le fichier console.log. Par défaut, logDirectory est associé à la variable d'environnement LOG_DIR. Le chemin par défaut de la variable d'environnement LOG_DIR est WLP_OUTPUT_DIR/serverName/logs.
Eviter les incidents : utilisez la variable d'environnement LOG_DIR ou la propriété com.ibm.ws.logging.log.directory plutôt que l'attribut logDirectory pour configurer le répertoire dans lequel vous voulez que tous les messages soient écrits. Sinon, peu de messages sont initialement écrits dans le répertoire logs par défaut, puis les messages restants sont écrits dans le répertoire indiqué en fonction de votre configuration. L'attribut logDirectory peut être utilisé pour mettre à jour de manière dynamique les journaux dans le répertoire indiqué alors que le serveur est en cours d'exécution.
maxFileSize
com.ibm.ws.logging
.max.file.size
Taille maximale (en mégaoctets) d'un fichier journal avant le roulement. L'environnement d'exécution du profil Liberty procède au roulement des journaux en fonction de la taille uniquement. Pour désactiver cet attribut, définissez la valeur 0. La taille de fichier maximale est approximative. Par défaut, la valeur est 20.
Remarque : maxFileSize ne s'applique pas au fichier console.log.
maxFiles
com.ibm.ws.logging
.max.files
Si une taille de fichier maximale est appliquée, ce paramètre détermine combien de fichiers journaux de chaque type sont conservés. Ce paramètre s'applique également au nombre de journaux des exceptions qui récapitulent les exceptions survenues au cours d'un jour donné. Par conséquent, si la valeur choisie est 10, le répertoire ffdc/ pourra contenir jusqu'à 10 journaux de messages, 10 journaux de trace et 10 journaux récapitulatifs des exceptions. Par défaut, la valeur est 2.
Remarque : maxFiles ne s'applique pas au fichier console.log.
consoleLogLevel
com.ibm.ws.logging
.console.log.level
Ce filtre contrôle la granularité des messages envoyés au fichier console.log. Les valeurs admises sont INFO, AUDIT, WARNING, ERROR et OFF. Le niveau par défaut est AUDIT.
Pour plateformes répartiesRemarque : Avant de changer cette valeur, prenez connaissances des informations de la section "Impossible d'interagir avec le serveur de profil Liberty après la modification des paramètres de niveau de journalisation de la console" dans la rubrique Problèmes et restrictions connus concernant les outils de développement.
copySystemStreams
com.ibm.ws.logging.
copy.system.streams
Si la valeur est true, les messages écrits dans les flux System.out et System.err sont copiés dans console.log. Si la valeur est false, ils sont écrits dans des journaux configurés tels que messages.log ou trace.log, mais ils ne sont pas copiés dans console.log. La valeur par défaut est true.
messageFileName
com.ibm.ws.logging
.message.file.name
Le journal des messages porte le nom par défaut messages.log. Ce fichier existe toujours et contient les messages du niveau INFO et des autres niveaux (AUDIT, WARNING, ERROR, FAILURE), en plus des messages envoyés aux flux standard System.out et System.err. Ce journal contient également des horodatages et l'ID de l'unité d'exécution émettrice. Si le fichier journal est substitué, les noms de fichiers journaux antérieures ont le format messages_horodatage.log
suppressSensitiveTrace   La trace de serveur risque d'exposer des données sensibles lors du suivi de données sans type, tels les octets reçus via une connexion réseau. Si sa valeur est true, cet attribut empêche l'exposition des informations potentiellement sensibles dans les fichiers journaux et de trace. La valeur par défaut est false.
traceFileName
com.ibm.ws.logging
.trace.file.name
Le fichier trace.log est seulement créé si la trace supplémentaire ou détaillée est activée. stdout est considéré comme une valeur spéciale qui a pour effet de diriger la trace vers le flux de sortie standard d'origine.
traceSpecification
com.ibm.ws.logging
.trace.specification
La chaîne de trace est utilisée pour activer la trace de façon sélective. La valeur par défaut est *=info.
traceFormat
com.ibm.ws.logging
.trace.format
Cet attribut contrôle le format du journal de trace. Le format par défaut pour le profil Liberty est ENHANCED. Vous pouvez aussi utiliser les formats BASIC et ADVANCED, comme dans le profil complet.
[8.5.5.4 ou ultérieure]hideMessage
com.ibm.ws.logging.hideMessage
Vous pouvez utiliser l'attribut hideMessage pour configurer les messages que vous voulez masquer dans les fichiers console.log et message.log. Si les messages sont configurés pour être masqués, ils sont redirigés vers le fichier trace.log.
Pour plateformes répartiesRemarque : Avant d'utiliser cet attribut, prenez connaissance des informations fournies sous la section Impossible de reconnaître le démarrage du serveur lorsque l'attribut hideMessage est utilisé pour supprimer les messages de la rubrique Problèmes et restrictions connus concernant les outils de développement topic.
Vous pouvez définir des propriétés de journalisation dans le fichier de configuration de serveur en sélectionnant Journalisation et traçage dans la vue Configuration de serveur dans les outils de développement, ou en ajoutant un élément de journalisation au fichier de configuration de serveur comme suit :
<logging traceSpecification="*=audit:com.myco.mypackage.*=finest"/>
Le format de la spécification de niveau de détail de journal est le suivant :
<composant> = <niveau>

<composant> correspond au composant pour lequel un niveau de détail de journal doit être défini, et <niveau> à l'un des niveaux de journal d'événements valides (désactivé, fatal, grave, avertissement, audit, info, config, détail, fin, plus fin, le plus fin, tous). Plusieurs spécifications de niveau de détail de journal doivent être séparées par deux points (:).

Avertissement : Pour un consignateur donné, le niveau est déterminé par la spécification de trace la plus spécifique qui s'applique à ce consignateur.
Les composants correspondent aux modules et classes Java™ ou aux collections de modules Java. Utilisez un astérisque (*) comme caractère générique pour indiquer les composants qui comportent toutes les classes de tous les packages contenus par le composant spécifié. Exemple :
*
Indique tout le code traçable qui s'exécute sur le serveur d'application, y compris le code système produit et le code client.
com.ibm.ws.*
Spécifie toutes les classes dont le nom de package commence par com.ibm.ws.
com.ibm.ws.classloader.JarClassLoader
Spécifie uniquement la classe JarClassLoader.
Tableau 2. Niveaux de journalisation valides. Le tableau suivant répertorie les niveaux valides pour les serveurs d'applications sur WebSphere Application Server version 6 et versions ultérieures.
Niveau de journalisation de la version 6 et des versions ultérieures Contenu / Signification
off La journalisation est désactivée.
fatal La tâche ne peut se poursuivre et le composant, l'application et le serveur ne fonctionnent pas.
severe La tâche ne peut se poursuivre mais le composant, l'application et le serveur fonctionnent toujours. Ce niveau peut également indiquer une erreur irrémédiable imminente.
warning Erreur potentielle ou imminente. Ce niveau peut également indiquer un incident progressif (par exemple, la perte éventuelle de ressources).
audit Evénement important qui affecte l'état du serveur ou les ressources
info Informations générales qui présentent la progression globale de la tâche
config Statut ou modification de la configuration
detail Informations générales qui détaillent la progression de la sous-tâche
fine informations de Trace - trace générale + valeurs d'entrée/de sortie et , de retour de la méthode
finer Informations de trace - trace détaillée
finest Informations de trace - Trace détaillée qui inclut les détails nécessaires au débogage des problèmes
all Tous les événements sont consignés. Si vous créez des niveaux personnalisés, le niveau all inclut ces niveaux, et peut fournir une trace plus détaillée que le niveau finest.
Le fichier console.log n'a pas le même niveau de gestion que les autres fichiers journaux. La seule propriété que vous pouvez modifier est consoleLogLevel. Si vous êtes préoccupé par l'augmentation de la taille du fichier console.log, vous pouvez désactiver le fichier console.log et utiliser le fichier journal des messages à la place. Les mêmes données, dans un format différent, sont écrites pour le fichier journal des messages, et vous pouvez contrôler la taille et le nombre de fichiers journaux des messages à l'aide des attributs maxFileSize et maxFiles. Par exemple, le fichier bootstrap.properties génère un fichier console.log vide et un maximum de trois fichiers loggingMessages.log de 1 Mo en rotation. Toutefois, les messages provenant de la machine virtuelle Java sous-jacente peuvent tout de même être écrits dans le fichier console.log. Les paramètres qui figurent dans le fichier bootstrap.properties sont appliqués lorsque le fichier journal des messages est créé : par conséquent, le fichier journal des messages est créé initialement en tant que loggingMessages.log et non en tant que fichier par défaut messages.log.
   com.ibm.ws.logging.max.file.size=1
   com.ibm.ws.logging.max.files=3
   com.ibm.ws.logging.console.log.level=OFF
   com.ibm.ws.logging.message.file.name=loggingMessages.log
Le fichier console.log est réinitialisé lors du redémarrage du serveur.
Remarque : Sur toutes les plateformes, les journaux sont écrits avec le codage par défaut du système.
  • Pour plateformes WindowsSur les systèmes Windows, il existe deux types de codage : la page de codes OEM, qui est utilisée pour la sortie dans la console, et la page de codes ANSI, qui est utilisée pour lire et écrire les fichiers. Le fichier console.log utilise la page de codes OEM et tous les autres journaux la page de codes ANSI.
  • Pour plateformes répartiesSur toutes les autres plateformes, tous les fichiers journaux utilisent le codage par défaut.

Icône indiquant le type de rubrique Rubrique de référence

Dispositions pour les centres de documentation | Commentaires


Icône d'horodatage Dernière mise à jour: Wednesday, 2 September 2015
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=phil&product=was-libcore-mp&topic=rwlp_logging
Nom du fichier : rwlp_logging.html