Title: Protokolldateien

Um einen Webserver effektiv verwalten zu können, ist die Aufzeichnung der Aktivitäten und Leistungsmerkmale des Servers sowie der aufgetretenen Probleme erforderlich. Der Apache-Server bietet hierfür umfangreiche und flexible Möglichkeiten. Im folgenden wird beschrieben, wie die Protokollierung konfiguriert wird und was die Aufzeichnungen enthalten.

Zur Sicherheit

Jeder, der in dem Verzeichnis Schreibrechte besitzt, in das der Apache die Protokolldateien schreibt, kann Zugriff auf die uid (in der Regel root) erhalten, unter der der Server gestartet wurde. Seien Sie sich deshalb über die Konsequenzen im Klaren, wenn sie jemandem Schreibrechte für das Verzeichnis gewähren, in welchem der Server die Protokolldateien speichert. Weitere Einzelheiten finden Sie unter den Sicherheitstipps.

Darüber hinaus können Protokolldateien direkt vom Client übergebene Informationen enthalten. Böswillige Clients können daher Steuerzeichen in Protokolldateien schreiben, so dass Vorsicht beim Umgang mit den Rohdaten geboten ist.

Fehlerprotokoll ErrorLog LogLevel

Das Fehlerprotokoll des Servers, dessen Name und Verzeichnis mit der ErrorLog-Direktive setzt werden, ist die wichtigste Protokolldatei. In diese Datei schreibt der Apache bei der Bearbeitung der Anfragen Fehlermeldungen und Diagnosen. An dieser Stelle muss als erstes gesucht werden, wenn beim Serverstart oder Betrieb Probleme auftreten, weil sich hier oft Details finden, die zeigen, wo der Fehler liegt und wie er behoben werden kann.

Das Fehlerprotokoll wird in der Regel in eine Datei geschrieben (unter Unix normalerweise in die Datei error_log und unter Windows und OS/2 in die Datei error.log). Unter Unix kann der Server die Fehler auch an syslog senden oder in eine Pipe schreiben.

Das Format des Fehlerprotokolls ist relativ formlos und deskriptiv. Bestimmte Elemente sind aber in fast allen Fehlerprotokolleinträgen zu finden. Eine typische Fehlermeldung sieht folgendermaßen aus:

[Wed Oct 11 14:32:52 2000] [error] [client 127.0.0.1] client denied by server configuration: /export/home/live/ap/htdocs/test

Am Beginn stehen Datum und Uhrzeit der Meldung. Das zweite Element nennt den Schweregrad des Fehlers. Über den Schweregrad wird mit der Direktive LogLevel gesteuert, welche Arten von Fehlern in das Fehlerprotokoll eingetragen werden. An dritter Stelle steht die IP-Adresse des Clients, der den Fehler ausgelöst hat. Anschließend folgt die Fehlermeldung. In diesem Beispiel besagt sie, dass dem Client infolge der Konfiguration der Zugriff verweigert wurde. Der Server nennt den Dateipfad des Dateisystems (nicht den Web-Pfad) für das angeforderte Dokument.

Das Fehlerprotokoll kann sehr viele unterschiedliche Meldungen enthalten, die aber in der Regel dem aufgeführten Beispiel ähneln. Das Protokoll enthält auch Fehlerausgaben von CGI-Skripten. Jede von einem CGI-Skript nach stderr geschriebene Nachricht wird direkt in das Fehlerprotokoll eingetragen.

Eine Anpassung des Fehlerprotokolls durch Hinzufügen oder Ausklammern von Nachrichten ist nicht möglich. Fehlerprotokolleinträge für bestimmte Anfragen werden aber auch in das Zugriffsprotokoll aufgenommen. Das oben angeführte Beispiel entspricht einem Zugriffsprotokolleintrag mit dem Statuskode 403. Da das Zugriffsprotokoll konfigurierbar ist, lassen sich in dieser Protokolldatei mehr Hinweise auf Fehlerursachen aufzeichnen.

In einer Testphase ist oft sinnvoll, das Fehlerprotokoll kontinuierlich zu überwachen. Unter Unix verwenden Sie hierfür folgenden Befehl:

tail -f error_log
Zugriffsprotokoll mod_log_config mod_setenvif CustomLog LogFormat SetEnvIf

Im Zugriffsprotokoll des Servers werden alle verarbeiteten Anfragen aufgezeichnet. Das Verzeichnis und der Inhalt des Zugriffsprotokolls werden mit der CustomLog-Direktive gesteuert. Mit der LogFormat-Direktive kann die Auswahl der Inhalte für die Protokolle vereinfacht werden. Im folgenden Abschnitt wird beschrieben, wie der Server für das Aufzeichnen der Informationen im Zugriffsprotokoll konfiguriert wird.

