icm/HTTP/logging_<xx>

Wertebereich und Syntax

Dieser Parameter hat folgende Syntax:

icm/HTTP/logging_<xx> =  PREFIX=<URL prefix>, LOGFILE=<log file name> 
[, LOGFORMAT=<format>, FILTER=<filter>, MAXSIZEKB=<size in KBytes>, 
SWITCHTF=<options>, FILEWRAP=on]
            

Hierbei haben die einzelnen Angaben folgende Bedeutung.

PREFIX

URL-Präfix, für den dieser HTTP-Subhandler aufgerufen werden soll (z.B. / ).

Weitere Informationen: Bearbeitung von HTTP-Requests

LOGFILE

Name der Ausgabedatei im Dateisystem.

Bei jedem Neustart prüft der ICM, ob die als Log-Datei spezifizierte Datei existiert. Wenn ja, schreibt er in der Datei weiter, wenn nein, legt er sie neu an.

Sie können an den eigentlichen Dateinamen noch einen Zeitstempel anhängen. Hierfür stehen folgende Optionen bei der Angabe der Log-Datei zur Verfügung:

LOGFORMAT

Es gibt folgende vordefinierte Formate für Log-Dateien:

• CLF

  Common Logfile Format mit der Form:

  10.18.104.36 - - [15/Oct/2007:16:18:35 +0100] "GET /dummy?para=100&user=sap HTTP/1.0" 200 86

  Das CLF-Format wird durch den folgenden String erzeugt: %h %l %u %t "%r" %s %b

• CLFMOD

  Modifiziertes Common Logfile Format: Es werden die Formfelder und URI-Parameter nicht mit in die Trace-Datei geschrieben (aus Sicherheitsgründen sollten diese Werte nicht in der Log-Datei gespeichert werden). Beispiel von oben:

  10.18.104.36 - - [15/Oct/2007:16:18:35 +0100] "GET /dummy HTTP/1.0" 200 86

  Das CLFMOD-Format wird durch den folgenden String erzeugt: %h %l %u %t "%r2" %s %b

• SAP

  SAP Logfile Format, bei dem zusätzlich noch die Bearbeitungsdauer im Applikationsserver in Millisekunden mit ausgegeben wird:

  [15/Oct/2007:15:41:35 +0100] 10.18.104.36 - - "GET /dummy HTTP/1.0" 200 86 10

  Das SAP-Format wird durch den folgenden String erzeugt: %t %h %u - "%r2" %s %b %L .

• SAPSMD

  Logformat für das Tracking von HTTP Requests anhand des HTTP Headerfeldes X-CorrelationID :

  [15/Oct/2007:15:41:35 +0100] - "GET /dummy HTTP/1.0" 200 86 [10] h[A7594F39ED9F7C41BABA7397F8070718-1-5] |

  Das SAPSMD-Format wird durch den folgenden String erzeugt: %t - "%r0" %s %b [%L] h[%{X-CorrelationID}i]

• SAPSMD2

  Logformat für das Tracking von HTTP Requests anhand des HTTP Headerfeldes X-CorrelationID :

  Dieses Logformat beinhaltet die Ausgabe des vollständigen Request- und Responseheaders.

  Das SAPSMD2-Format wird durch den folgenden String erzeugt: %t - "%r0" {%{[?]}i} %s %b [%L] {%{[?]}o}

