Zum Inhalt springen

Apache/11 Logging/Core-Direktiven

Aus Foxwiki

Core-Direktiven

Neben den bereits erwähnten ErrorLog-Einstellungen enthält der Core noch die beiden indirekt mit dem Logging verbundenen Direktiven HostnameLookups und IdentityCheck (Letztere wird seit Version 2.1-beta in ein eigenes Modul ausgelagert)

Logging-Direktiven und -Module 11.1 

ErrorLog

Verzeichnis für die Fehler-Log-Datei 

Modul core
Kontext Server, <VirtualHost>
Syntax ErrorLog Dateiname|syslog[:Quelle]
Standardwert UNIX: logs/error_log; Windows: logs/error.log

Die Direktive ErrorLog legt den Namen der Datei fest, in der die verschiedenen Fehler protokolliert werden. Unter UNIX ist die Voreinstellung logs/error_log, unter Windows logs/error.log. Wie üblich ist der Pfad relativ zur ServerRoot

Statt einer Datei können Sie unter Betriebssystemen, die dies unterstützen, auch eine Pipe zu einem Programm angeben, das die Log-Meldungen unmittelbar weiterverarbeitet. Dies ist beispielsweise für das Apache-Hilfsprogramm rotatelogs interessant, das in regelmäßigen Abständen neue Log-Dateien anlegt. Das Verfahren wird weiter unten im Zusammenhang mit der Direktive CustomLog genauer erläutert. Hier nur ein Beispiel, das jeden Tag eine neue Log-Datei mit einem Namen wie access_log.2011-09-07 (Jahr-Monat-Tag) anlegt 

ErrorLog "|/usr/local/apache2/bin/rotatelogs \
/usr/local/apache2/logs/access_log.%Y-%m-%d 86400"

Unter UNIX besteht darüber hinaus die alternative Möglichkeit, die Fehlermeldungen an das syslog zu übergeben, anstatt sie in eine einfache Datei zu schreiben

  • Dazu wird statt eines Pfades die Syntax syslog oder syslog:Fehlerquelle verwendet
  • Die Fehlerquelle (facility) beschreibt die Art des Programms oder Prozesses, von dem die Meldung stammt

Die folgenden Quellen sind in syslog definiert

  • auth: Authentifizierung
  • authpriv: Authentifizierung privilegierter Benutzer
  • cron: cron-Daemon
  • daemon: sonstige Daemons
  • ftp: FTP-Server
  • kern: Kernel
  • local0 bis local7: zur freien Verwendung durch beliebige Programme
  • lpr: Drucker-Subsystem
  • mail: Mail-Subsystem
  • news: News-Subsystem
  • syslog: interne Meldungen von syslog selbst
  • uucp: UUCP-Subsystem
  • user: Anwendungsprogramme
Beispiel
ErrorLog syslog:daemon
ErrorLogFormat

Formatangabe für zusätzliche Informationen in den Einträgen im ErrorLog 

Seit Version 2.3.9
Modul core
Kontext Server, <VirtualHost>
Syntax ErrorLogFormt [connection|request] Format

Traditionell war das Format der Einträge im ErrorLog stets dasselbe. Erst in neueren 2.3-Beta-Versionen kann das Format modifiziert werden, ähnlich wie es bei Access- und anderen Log-Dateien schon seit langer Zeit der Fall ist. Genauer gesagt können Sie zusätzliche Informationen hinzufügen

Wenn Sie connection oder request vor dem eigentlichen Format angeben, werden die zusätzlichen Daten nur bei der ersten Log-Meldung einer Verbindung beziehungsweise Anfrage protokolliert, ansonsten gelten sie für jeden Log-Eintrag

Für die Formatangabe selbst ist eine Reihe verschiedener Platzhalter verfügbar, die in Tabelle 11.1 zusammengefasst werden. Sie ähneln den Platzhaltern für Access-Log-Dateien (siehe Kürzel für Log-Formate, Seite 524), sind aber nicht identisch

Kürzel Beschreibung 