Das ist aber nur der erste Schritt für die Protokollverwaltung. Im nächsten Schritt müssen diese Informationen analysiert werden, um aussagekräftige Statistiken anlegen zu können. Die Protokollanalyse geht über den Rahmen dieser Erörterung hinaus und ist eigentlich auch nicht Aufgabe des Webservers. Weitere Informationen hierzu und zu Programmen, die Protokollanalysen durchführen, finden Sie unter folgenden Adressen: Open Directory oder Yahoo.

Ältere Apache-Versionen verwenden andere Module und Direktiven zur Steuerung der Zugriffsprotokollierung, wie zum Beispiel mod_log_referer, mod_log_agent und TransferLog-Direktive. Die CustomLog-Direktive fasst jetzt die Funktionalität dieser älteren Direktiven zusammen.

Das Format des Zugriffsprotokolls ist weitgehend konfigurierbar. Es wird mit einem Format-String ähnlich dem der C-Funktion printf(1) angegeben. In den nächsten Abschnitten folgen einige Beispiele, eine vollständige Liste der Parameter des Format-String finden Sie unter mod_log_config - Format-Strings.

Das allgemeine Protokollformat

Eine typische Konfiguration des Zugriffsprotokolls kann wie folgt aussehen:

LogFormat "%h %l %u %t \"%r\" %>s %b" common
CustomLog logs/access_log common