• Selbstdefinierte Formate

  Soll ein anderes Format geschrieben werden, können Sie dies durch den Formatstring konfigurieren.

  Hierbei können Sie folgende Platzhalter verwenden.

  %b	Länge der Response in Bytes
  %r0 oder %r	1. Zeile eines HTTP-Requests mit Originalpfad und Formfeldern: z.B. GET /sap(bD1kZSZjPTAwMA==)/bc/ping?lang=de HTTP/1.0
  %r1	1. Zeile eines HTTP-Requests mit Originalpfad ohne Formfelder: z.B. GET /sap(bD1kZSZjPTAwMA==)/bc/ping HTTP/1.0
  %r2	1. Zeile eines HTTP-Requests mit URL-dekodiertem Pfad ohne Formfelder: z.B. GET /sap/bc/ping HTTP/1.0
  %f	Name des angefragten Objektes ohne Formfelder
  %U	gesamte URI eines Requests (mit Formfeldern)
  %s	OK-Code der Response
  %p0	gesamte Original-URI eines Requests (mit Formfeldern), äquivalent zu %U
  %p1	gesamte Original-URI eines Requests (ohne Formfelder)
  %p2	URL-dekodierter Pfad ohne Formfelder, äquivalent zu %f
  %p3	URL-dekodierter Pfad mit Formfeldern
  %{name}i	Name eines Request-Headerfeldes z.B. %{user-agent}i
  %{[?]}i	Ausgabe aller Request-Headerfelder im Format [name1 : wert1][name2 : wert2] ...
  %{?;}i	Ausgabe aller Request-Headerfelder im Format name1 : wert1;name2 : wert2; … ;name_n : wert_n Die Separatoren zwischen den einzelnen Headerfeldern sind frei wählbar.
  %{name}o	Name eines Response-Headerfeldes, z.B. %{server}o
  %{[?]}o	Ausgabe aller Response-Headerfelder im Format [name1 : wert1][name2 : wert2] ...
  %{?;}o	Ausgabe aller Response-Headerfelder im Format name1 : wert1;name2 : wert2; … ;name_n : wert_n Die Separatoren zwischen den einzelnen Headerfeldern sind frei wählbar.
  %{cookie}c	Ausgabe eines Requests-Cookies
  %{cookie}C	Ausgabe eines Response-Cookies
  %{formfield}F	Name eines Request-Formfeldes z.B. %{sap-client}F
  %{semfield}E	Name eines Semikolonfeldes
  %T	Dauer einer Anfrage in Sekunden
  %L	Dauer einer Anfrage in Millisekunden
  %j	Protokoll: HTTP oder HTTPS

  %h	Name des entfernten Rechners (des Clients, z. B. Browser)
  %h0	wie %h
  %h1	Wenn das Headerfeld x-forwarded-for gesetzt ist, der Wert des Headerfeldes, sonst der Name des direkten Rechners vor dem ICM (bzw. Web Dispatchers), also des Clients, z. B. Browser.
  %H	Name des lokalen Rechners
  %V	Vollqualifizierter Rechnername (FQHN) des Servers (Wert des Parameters icm/host_name_full bzw. FQHN vom Betriebssystem).
  %v	Name des virtuellen Rechners (IP-Adresse oder Name des Servers, mit dem sich der Client verbunden hat)
  %a	IP-Adresse des entfernten Rechners
  %S	lokaler Portname/Service

  %l	Angabe des "Remote Logname" . Dieser Name ist das Ergebnis einer IDENT-Anfrage an den Client. Dies funktioniert nur, wenn dort der IdentityCheck aktiviert ist.
  %u	Benutzername einer 401-Authentication Achtung Wenn Single Sign-On aktiv ist, sehen Sie hier nur ein - .
  %t	Zeitangabe im CLF-Format: [15/Dec/2007:16:18:35 +0100]
  %q	HTTP-Request-Id in folgender Notation: <conn slot> / <conn uid> / <rq id> Dabei gilt: <conn slot> / <conn uid> beschreibt die ICM Verbindung. <rq id> ist die fortlaufende Nummer des HTTP Requests auf der Verbindung. Die HTTP Request Id ist während des Lebensdauer des ICM-Prozess eindeutig.
  %M1	Aufzeichnung von HTTP Requests in Mikrosekunden, in der Form t0(pfclock):…;dt1(us):…;dt2(us):…;dt3(us):…;dt4(us):-;total(us): … Die Zeitpunkte der Aufzeichnung sind: 0: Beginn der HTTP Requestverarbeitung 1: Schicken des Requests zum Server 2: Ende der HTTP Requestverarbeitung 3: Beginn der HTTP Responseverarbeitung 4: Ende der HTTP Responseverarbeitung Da dieser Zeitpunkt nach dem Schreiben des HTTP Log Eintrags liegt, wird er im HTTP Log nicht protokolliert. Der absolute Wert des Zeitpunkts 0 entspricht dem Wert, den der ABAP Befehl GET RUN TIME liefert. Die übrigen Werte werden als Delta protokolliert.
  %M2	Aufzeichnung von HTTP Requests in Mikrosekunden, in der Form t0(timeofday):…;dt1(us):…;dt2(us):…;dt3(us):…;dt4(us):-;total(us): Analog zu Platzhalter %M1 Allerdings entspricht der absolute Wert des Zeitpunkts 0 dem Wert, den die Betriebssystemfunktion gettimeofday liefert.
  %m1	wie %M1, allerdings mit Millisekundenauflösung
  %m2	wie %M2, allerdings mit Millisekundenauflösung
  %B1	Backendtyp; mögliche Werte: ABAP , JAVA , NET . ABAP : Logging ist im ICM aktiv und der Request wird an den AS ABAP geleitet JAVA : Logging ist im ICM aktiv und der Request wird an den AS Java geleitet NET : Logging ist im Web Dispatcher aktiv. Der Request geht über das Netzwerk an einen ICM des SAP-Systems.
  %B2	Backendinfo wird ausgegeben; bei ABAP die WP-Nummer, bei JAVA die Cluster-ID Beispiel Mit dem Format: %h %l %u %t "%r" %s %b %B1:%B2 werden dann die folgenden Einträge geschrieben: 127.0.0.1 - - [08/Mar/2007:21:19:25 +0100] "GET /sap/public/icf_info/icr_urlprefix HTTP/1.0" 200 11376 ABAP:1 10.18.203.72 - - [08/Mar/2007:21:20:03 +0100] "GET /images/title.gif HTTP/1.1" 304 - JAVA:606993150 Im ersten Fall ging der Request vom ICM an den AS ABAP und wurde dort von Workprozess 1 bearbeitet. Im zweiten Fall ging der Request vom ICM an den AS Java und wurde von dem Server-Prozess mit der Cluster-ID 606993150 bearbeitet.

  Beispiel

  Sie können das von anderen Webservern bekannte "NCSA Combined Log Format" nachbilden, indem Sie den folgenden Formatstring verwenden:

  LOGFORMAT=%h %l %u %t "%r" %s %b "%{referer}i" "%{user-agent}i"

  Hinweis

  Die Nutzung von vordefinierten Logfile-Formaten ist deutlich performanter als die Nutzung von eigen definierten Formatstrings, da hier jedes Element des Formatstrings einzeln bestimmt und ausgegeben werden muss.

