Basisnachrichtenprotokolle oder traditionelle Nachrichtenprotokolle für die Behebung von Anwendungsfehlern verwenden

WebSphere Application Server kann Systemnachrichten in verschiedene allgemein verwendbare Protokolle schreiben, z. B. JVM-, Prozess- und IBM® Serviceprotokolle, die zur Fehlerbestimmung herangezogen werden können.

Vorbereitende Schritte

Die JVM-Protokolle werden durch Umleitung der JVM-Datenströme System.out und System.err in unabhängige Protokolldateien erstellt. WebSphere Application Server schreibt formatierte Nachrichten in den Datenstrom System.out. Darüber hinaus können Anwendungen und anderer Code mit den Methoden print() und println(), die von den Datenströmen definiert werden, in diese Datenströme schreiben. Einige integrierte Komponenten des Developer Kit, wie z. B. die Methode printStackTrace() der Klasse Throwable, können auch in diese Datenströme schreiben. In der Regel wird das Protokoll System.out verwendet, um den Zustand des aktiven Anwendungsservers zu überwachen. Die Protokolle System.out und System.err können für die Problembestimmung verwendet werden. Das Protokoll System.err enthält Traceinformationen zum Ausnahme-Stack, die sich bei der Fehleranalyse als nützlich erweisen.

Weil jeder Anwendungsserver eine JVM darstellt, gibt es für jeden Anwendungsserver und alle dazu gehörenden Anwendungen eine Gruppe von JVM-Protokollen, die standardmäßig in dem folgenden Verzeichnis gespeichert werden:
  • [AIX Solaris HP-UX Linux Windows][z/OS]Installationsstammverzeichnis/profiles/Profilname/logs/Servername
  • [IBM i]Profilstammverzeichnis/logs/Servername

Bei einer Konfiguration von WebSphere Application Server Network Deployment werden auch für den Deployment Manager und für jeden Verwaltungsagenten JVM-Protokolle erstellt, da diese ebenfalls JVMs darstellen.

[z/OS]Es gibt für jeden Anwendungsserver und seine Anwendungen jeweils ein Set der Protokolldatenströme STDOUT und STDERR. Es werden auch JVM-Protokolle für den Deployment Manager und jeden Verwaltungsagenten erstellt, weil auch sie JVMs darstellen.

Die Prozessprotokolle werden durch Umleitung der Prozessdatenströme STDOUT und STDERR in unabhängige Protokolldateien geschrieben. Nativer Code, z. B. auch die JVM (Java™ Virtual Machine) selbst, schreibt in diese Dateien. Im Allgemeinen schreibt WebSphere Application Server nicht in diese Dateien. Allerdings können die Protokolle Informationen enthalten, die sich auf Probleme in nativem Code oder auf von der JVM geschriebene Diagnoseinformationen beziehen.

Wie bei JVM-Protokollen gibt es eine Reihe von Prozessprotokollen für jeden Anwendungsserver, da jede JVM ein Betriebssystemprozess ist. In einer Konfiguration von WebSphere Application Server Network Deployment wird eine Reihe von Protokollen für den Deployment Manager und jeden Verwaltungsagenten erstellt.

Veraltetes Feature Veraltetes Feature: Das IBM Serviceprotokoll enthält sowohl die Nachrichten von WebSphere Application Server, die in den Datenstrom System.out geschrieben werden, als auch einige spezielle Nachrichten, die erweiterte Serviceinformationen enthalten, die normalerweise nicht von Interesse sind, für die Fehleranalyse aber möglicherweise wichtig sind. Es gibt ein Serviceprotokoll für alle JVMs von WebSphere Application Server an einem Knoten, einschließlich aller Anwendungsserver. Das IBM Serviceprotokoll wird in binärem Format geführt und benötigt ein spezielles Tool für die Anzeige. Diese Anzeigefunktion, die Protokoll- und Traceanalyse, bietet zusätzliche Diagnosemöglichkeiten. Außerdem bietet das binäre Format spezielle Funktionen, die vom IBM Support genutzt werden können.depfeat

Zusätzlich zu diesen allgemein verwendbaren Protokollen enthält WebSphere Application Server andere spezielle Protokolle für bestimmte Komponenten und Aktivitäten. Das HTTP-Server-Plug-in beispielsweise verwaltet ein eigenes Protokoll. Normalerweise sind diese Protokolle uninteressant. Es ist jedoch möglich, dass Sie während einer speziellen Fehlerbestimmungsprozedur angewiesen werden, eines oder mehrere dieser Protokolle zu untersuchen. Der Abschnitt "Mit dem Anwendungsserver auf eine Webressource zugreifen und HTTP Server umgehen" des Artikels "Es wird keine Webressource angezeigt" enthält detaillierte Anweisungen dazu, wie und wann das Plug-in-Protokoll angezeigt werden sollte.