%% Prozentzeichen
%a Remote-IP-Adresse und Port
%A lokale IP-Adresse und Port
%{Name}e Umgebungsvariable Name
%E Fehlerstatuscode und -String der Apache Portable Runtime bzw. des Betriebssystems
%F Quelldateiname und Zeilennummer des Protokollaufrufs
%{Name}i HTTP-Anfrage-Header Name

Tabelle 11.1 11.1 Formatplatzhalter für ErrorLogFormat

Logging-Direktiven und -Module 11.1

Kürzel Beschreibung 

%k Anzahl der Keepalive-Anfragen über die aktuelle Verbindung
%l LogLevel der Meldung (siehe LogLevel, Seite 520)
%L Log-ID der Anfrage
%{c}L Log-ID der Verbindung
%{C}L Log-ID, falls die Meldung zu einer Verbindung gehört, ansonsten leer
%m Name des Moduls, das die Log-Meldung ausgibt
%M die Log-Meldung selbst
%{Name}n Anfrage-Hinweis Name
%P Prozess-ID des aktuellen Prozesses
%T Thread-ID des aktuellen Threads
%{g}T systemweit eindeutige ID des aktuellen Threads (wie in der Ausgabe
von top); zurzeit nur Linux
%t aktuelle Zeit
%{u}t aktuelle Zeit einschließlich Mikrosekunden
%{cu}t aktuelle Zeit im ISO-8601-Format einschließlich Mikrosekunden
%v kanonischer Servername des aktuellen Servers
%V Servername desjenigen Servers, der die Anfrage bearbeitet, gemäß UseCanonicalName-Einstellung \ (Backslash- Leerzeichen, das keine Feldtrennung verursacht Leerzeichen)
% (Prozent-Leer- Feldtrennzeichen (wird nicht ausgegeben) zeichen) 
lle

=== 11.1 11.1 Formatplatzhalter für ErrorLogFormat (Forts.)

Die einzelnen Felder werden durch Leerzeichen voneinander getrennt. Wenn ein Feld keine Ausgabe erzeugt – z. B. %{Referer}i, in dem es keinen Referer gibt –, werden auch eventuelle zusätzliche Zeichen des Feldes nicht ausgegeben. Wenn Sie z. B. (%{Referer}i) schreiben, um den Referer in runde Klammern zu setzen, werden auch die runden Klammern nicht ausgegeben, wenn der Referer fehlt Wenn Sie innerhalb eines Feldes ein Leerzeichen ausgeben möchten, können Sie es durch einen Backslash escapen – Beispiel 

Referer:\ %{Referer}i

Möchten Sie umgekehrt zwei Felder ohne sichtbaren Abstand hintereinander ausgeben, können Sie ein Prozentzeichen, gefolgt von einem Leerzeichen, als Feldtrenner verwenden

Hinter dem Prozentzeichen der meisten Kürzel kann noch ein Modifier stehen

  • - (Minus): Wenn das Element keine Ausgabe erzeugt, wird stattdessen ein

Minuszeichen in die Ausgabe geschrieben. Beispiel: %-{Accept}i gibt, falls vorhanden, die vom Client akzeptierten MIME-Types aus oder -, falls der Header Accept in der Anfrage fehlt

  • + (Plus): Wenn Sie bei einem Feld den Modifier + verwenden, wird die gesamte Zeile nicht ausgegeben, falls das entsprechende Element keinen

Inhalt hat. Zeilen, in denen %+{Referer}i vorkommt, werden also beispielsweise nur protokolliert, wenn die entsprechende Anfrage einen Referer enthielt. Dies ist nur in Anfragen mit der Zusatzangabe request sinnvoll

  • Numerischer Wert (LogLevel): Das Element wird nur protokolliert, wenn die Dringlichkeitsstufe (LogLevel) mindestens dem angegebenen Wert entspricht

Mögliche Werte reichen von 1 (alert) über 4 (warn) und 7 (debug) bis hin zu 15 (trace8). Einzelheiten über LogLevels erfahren Sie in der Beschreibung der im Anschluss beschriebenen gleichnamigen Direktive. %4{Host}i loggt den Anfrage-Header Host nur dann, wenn die Dringlichkeit mindestens warn ist