FILTER

Filter bewirken, dass ein HTTP-Request nur dann protokolliert wird, wenn ein bestimmtes Feld (z.B. ein HTTP-Headerfeld), im Request oder in der Response vorhanden ist. Bei Angabe von mehreren Feldern in einem Filter werden die Felder mit "oder" verknüpft.

Die Angabe eines Wertes ist optional. Wenn kein Wert angegeben ist, wird die Existenz des Feldes geprüft.

Durch Voranstellen von \ im Namen oder Wert des Feldes können die Zeichen '=', '}' und '\' escapet werden. Das Attribut Filter hat die folgende Syntax:

FILTER= {name}typ[={wert}] [ ; {name}type[={wert}] ] ...
            

Ein Filter kann folgende Felder enthalten:

• {name}i[={wert}] Filter auf ein Request-Headerfeld, z.B. {X-Correlation-Id}i

• {name}o[={wert}] Filter auf ein Response-Headerfeld

• {name}c[={wert}] Filter auf ein Request-Cookie

• {name}F[i][={wert}] Filter auf ein Request-Formfeld, z.B. {color}F={green} oder {color}Fi={green}

• {name}E[i][={wert}] Filter auf ein Request-Semikolonfeld

Bei Headerfeldern und Cookiefeldern ist Groß- und Kleinschreibung des Namens nicht signifikant. Bei Formfeldern und Semikolonfeldern ist Groß- und Kleinschreibung des Namens signifikant, außer wenn im Filter hinter dem Typ noch ein i angegeben wird. Dieses legt fest, dass Groß- und Kleinschreibung des Feldnamens für diesen Filter nicht signifikant ist.

Es gibt folgenden vordefinierten Filter:

SAPSMD : mit der Form {X-CorrelationId}i

Wenn dieser vordefinierte Filter gesetzt ist, werden nur Requests protokolliert, die das Headerfeld X-CorrelationId enthalten. Der Filter ist unabhängig vom gewählten Logfile-Format (s.o.)

MAXSIZEKB

MAXSIZEKB ist die maximale Größe der Logdatei in Kilobyte.

Wird diese Größe überschritten, wird die aktuelle Datei geschlossen und eine neue (mit anderem Namen) geöffnet.

Der neue Dateiname ist (durch die Angabe von Zeit/Datumsfeldern, s.o.) eindeutig oder er wird durch Anhängen von _xx eindeutig gemacht (wobei xx eine von 0 aufsteigende Zahlenfolge ist)

SWITCHTF

Eine neue Logdatei kann nicht nur erzeugt werden, wenn eine bestimmte Größe erreicht ist, sondern auch bei zeitlichen Änderungen:

FILEWRAP

Wird FILEWRAP=on gewählt, so wird immer, wenn eine neue Datei angefangen würde (aufgrund Überschreitung der Zeit- oder Größengrenze), die bestehende Logdatei zurückgesetzt und neu geschrieben. Es gibt also immer nur eine Logdatei mit den aktuellen Logging-Daten.

Wenn Sie die Option weglassen, wird nach Überschreitung der Größe eine neue Datei geschrieben (s.o.).