Utilisation de journaux de messages de base ou traditionnels pour résolution des problèmes liés aux applications

WebSphere Application Server peut écrire des messages système dans plusieurs journaux généraux, notamment les journaux de la machine virtuelle Java, des processus et des services IBM®, que vous pouvez examiner pour déterminer la nature des incidents.

Avant de commencer

Les journaux JVM sont créés par réacheminement des flux System.out et System.err de la machine virtuelle Java (JVM) vers des fichiers journaux indépendants. WebSphere Application Server écrit des messages formatés au flux System.out. De plus, les applications et d'autre code peuvent écrire ces flux à l'aide des méthodes print() et println() définies par les flux. Certains kits de développeur intégrés, tels que la méthode printStackTrace() sur la classe Throwable peuvent également écrire dans ces flux. En général, le journal System.out est utilisé pour surveiller la santé du serveur d'applications en cours d'exécution. Les journaux System.out et System.err peuvent être utilisés à des fins d'identification des problèmes. Le journal System.err contient des informations de trace de la pile d'exceptions très utiles lors de l'identification d'incident.

Chaque serveur d'applications représentant une JVM, il existe un jeu de journaux JVM pour chaque serveur d'applications et ses applications. Ces journaux se trouvent par défaut dans le répertoire suivant :
  • [AIX Solaris HP-UX Linux Windows][z/OS]racine_installation/profiles/nom_profil/logs/nom_serveur
  • [IBM i]racine_profil/logs/nom_serveur

Dans le cas d'une configuration WebSphere Application Server, Network Deployment, des journaux JVM sont également créés pour le gestionnaire de déploiement et pour chaque agent administratif, car ils représentent également des machines virtuelles Java.

[z/OS]Il existe des flux de consignation STDOUT et STDERR pour chaque serveur d'applications et toutes ses applications. Les journaux JVM sont aussi créés pour le gestionnaire de déploiement et pour chaque agent administratif, car ils représentent également des JVM.

Les journaux de processus sont créés par réacheminement des flux STDOUT et STDERR du processus vers des fichiers journaux indépendants. Le code natif, y compris la machine virtuelle Java™ (JVM) elle-même, écrit dans ces fichiers. En règle générale, WebSphere Application Server n'écrit pas dans ces fichiers. Ces fichiers peuvent toutefois contenir des informations relatives à des incidents au niveau du code natif ou des informations de diagnostic écrites par la JVM.

Comme avec les journaux JVM, une série de journaux de processus est créée pour chaque serveur d'applications, chaque JVM étant un processus de système d'exploitation. Dans le cas d'une configuration WebSphere Application Server, Network Deployment, un ensemble de journaux de processus est créé pour le gestionnaire de déploiement et chaque agent administratif.

Fonction obsolète Fonction obsolète: Le journal des services IBM contient à la fois les messages WebSphere Application Server qui sont écrits au flux System.out et certains messages spéciaux qui contiennent des informations de service étendues ne présentant habituellement pas d'intérêt, mais pouvant s'avérer importantes lors de l'analyse des incidents. Il y a un journal de service pour toutes les JVM WebSphere Application Server sur un noeud, y compris tous les serveurs d'applications. Le journal de service IBM est au format binaire et un outil spécial est nécessaire pour le visualiser. Cet outil, l'analyseur de journaux et de traces, fournit des fonctions de diagnostic supplémentaires. De plus, le format binaire offre d'autres possibilités exploitées par les services d'assistance IBM.depfeat

Outre ces journaux à usage général, WebSphere Application Server contient d'autres journaux spécialisés propres à une activité ou à un composant particulier. Par exemple, le plug-in du serveur HTTP gère un journal qui lui est propre. En général, ces journaux ne présentent pas d'intérêt, mais vous pouvez être invité à examiner un journal ou plusieurs d'entre eux lors de l'exécution de procédures d'identification d'incidents spécifiques. Pour savoir quand et comment visualiser le journal de plug-in, voir la sous-section Accéder à une ressource Web via le serveur d'applications et ignorer le serveur HTTP de la rubrique Une ressource Web ne s'affiche pas.