Beispiel
ErrorLogFormat "[%{u}t] [%-m:%l] [pid %P:tid %T] %7F: %E: [client\%a] %M% ,\ referer\ %{Referer}i"

Dies entspricht dem Standardformat in Apache 2.3 und erzeugt eine Ausgabe wie diese, die auf einen fehlerhaften Link hindeutet 

[Thu Oct 13 15:26:31.145241 2011] [core:error] [pid 6921:tid
3241673914] [client ::1:41963] File does not exist: /usr/local/
apache2/htdocs/idex.html, referer https://www.mynet.de/about.html
LogLevel
Dringlichkeitsstufe, ab der Fehlermeldungen in das ErrorLog geschrieben werden

Modul core
Kontext Server, <VirtualHost>; seit 2.3.6 auch <Directory>
Syntax LogLevel Stufe seit 2.3.6: Loglevel [Modul:]Stufe [Modul:Stufe]
Standardwert warn

Diese Direktive bestimmt, ab welcher Dringlichkeitsstufe Meldungen in die ErrorLog-Datei geschrieben werden. Die Werte entsprechen den Stufen, die für syslog definiert sind (in Klammern sind die zugehörigen Werte für numerische ErrorLogFormat-Modifier angegeben)

Logging-Direktiven und -Module 11.1

  • emerg: Notfall; das System ist unbrauchbar
  • alert: Alarm – sofortiger Eingriff erforderlich (1)
  • crit: kritischer Fehler (2)
  • error: normaler Fehler (3)
  • warn: Warnung (4)
  • notice: Hinweis (5)
  • info: normale Information (6)
  • debug: Debugging-Information (7)
  • trace1 bis trace8: Zusatzinformationen bestimmter Module (8–15; seit Version 2.3.6)

Die Voreinstellung ist warn; zu dieser Stufe gehören Meldungen wie die folgende 

[Wed Aug 31 09:28:41 2011] [warn] Parent: child process 16526 did not exit, sending another SIGHUP

Warnungen sind also Ausnahmezustände, die sich in der Regel ohne Eingriff des Administrators beseitigen lassen. Deshalb genügt für einen Produktionsserver meistens die Einstellung error. Werte, die mehr Einträge erzeugen – vor allem debug –, sind aufgrund des zusätzlichen Ressourcenverbrauchs eigentlich nur zu Testzwecken empfehlenswert, etwa wenn Sie eine neue Apache-Version oder ein experimentelles Modul in Betrieb nehmen möchten

Ab Version 2.3.6-beta wurden die Fähigkeiten von LogLevel stark erweitert. Seit dieser Version ist es zum einen möglich, pro Verzeichnis ein anderes LogLevel zu wählen. Angenommen, Sie möchten im Allgemeinen das LogLevel warn beibehalten, in einem bestimmten Unterverzeichnis jedoch zur Untersuchung eines Fehlverhaltens auf debug umschalten. Dann funktioniert dies beispielsweise folgendermaßen 

# Serverkonfiguration
LogLevel warn
# Problematisches Verzeichnis
<Directory /usr/local/apache2/htdocs/scripts>
LogLevel debug
</Directory>

Außerdem wurde die Möglichkeit eingeführt, das LogLevel für einzelne Module zu verändern. Dazu wird die erweiterte Syntax Modul:Stufe verwendet, wobei mehrere durch Leerzeichen getrennte Angaben möglich sind. Das Modul kann auf drei Arten angegeben werden (hier jeweils am Beispiel von mod_rewrite)

  • der Modul-Identifier, der beispielsweise auch bei LoadModule verwendet wird – rewrite_module
  • der Module-Identifier ohne das Suffix _module – rewrite
  • der Name der Haupt-Quellcodedatei des Moduls – mod_rewrite.c

Dieses Verfahren ersetzt einige in älteren Apache-Versionen verfügbare Spezialdirektiven für das Logging der Ausgabe bestimmter Module, insbesondere die in Abschnitt 11.1.6, Logging-Direktiven in mod_rewrite, ab Seite 537 vorgestellten Rewrite-Log-Direktiven