Hier wird die Kurzbezeichnung common für den Format-String angegeben. Er besteht aus %-Anweisungen für die jeweiligen Informationen. Auch Literale, die die direkt in die Ausgabe geschrieben werden, können angegeben werden. Den Anführungszeichen (") wird als Escape-Zeichen ein Backslash vorangestellt werden, damit sie nicht als Ende des Format-String interpretiert werden. Der Format-String kann auch Steuerzeichen wie \n für einen Zeilenvorschub und \t für einen Tabulatorsprung enthalten.

Mit der Direktive CustomLog wird eine neue Protokolldatei mit dem angegebenen Kurznamen eingerichtet. Der Dateiname für das Zugriffsprotokoll wird relativ zur ServerRoot interpretiert, wenn er nicht mit einem Schrägstrich beginnt.

Bei der oben angegebenen Konfiguration erfolgen die Protokolleinträge im sogenannten Common Log Format (CLF). Dieses Standardformat kann von vielen unterschiedlichen Webservern erzeugt und von vielen Analyseprogrammen gelesen werden. Ein CLF-Eintrag in eine Protokolldatei kann wie folgt aussehen:

127.0.0.1 - frank [10/Oct/2000:13:55:36 -0700] "GET /apache_pb.gif HTTP/1.0" 200 2326

Jedes Element dieses Eintrags wird im folgenden beschrieben.

127.0.0.1 (%h)
Dies ist die IP-Adresse des Client (Remote-Host), der die Anfrage an den Server gerichtet hat. Wurde HostnameLookups On gesetzt, versucht der Server den Hostnamen zu ermitteln und trägt ihn anstelle der IP-Adresse ein. Von einer solchen Konfiguration ist aber abzuraten, weil sie den Server stark verlangsamen kann. Besser ist es, eine Nachbearbeitung mit logresolve vorzunehmen, um die Hostnamen zu bestimmen. Die hier angegebene IP-Adresse entspricht nicht unbedingt der Adresse des Rechners, an dem der Benutzer sitzt. Liegt zwischen ihm und dem Server ein Proxy-Server, dann wird es sich vielmehr um die Adresse des Proxy-Servers handeln.
- (%l)
Der Bindestrich gibt an, dass die angeforderten Informationen nicht zur Verfügung stehen. In diesem Beispiel steht die RFC 1413-Identität des Client nicht zur Verfügung, die von identd auf dem Client-Rechner festgelegt wird. Diese Angabe ist äußerst unzuverlässig und sollte daher nur in gut überwachten internen Netzwerken benutzt werden. Der Apache verwendet diese Angabe nur, wenn die Direktive IdentityCheck auf On gesetzt ist.
frank (%u)
Die von der HTTP-Authentifizierung ermittelte Userid der Person, die das Dokument angefordert hat. Der gleiche Wert wird normalerweise CGI-Skripten mit der Umgebungsvariablen REMOTE_USER übergeben. Hat die Anfrage den Statuskode 401 (siehe unten), sollte diesem Wert nicht vertraut werden, weil der Benutzer noch nicht authentifiziert wurde. Ist das Dokument nicht mit einem Passwort geschützt, lautet dieser Eintrag wie im letzten Fall -.
[10/Oct/2000:13:55:36 -0700] (%t)
Der Zeitpunkt, zu dem der Server die Bearbeitung der Anfrage abgeschlossen hat. Das Format ist:

[day/month/year:hour:minute:second zone]
day = 2 Ziffern
month = 3 Buchstaben
year = 4 Ziffern
hour = 2 Ziffern
minute = 2 Ziffern
second = 2 Ziffern
zone = (`+' | `-') 4 Ziffern

Mit der Anweisung %{format}t im Format-String kann die Zeit auch in einem anderen Format angegeben werden, wobei format sich auf die C-Funktion strftime(3) bezieht.
"GET /apache_pb.gif HTTP/1.0" (\"%r\")
Die Anforderungszeile des Client wird in doppelte Anführungszeichen gesetzt. Sie enthält viele nützliche Informationen. Zum einen zeigt sie, dass der Client die GET-Methode benutzt hat. Zum zweiten zeigt sie, dass der Client die Ressource /apache_pb.gif angefordert hat und zum Dritten, dass der Client das Protokoll HTTP/1.0 benutzt hat. Einzelne Bestandteile der Anfragezeile können auch gesondert protokolliert werden. Mit dem Format-String %m %U%q %H werden beispielsweise Methode, Pfad, Abfragezeichenfolge und Protokoll protokolliert.
200 (%>s)
Dies ist der Statuskode, den der Server an den Client sendet. Diese Information ist sehr nützlich, weil sie zeigt, ob die Anfrage erfolgreich beantwortet (Kodes, die mit 2 beginnen) oder umgeleitet (Kodes mit 3) wurde, ob ein Fehler beim Client (Kodes mit 4) oder beim Server (Kodes mit 5) ausgelöst wurde. Eine vollständige Liste der Statuskodes finden Sie in der Adresse HTTP-Spezifikation (RFC2616 Abschnitt 10).
2326 (%b)
Der letzte Eintrag gibt die Größe des an den Client gesendeten Objekts ohne die Header an. Wurde dem Client nichts zugesendet, ist der Wert -. Soll in diesem Fall 0 eingetragen werden, dann benutzen Sie stattdessen %B.
Das kombinierte Protokollformat

Ein ebenfalls häufig verwendeter Format-String ist das sogenannte kombiniert Protokollformat. Es kann wie folgt verwendet werden.

LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-agent}i\"" combined
CustomLog log/access_log combined

Dieses Format unterscheidet sich nur durch zwei zusätzliche Felder vom Common Log-Format. Die beiden zusätzlichen Felder benutzen die %{header}i-Anweisung, wobei header ein beliebiger HTTP-Anfrage-Header sein kann. Das Zugriffsprotokoll sieht bei diesem Format so aus:

127.0.0.1 - frank [10/Oct/2000:13:55:36 -0700] "GET /apache_pb.gif HTTP/1.0" 200 2326 "http://www.example.com/start.html" "Mozilla/4.08 [en] (Win98; I ;Nav)"

Die zusätzlichen Felder sind:

"http://www.example.com/start.html" (\"%{Referer}i\")
Der HTTP-Anfrage-Header Referer. Er nennt die Site, auf die der Client verwiesen wurde. (Das sollte die Seite sein, die mit /apache_pb.gif verknüpft ist oder die es eingebunden ist).
"Mozilla/4.08 [en] (Win98; I ;Nav)" (\"%{User-agent}i\")
Der HTTP-Anfrage-Header User-agent . Das sind die Angaben, die der Client-Browser über sich selbst macht.
Mehrere Zugriffsprotokolle

Mit mehreren CustomLog -Direktiven in der Konfigurationsdatei können mehrere Zugriffsprotokolle eingerichtet werden. Mit der folgenden Direktiven werden beispielsweise drei Zugriffsprotokolle eingerichtet. Das erste enthält die grundlegenden CLF-Informationen, während das zweite und dritte Verweis- und Browserinformationen enthalten. Die beiden letzten CustomLog-Zeilen zeigen, wie die Wirkungen der ReferLog- und AgentLog -Direktiven hervorgerufen werden.

LogFormat "%h %l %u %t \"%r\" %>s %b" common
CustomLog logs/access_log common
CustomLog logs/referer_log "%{Referer}i -> %U"
CustomLog logs/agent_log "%{User-agent}i"

Das Beispiel zeigt auch, dass kein Kurzname mit der LogFormat-Direktive angegeben werden muss. Das Protokollformat kann vielmehr direkt in der CustomLog-Direktive angegeben werden.

Bedingte Protokollierung

Manchmal kann es sinnvoll sein, bestimmte Einträge aufgrund der Merkmale der Client-Anfrage in den Zugriffsprotokollen zu unterdrücken. Dafür eignen sich Umgebungsvariablen. Zuerst muss eine Umgebungsvariable gesetzt werden, die anzeigt, dass die Anfrage bestimmte Bedingungen erfüllt. Dies geschieht normalerweise mit der Anweisung SetEnvIf. Anschließend werden mit der env=-Klausel der CustomLog-Direktive je nach der Umgebungsvariablen Anfragen ein- oder ausgeschlossen. Einige Beispiele:

# Anfragen der Loop-Back-Schnittstelle kennzeichnen
SetEnvIf Remote_Addr "127\.0\.0\.1" dontlog
# Anfragen nach der Datei robots.txt kennzeichnen
SetEnvIf Request_URI "^/robots\.txt$" dontlog
# Den Rest protokollieren
CustomLog logs/access_log common env=!dontlog

Im nächsten Beispiel werden Anfragen von englisch Sprechenden und nicht englisch Sprechenden in unterschiedlichen Protokolldateien aufgezeichnet.

SetEnvIf Accept-Language "en" english
CustomLog logs/english_log common env=english
CustomLog logs/non_english_log common env=!english

Die bedingte Protokollierung ist sehr vielseitig und flexibel, sie ist aber nicht die einzige Möglichkeit, zu steuern, was in den Protokollen aufgezeichnet wird. Häufig sind diese nützlicher, wenn sie einen kompletten Ablauf der Serveraktivitäten wiedergeben. Dabei ist es meist einfacher, eine Nachbereitung der Protokolldateien vorzunehmen, bei der nicht zu berücksichtigende Anfragen entfernt werden.

Protokollwechsel

Selbst bei nur durchschnittlich ausgelasteten Server wächst der Umfang der Protokolldateien sehr schnell an. Das Zugriffsprotokoll nimmt in der Regel mit 10.000 Anfragen um 1 MByte zu. Dementsprechend müssen die Protokolldateien regelmäßig ausgewechselt oder gelöscht werden. Während der Ausführung des Servers ist das nicht möglich, weil der Apache weiter in die alte Datei schreibt, solange sie geöffnet ist. Der Server muss neu gestartet werden, nach dem die Protokolldateien verschoben oder gelöscht wurden, damit er neue Protokolldateien öffnen kann.

Mit einem sogenannten rücksichtsvollen Neustart kann der Server angewiesen werden, neue Protokolldateien zu öffnen, ohne dass dabei vorhandene oder schwebende Client-Verbindungen unterbrochen werden. Dabei muss der Server aber weiterhin in die alten Protokolldateien schreiben, solange er die noch anstehenden Anfragen bearbeitet. Nach dem Neustart muss deshalb einen Moment gewartet werden, bevor die alten Daten bearbeitet werden. Ein typisches Verfahren ist es, die Dateien zu wechseln und die alten zu komprimieren, um Platz zusparen:

mv access_log access_log.old
mv error_log error_log.old
apachectl graceful
sleep 600
gzip access_log.old error_log.old

Eine weitere Möglichkeit zum Wechsel von Protokolldateien sind die Pipes, die im nächsten Abschnitt behandelt werden.

Protokolle in Pipes schreiben

Der Apache kann Fehler- und Zugriffsprotokolle über Pipes an andere Prozesse weiterreichen. Auf diese Weise können die Möglichkeiten für die Protokollierung erweitert werden, ohne das dem Hauptserver Code hinzugefügt werden muss. Um Protokolle in eine Pipe zu schreiben, wird einfach nach dem Dateinamen ein Pipe-Zeichen (|) gesetzt und danach das Programm angegeben, das die Protokolleinträge über die Standardeingabe entgegennehmen soll. Der Apache beginnt den Vorgang mit dem Serverstart und nimmt ihn wieder auf, wenn der Server abgestürzt war, weshalb dieses Verfahren auch als zuverlässig bewertet wird.

Die Pipe-Prozesse für die Protokollierung werden vom übergeordneten httpd-Prozess gestartet. Sie erben die Userid dieses Prozesses, was bedeutet, dass Programme für die Protokollierung normalerweise unter dem Benutzer root ausgeführt werden. Deshalb ist es wichtig, diese Programme einfach und sicher zu gestalten.

Bei Verwendung von Pipes ist ein Wechsel der Protokolldateien ohne einen Neustart des Servers möglich. Hierfür wird das Apache-Programm rotatelogs benutzt. Mit der folgenden Anweisung können die Protokolldateien beispielsweise alle 24 Stunden gewechselt werden:

CustomLog "|/usr/local/apache/bin/rotatelogs /var/log/access_log 86400" common

Der gesamte Befehl für die Pipe wird in Anführungszeichen gesetzt. Diese Beispiele für das Zugriffsprotokoll sind auch auf das Fehlerprotokoll übertragbar.

Von dritter Seite wird noch das Programm cronolog für den Wechsel der Protokolldateien angeboten.

Ähnlich wie die bedingte Protokollierung sind die in Pipes umgelenkten Protokolle eine leistungsfähige Lösung, die nur verwendet werden sollte, wenn eine einfachere Lösung wie die offline Nachbereitung nicht möglich sind.

Virtuelle Hosts

Bei Ausführung eines Servers mit vielen virtuellen Hosts gibt es zahlreiche Möglichkeiten für den Umgang mit Protokolldateien. Zum einen kann die Protokollierung genauso wie bei einem einzelnen Host erfolgen. Werden die Protokolldirektiven außerhalb der VirtualHost-Abschnitte im Kontext des Hauptservers gesetzt, können alle Anfragen im gleichen Zugriffs- und Fehlerprotokoll aufgezeichnet werden. Allerdings ist es so schwieriger, Statistiken für die einzelnen virtuellen Hosts zusammenzustellen.

Werden die Direktiven CustomLog oder ErrorLog in einem VirtualHost-Abschnitt gesetzt, werden alle Anfragen oder Fehler dieses virtuellen Host in der angegebenen Datei aufgezeichnet. Bei virtuellen Hosts ohne entsprechende Direktiven erfolgt die Aufzeichnung weiterhin im Protokoll des Hauptservers. Dieses Verfahren eignet sich bei einer kleinen Anzahl virtueller Hosts, mit zunehmender Hostanzahl wird jedoch die Verwaltung schwieriger. Ferner können häufiger Probleme durch fehlende Dateideskriptoren entstehen.

Für das Zugriffsprotokoll gibt es einen geeigneten Kompromiss. Werden dem Format-String die entsprechenden Informationen über den virtuellen Host hinzugefügt, können alle Hosts in der gleichen Datei protokolliert und diese später in einzelne Dateien zerlegt werden. Ein Beispiel:

LogFormat "%v %l %u %t \"%r\" %>s %b" comonvhost
CustomLog logs/access_log comonvhost

Mit der %v-Anweisung wird der Name des virtuellen Host, der die Anfrage bedient, ebenfalls protokolliert. Mit einem Programm wie split-logfile kann das Zugriffsprotokoll dann nachbereitet werden, um es in eine Datei pro virtuellem Hosts zu zerlegen.

Andere Protokolldateien mod_cgi mod_rewrite PidFile RewriteLog RewriteLogLevel ScriptLog ScriptLogBuffer ScriptLogLength
PidFile

Beim Start speichert der Apache die Prozess-ID des übergeordneten httpd-Prozesses in der Datei logs/httpd.pid. Dieser Dateiname kann mit der PidFile-Direktive geändert werden. Die Prozess-ID ist für den Administrator zum Neustarten und Beenden des Daemon durch senden von Signalen an den übergeordneten Prozess gedacht. Unter Windows wird stattdessen die Befehlszeilenoption -k benutzt. Weitere Informationen finden Sie unter Stoppen und Neustarten.

ScriptLog

Um das Debugging zu erleichtern, kann mit der ScriptLog-Direktive die Eingabe für und die Ausgabe von CGI-Skripten aufgezeichnet werden. Das sollte allerdings nur für Testzwecke benutzt werden und nicht für Server im realen Einsatz. Weitere Informationen hierzu finden Sie in der mod_cgi-Dokumentation.

RewriteLog

Bei Nutzung der leistungsfähigen und umfangreichen Eigenschaften von mod_rewrite ist es fast immer erforderlich, mit Hilfe des RewriteLog-Protokolls das Debugging zu erleichtern. Diese Protokolldatei liefert eine detaillierte Analyse der Umwandlung von Anfragen durch die Rewriting Engine. Der Grad der Detaillierung wird mit der RewriteLogLevel-Direktive gesteuert.

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to