[AIX Solaris HP-UX Linux Windows]Remarque : Le journal système (SYSLOG) est uniquement pris en charge par WebSphere Application Server for z/OS. La journalisation de WebSphere Application Server n'utilise aucun journal du système d'exploitation sauf dans le cas de z/OS.
[z/OS]Remarque : Les flux System.out et STDOUT sont redirigés vers le nom symbolique SYSPRINT sous z/OS. Les flux System.err et STDERR sont redirigés vers le nom symbolique SYSOUT sous z/OS. Par défaut, les procédures cataloguées WebSphere Application Server for z/OS associent ces noms symboliques à des fichiers (SYSOUT=*) d'impression. Par conséquent, les journaux des messages passent dans la sortie de travaux WebSphere Application Server. La sortie de travaux peut être visualisée à l'aide de SDSF (Spool Display and Search Facility) ou d'un logiciel équivalent.

Pourquoi et quand exécuter cette tâche

L'examen de la sortie de journal de WebSphere Application Server permet parfois de diagnostiquer des incidents liés aux serveurs et aux applications.

Procédure

Déterminez le type de journaux que vous souhaiteriez mettre en oeuvre :

Exemple

Acheminement des sorties SYSPRINT et SYSOUT vers un fichier HFS.

Si vous connaissez bien les environnements UNIX ou Windows, vous n'êtes peut-être pas très enclin à utiliser les fonctions SDSF (ou IOF) pour afficher la sortie SYSPRINT et SYSOUT des servants. Si vous préférez utiliser un éditeur courant (tel que vi) dans une session Telnet pour visualiser la sortie, il est possible de rediriger les sorties SYSPRINT et SYSOUT vers les fichiers d'un système HFS.

Le code JCL ci-après montre comment modifier la carte DD SYSPRINT dans la procédure de démarrage pour rediriger la sortie vers un fichier HFS. L'ancienne carte DD SYSPRINT a été mise en commentaires et précédée de /*, et une nouvelle carte DD SYSPRINT pointe vers un fichier du répertoire "/monRép/monServeur", nommé dans l'exemple was.log.d&LYYMMDD..t&LHHMMSS.log. La période supplémentaire entre les variables de la date et de l'heure n'est pas une erreur de frappe, il s'agit d'une instance de la syntaxe JCL nécessaire pour terminer la première variable. &LYYMMDD est remplacé par la date locale au format AAMMJJ et &LHHMMSS est remplacé par l'heure locale au format HHMMSS. Le sous-paramètre PATHMODE définit le mode de fichier à 775 et le sous-paramètre PATHOPTS OWRONLY ouvre le fichier pour l'accès WRITE. Le sous-paramètre OCREAT indique que si le fichier n'existe pas, il est créé.

Vous pouvez modifier la carte DD SYSPRINT dans la procédure de démarrage Servant ou Controller. De plus, la carte DD SYSOUT peut être modifiée de la même manière pour rediriger la sortie SYSOUT.

//*YSPRINT  DD SYSOUT=*,SPIN=UNALLOC,FREE=CLOSE
//SYSPRINT  DD PATHMODE=(SIRWXU,SIRWXG,SIROTH),
//   PATHOPTS=(OWRONLY,OCREAT),
//   PATH='/monRép/monServeur/was.log.d&LYYMMDD..t&LHHMMSS'
Remarque : Si vous essayez de diriger la sortie de plusieurs flots vers le même fichier, par exemple si vous définissez à la fois les variables DEFALTDD et HRDCPYDD, l'attribution du fichier HRDCPYDD échoue et la sortie est envoyée à l'emplacement par défaut (JOBLOG/SYSLOG).

Icône indiquant le type de rubrique Rubrique de tâche



Icône d'horodatage Dernière mise à jour: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=ttrb_mglogs
Nom du fichier : ttrb_mglogs.html