Das folgende Beispiel setzt das LogLevel für mod_rewrite im aktuellen Konfigurationskontext auf den maximalen Wert trace8 

LogLevel rewrite:trace8
Warnung
Ein zu hoher Trace-Wert kann die Performance von Apache deutlich beeinträchtigen
Ein höherer Wert als trace2 sollte nur vorübergehend zu Debugging-Zwecken verwendet werden

Wenn Sie mit ein und derselben Direktive einen allgemeinen und einen oder mehrere modulspezifische LogLevel-Werte einstellen möchten, muss der allgemeine an erster Stelle stehen. Das folgende Beispiel stellt debug als allgemeinen Wert und trace2 für mod_rewrite ein 

LogLevel debug rewrite:trace2
HostnameLookups

DNS-Lookups von Hostnamen aktivieren 

Modul core
Kontext Server, <VirtualHost>, <Directory>, <Location>, <Files>
Syntax HostnameLookups On|Off|Double
Standardwert Off

Diese Direktive kann dafür sorgen, dass Apache durch einen Reverse-DNSLookup die Hostnamen der anfragenden Clients ermittelt. Diese können in LogDateien geschrieben und außerdem über die Umgebungsvariable REMOTE_HOST an CGI-Skripte oder Server Side Includes weitergereicht werden. Sie können drei mögliche Werte angeben

  • Off: Die Hostnamen werden nicht ermittelt; es werden nur IP-Adressen protokolliert. Dies ist die Standardeinstellung

Logging-Direktiven und -Module 11.1

  • On: Der Reverse-Lookup wird durchgeführt, Apache versucht also, die Hostnamen zu ermitteln
  • Double: Diese Einstellung sorgt für einen Double-Reverse-Lookup. Zunächst wird ein gewöhnlicher Reverse-Lookup durchgeführt. Mit dem Ergebnis wird wiederum ein Forward-Lookup ausgeführt. Die dabei gefundene IP-Adresse muss der ursprünglich nachgeschlagenen entsprechen. Im tcpwrappersSprachgebrauch wird das Verfahren auch als PARANOID bezeichnet. Es stellt nämlich durch die Gegenprobe sicher, dass die Information korrekt ist

Bei stark beanspruchten Servern sollten Sie besser Off beibehalten und die Hostnamen später mithilfe des weiter unten vorgestellten Tools logresolve ermitteln

IdentityCheck Protokollierung entfernter Benutzernamen gemäß RFC 1413

Modul mod_ident (bis Version 2.0.x im core) Kontext Server, <VirtualHost>, <Directory>, <Location>, <Files> Syntax IdentityCheck On|Off Standardwert Off

Wenn diese Direktive eingeschaltet wird, versucht Apache, einen auf dem ClientHost laufenden identd-Dienst zu befragen und von ihm Benutzerinformationen zu erhalten. Falls dies funktioniert, wird die gefundene Information bei der Verwendung der Standard-Log-Formate in die TransferLog-Datei aufgenommen

Normalerweise sollte diese Möglichkeit nicht verwendet werden. Zum einen leidet die Performance stark, und zum anderen brauchen eventuell ermittelte Daten überhaupt nicht der Wahrheit zu entsprechen. Darüber hinaus läuft auf den meisten Systemen ohnehin kein identd-Server

IdentityCheckTimeout Maximale Wartezeit für die identd-Abfrage

Seit Version 2.1-beta Modul mod_ident Kontext Server, <VirtualHost>, <Directory>, <Location>, <Files> Syntax IdentityCheckTimeout Sekunden Standardwert 30

Diese Direktive gibt an, wie lange Apache maximal auf die Antwort eines identdServers warten soll. Dies gilt natürlich nur dann, wenn IdentityCheck überhaupt

eingeschaltet ist. Der Vorgabewert von 30 Sekunden wird in RFC 1413 empfohlen; Sie brauchen ihn nur dann zu verlängern, wenn Sie es mit bekanntermaßen langsamen identd-Servern zu tun haben

Abgerufen von „https://wiki.foxtom.de/index.php?title=Apache/11_Logging/Core-Direktiven&oldid=136710“