Fichiers journaux des serveurs d'applications

Lors du démarrage et de l'arrêt d'un serveur d'applications, différents fichiers journaux sont générés. Après le démarrage ou l'arrêt d'un serveur d'applications, contrôlez ces fichiers journaux afin de vous assurer que le serveur d'applications et l'application exécutée sur le serveur ont démarré ou se sont arrêtés correctement.

Les fichiers journaux du serveur d'applications se trouve dans le répertoire suivant :

Dans le Transaction server Docker container, WC_profiledir/logs/server1
WCDE_installdir/wasprofile/logs/server1

Examinez les fichiers journaux suivants après avoir démarré ou arrêté un serveur d'applications :

stopServer.log: Ce fichier journal contient les messages générés à l'arrêt du serveur d'applications. Celui-ci a été correctement arrêté si le fichier journal contient le texte Server server_name stop completed, server_name étant le nom du serveur d'applications arrêté.
SystemErr.log: Ce fichier journal contient les exceptions et les traces de pile Java. Ces exceptions sont interceptées par des applications d'entreprise et leurs serveurs d'applications associés.
Un fichier SystemErr.log vide ne signifie pas nécessairement le bon fonctionnement d'une application, car tous les messages d'erreur générés par l'application ne sont pas considérés comme des messages d'erreur par le système d'exploitation. Vous devez également examiner le contenu du fichier SystemOut.log.
SystemOut.log: Ce fichier journal contient les messages générés lorsque les applications en cours d'exécution sur le serveur d'applications sont lancées ou arrêtées. Il ne contient pas de message d'erreur comme ceux qui figurent dans le fichier SystemErr.log). Cependant, ce fichier journal contient les messages d'erreur que le système d'exploitation ne considère pas comme tels.
Contrôlez ce fichier journal et le fichier SystemErr.log après le démarrage d'un serveur d'applications pour confirmer que les applications exécutées sur le serveur ont également été correctement lancées.
trace.log: Si la trace est activée sur le serveur, le fichier journal contient les messages de trace des composants pendant que le service est en cours d'exécution.; Remarque :
Lorsque vous collaborez avec IBM pour déboguer des incidents relatifs au traitement d'une requête, il est possible que, dans certains cas, des composants de traçage de bas niveau doivent être activés pour capturer des informations détaillées sur la façon dont la requête est traitée. Ces composants de traçage Application Server de bas niveau ne connaissent pas l'intention de la requête ni les données potentielles qu'elle contient. Par conséquent, une fois activés, il est possible que ces composants de traçage incluent des informations confidentielles, en texte en clair, dans le fichier de trace.
Il est conseillé de ne pas activer ces types de composants de traçage sur un système de production et d'essayer de simuler l'incident dans un environnement d'assurance qualité afin de capturer les informations appropriées. Cependant, si les composants de la fonction de trace doivent être activés sur un système de production, gérez les fichiers de trace avec précaution. Avant d'envoyer la trace, supprimez des données confidentielles qui peuvent être dans le fichier de trace avant de permettre à un tiers d'utiliser la trace pour diagnostic. Par ailleurs, une fois que la trace n'est plus nécessaire, supprimez les fichiers à l'aide d'un processus d'effacement des données d'un niveau de fiabilité supérieur. Lorsque le problème est trouvé et le composant de traçage n'est plus nécessaire, désactivez immédiatement les composants de traçage de bas niveau.