[AIX Solaris HP-UX Linux Windows]Anmerkung: Das Systemprotokoll (SYSLOG) wird nur in WebSphere Application Server for z/OS unterstützt. Die Protokollierungsfunktionen von WebSphere Application Server verwenden, mit Ausnahme von z/OS, keine Betriebssystemprotokolle.
[z/OS]Anmerkung: Die Datenströme System.out und STDOUT werden unter z/OS an den Datendefinitionsnamen SYSPRINT umgeleitet. Die Datenströme System.err und STDERR unter z/OS werden an den Datendefinitionsnamen SYSOUT umgeleitet. Standardmäßig ordnen die katalogisierten Prozeduren von WebSphere Application Server for z/OS diese so genannten Datendefinitionsnamen Ausgabedateien (SYSOUT=*) zu. Dies bewirkt, dass Nachrichtenprotokolle in die Jobausgabe von WebSphere Application Server geschrieben werden. Die Jobausgabe kann mit Spool Display and Search Facility (SDSF) oder einer entsprechenden Software angezeigt werden.

Informationen zu diesem Vorgang

Manchmal können Server- und Anwendungsfehler durch Untersuchung der Protokollausgabe von WebSphere Application Server diagnostiziert werden.

Vorgehensweise

Bestimmen Sie, welche Typen von Protokollen implementiert werden sollen:

Beispiel

SYSPRINT- und SYSOUT-Ausgabe an eine HFS-Datei umleiten

Wenn Sie mit UNIX- und Windows-Umgebungen vertraut sind, zögern Sie möglicherweise, die SDSF-Funktionen (oder IOF-Funktionen) zum Anzeigen der SYSPRINT- und SYSOUT-Ausgaben der Servants zu verwenden. Wenn Sie zum Anzeigen der Ausgabe lieber einen Ihnen vertrauten Editor (z. B. vi) in einer Telnet-Sitzung verwenden möchten, können Sie die SYSPRINT- und SYSOUT-Ausgaben in Dateien in einem HFS umleiten.

Das folgende JCL-Beispiel veranschaulicht, wie Sie die SYSPRINT-DD-Karte in Ihrer Startprozedur ändern können, damit die Ausgabe in eine HFS-Datei umgeleitet wird. Die alte SYSPRINT-DD-Karte wurde mit den Zeichen /* auf Kommentar gesetzt, und eine neue SYSPRINT-DD-Karte zeigt auf eine Datei im Verzeichnis "/myDir/myServer", das in diesem Fall was.log.d&LYYMMDD..t&LHHMMSS.log heißt. Der zusätzliche Punkt zwischen Datum und Uhrzeit ist kein Tippfehler, sondern eine Instanz der JCL-Syntax, die erforderlich ist, um die erste Variable zu beenden. &LJJMMTT wird durch das lokale Datum im Format JJMMTT und &LHHMMSS durch die gültige Ortszeit im Format HHMMSS ersetzt. Der Unterparameter PATHMODE setzt den Dateimodus auf 775, und der PATHOPTS-Unterparameter OWRONLY öffnet die Datei im Schreibzugriff. Der Unterparameter OCREAT zeigt an, dass die Datei erstellt wird, sofern sie nicht vorhanden ist.

Sie können die SYSPRINT-DD-Karte in der Startprozedur des Servant oder des Controllers ändern. Die SYSOUT-DD-Karte kann auf dieselbe Weise geändert werden, wenn Sie die SYSOUT-Ausgabe umleiten möchten.

//*YSPRINT  DD SYSOUT=*,SPIN=UNALLOC,FREE=CLOSE
//SYSPRINT  DD PATHMODE=(SIRWXU,SIRWXG,SIROTH),
//   PATHOPTS=(OWRONLY,OCREAT),
//   PATH='/myDir/myServer/was.log.d&LYYMMDD..t&LHHMMSS'
Anmerkung: Wenn Sie versuchen, die Ausgabe für mehrere Datenströme an dieselbe Datei zu leiten, indem Sie beispielsweise die Variablen DEFALTDD und HRDCPYDD setzen, schlägt die Zuordnung für die HRDCPYDD-Datei fehl, und die Ausgabe wird an die Standardposition (JOBLOG/SYSLOG) gesendet.

Symbol, das den Typ des Artikels anzeigt. Taskartikel



Symbol für Zeitmarke Letzte Aktualisierung: 25.05.2016
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=ttrb_mglogs
Dateiname:ttrb_mglogs.html