Zum Inhalt springen

Apache/HTTP/Logging/tmp

Aus Foxwiki

Protokolldateien

Um einen Webserver effektiv verwalten zu können, ist es notwendig, Feedback über die Aktivität und Leistung des Servers sowie über eventuell auftretende Probleme zu erhalten

  • Der Apache HTTP Server bietet sehr umfassende und flexible Protokollierungsfunktionen
  • In diesem Dokument wird beschrieben, wie Sie die Protokollierungsfunktionen konfigurieren und die Inhalte der Protokolle verstehen können

Überblick

Verwandte Module

Der Apache HTTP-Server bietet eine Vielzahl verschiedener Mechanismen zur Protokollierung aller Vorgänge auf Ihrem Server, von der ersten Anfrage über den URL-Zuordnungsprozess bis hin zur endgültigen Auflösung der Verbindung, einschließlich aller Fehler, die während des Prozesses aufgetreten sind

  • Darüber hinaus können Module von Drittanbietern Protokollierungsfunktionen bereitstellen oder Einträge in die vorhandenen Protokolldateien einfügen, und Anwendungen wie CGI-Programme, PHP-Skripte oder andere Handler können Nachrichten an das Fehlerprotokoll des Servers senden

In diesem Dokument werden die Protokollmodule behandelt, die standardmäßig zum HTTP-Server gehören

Sicherheitswarnung

Jeder, der in das Verzeichnis schreiben kann, in das Apache httpd eine Protokolldatei schreibt, kann mit ziemlicher Sicherheit auf die Benutzerkennung zugreifen, unter der der Server gestartet wurde, normalerweise root. Gewähren Sie Personen KEINEN Schreibzugriff auf das Verzeichnis, in dem die Protokolle gespeichert sind, ohne sich der Konsequenzen bewusst zu sein

Außerdem können Protokolldateien Informationen enthalten, die direkt vom Client ohne Escape-Sequenz bereitgestellt werden

  • Daher ist es für böswillige Clients möglich, Steuerzeichen in die Protokolldateien einzufügen
  • Daher ist beim Umgang mit Rohprotokollen Vorsicht geboten

Fehlerprotokoll

Verwandte Module

Verwandte Anweisungen

Das Server-Fehlerprotokoll, dessen Name und Speicherort durch die ErrorLog-Direktive festgelegt wird, ist die wichtigste Protokolldatei

  • An diese Stelle sendet Apache httpd Diagnoseinformationen und zeichnet alle Fehler auf, die bei der Verarbeitung von Anfragen auftreten
  • Es ist die erste Anlaufstelle, wenn beim Starten des Servers oder beim Betrieb des Servers ein Problem auftritt, da es oft Einzelheiten darüber enthält, was schiefgelaufen ist und wie es behoben werden kann

Das Fehlerprotokoll wird normalerweise in eine Datei geschrieben (normalerweise error_log auf Unix-Systemen und error.log auf Windows und OS/2)

Das Format des Fehlerprotokolls wird durch die ErrorLogFormat-Direktive definiert, mit der Sie anpassen können, welche Werte protokolliert werden

  • Wenn Sie keine angeben, wird ein Standardformat definiert

Eine typische Protokollmeldung lautet wie folgt: 

[Fri Sep 09 10:42:29.902022 2011] [core:error] [pid 35708:tid 4328636416] [client 72.15.99.187] File does not exist: /usr/local/apache2/htdocs/favicon.ico

Der erste Eintrag im Logeintrag ist das Datum und die Uhrzeit der Meldung

  • Der nächste Eintrag ist das Modul, das die Meldung erzeugt hat (in diesem Fall "core"), und der Schweregrad dieser Meldung
  • Darauf folgt die Prozess-ID und gegebenenfalls die Thread-ID des Prozesses, bei dem der Zustand aufgetreten ist
  • Als Nächstes folgt die Client-Adresse, die die Anfrage gestellt hat
  • Und schließlich folgt die detaillierte Fehlermeldung, die in diesem Fall auf eine Anfrage nach einer Datei hinweist, die nicht vorhanden war

Im Fehlerprotokoll können die unterschiedlichsten Meldungen erscheinen

  • Die meisten sehen ähnlich aus wie das Beispiel oben
  • Das Fehlerprotokoll enthält auch Debugging-Ausgaben von CGI-Skripten
  • Alle Informationen, die von einem CGI-Skript in stderr geschrieben werden, werden direkt in das Fehlerprotokoll kopiert

Wenn Sie ein %L-Token sowohl in das Fehlerprotokoll als auch in das Zugriffsprotokoll einfügen, wird eine Protokolleintrags-ID erstellt, mit der Sie den Eintrag im Fehlerprotokoll mit dem Eintrag im Zugriffsprotokoll korrelieren können

  • Wenn mod_unique_id geladen ist, wird auch dessen eindeutige Anforderungs-ID als Logeintrags-ID verwendet

Beim Testen ist es oft nützlich, das Fehlerprotokoll kontinuierlich auf Probleme zu überwachen

Auf Unix-Systemen können Sie dies mit folgendem Befehl erreichen: 

 tail -f error_log

Protokollierung pro Modul

Die LogLevel-Anweisung ermöglicht es Ihnen, einen Protokollschweregrad auf Modulbasis festzulegen

  • Auf diese Weise können Sie bei der Fehlerbehebung eines Problems mit nur einem bestimmten Modul dessen Protokollierungsvolumen erhöhen, ohne auch die Details anderer Module zu erhalten, die Sie nicht interessieren
  • Dies ist besonders nützlich für Module wie mod_proxy oder mod_rewrite, bei denen Sie Details darüber wissen möchten, was sie zu tun versuchen

Geben Sie dazu den Namen des Moduls in Ihrer LogLevel-Anweisung an: 

 LogLevel info rewrite:trace5

Dies setzt den Haupt-LogLevel auf info, erhöht ihn jedoch auf trace5 für mod_rewrite

Dies ersetzt die modulbezogenen Logging-Anweisungen wie RewriteLog, die in früheren Versionen des Servers vorhanden waren

Access Log

Verwandte Module Verwandte Anweisungen
mod_log_config
mod_setenvif 		CustomLog
LogFormat
SetEnvIf

Das Server-Zugriffsprotokoll zeichnet alle vom Server verarbeiteten Anfragen auf

  • Der Speicherort und der Inhalt des Zugriffsprotokolls werden durch die CustomLog-Anweisung gesteuert
  • Die LogFormat-Anweisung kann verwendet werden, um die Auswahl der Protokollinhalte zu vereinfachen
  • In diesem Abschnitt wird beschrieben, wie der Server für die Aufzeichnung von Informationen im Zugriffsprotokoll konfiguriert wird

Die Speicherung der Informationen im Zugriffsprotokoll ist nur der erste Schritt der Protokollverwaltung

  • Der nächste Schritt besteht darin, diese Informationen zu analysieren, um nützliche Statistiken zu erstellen
  • Die Protokollanalyse im Allgemeinen geht über den Rahmen dieses Dokuments hinaus und ist nicht wirklich Teil der Aufgabe des Webservers selbst

Verschiedene Versionen von Apache httpd haben andere Module und Anweisungen zur Steuerung der Zugriffsprotokollierung verwendet, darunter mod_log_referer, mod_log_agent und die TransferLog-Anweisung

  • Die CustomLog-Direktive umfasst nun die Funktionalität aller älteren Direktiven

Das Format des Zugriffsprotokolls ist in hohem Maße konfigurierbar

  • Das Format wird mithilfe einer Formatzeichenfolge angegeben, die einer C-artigen printf(1)-Formatzeichenfolge ähnelt
  • In den nächsten Abschnitten werden einige Beispiele vorgestellt
  • Eine vollständige Liste der möglichen Inhalte der Formatzeichenfolge finden Sie in den mod_log_config Formatzeichenfolgen

Common Log Format

Eine typische Konfiguration für das Zugriffsprotokoll könnte wie folgt aussehen 

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

Hierdurch wird der Spitzname common definiert und mit einer bestimmten Protokollformatzeichenfolge verknüpft

  • Die Formatzeichenfolge besteht aus Prozentanweisungen, die den Server jeweils anweisen, eine bestimmte Information zu protokollieren
  • In die Formatzeichenfolge können auch Literalzeichen eingefügt werden, die direkt in die Protokollausgabe kopiert werden
  • Das Anführungszeichen (") muss durch einen vorangestellten Backslash maskiert werden, damit es nicht als Ende der Formatzeichenfolge interpretiert wird
  • Die Formatzeichenfolge kann auch die speziellen Steuerzeichen ‚\n‘ für Zeilenumbruch und ‚\t‘ für Tabulator enthalten

Die CustomLog-Anweisung erstellt eine neue Protokolldatei unter Verwendung des definierten Spitznamens

  • Der Dateiname für das Zugriffsprotokoll ist relativ zum ServerRoot, es sei denn, er beginnt mit einem Schrägstrich

Die obige Konfiguration schreibt Protokolleinträge in einem Format, das als Common Log Format (CLF) bekannt ist

  • Dieses Standardformat kann von vielen verschiedenen Webservern erstellt und von vielen Protokollanalyseprogrammen gelesen werden

Die in CLF erstellten Protokolldateieinträge sehen in etwa so aus: 

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

Jeder Teil dieses Logeintrags wird im Folgenden beschrieben

127.0.0.1 (%h)

Dies ist die IP-Adresse des Clients (Remote-Host), der die Anfrage an den Server gestellt hat

  • Wenn HostnameLookupsauf On gesetzt ist, versucht der Server, den Hostnamen zu ermitteln und anstelle der IP-Adresse zu protokollieren
  • Diese Konfiguration wird jedoch nicht empfohlen, da sie den Server erheblich verlangsamen kann
  • Stattdessen empfiehlt es sich, einen Protokoll-Postprozessor wie logresolve zu verwenden, um die Hostnamen zu ermitteln
  • Die hier gemeldete IP-Adresse ist nicht unbedingt die Adresse des Computers, an dem der Benutzer sitzt
  • Wenn sich zwischen dem Benutzer und dem Server ein Proxyserver befindet, ist diese Adresse die Adresse des Proxys und nicht die des Ursprungscomputers
- (%l)

Der "Bindestrich" in der Ausgabe zeigt an, dass die angeforderte Information nicht verfügbar ist

  • In diesem Fall ist die nicht verfügbare Information die RFC 1413-Identität des Clients, die von identd auf dem Client-Rechner ermittelt wurde
  • Diese Information ist höchst unzuverlässig und sollte fast nie verwendet werden, außer in streng kontrollierten internen Netzwerken
  • Apache httpd versucht nicht einmal, diese Informationen zu ermitteln, es sei denn, IdentityCheckist auf On gesetzt
frank (%u)

Dies ist die Benutzerkennung der Person, die das Dokument anfordert, wie durch die HTTP-Authentifizierung bestimmt

  • Der gleiche Wert wird normalerweise CGI-Skripten in der REMOTE_USER-Umgebungsvariable bereitgestellt
  • Wenn der Statuscode für die Anfrage (siehe unten) 401 ist, sollte dieser Wert nicht als vertrauenswürdig eingestuft werden, da der Benutzer noch nicht authentifiziert ist
  • Wenn das Dokument nicht kennwortgeschützt ist, lautet dieser Teil "-", genau wie der vorherige
[10/Oct/2000
13:55:36 -0700] (%t)

Die Uhrzeit, zu der die Anfrage empfangen wurde

Das Format ist 

[Tag/Monat/Jahr:Stunde:Minute:Sekunde Zone]
Tag = 2*Ziffer
Monat = 3*Buchstabe
Jahr = 4*Ziffer
Stunde = 2*Ziffer
Minute = 2*Ziffer
Sekunde = 2*Ziffer
Zone = (`+' | `-') 4*Ziffer

Es ist möglich, die Zeit in einem anderen Format anzuzeigen, indem %{format}t in der Logformatzeichenkette angegeben wird, wobei format entweder wie in strftime(3) aus der C-Standardbibliothek oder eines der unterstützten speziellen Token ist

"GET /apache_pb.gif HTTP/1.0"("%r")

Die Anforderungszeile des Clients wird in doppelten Anführungszeichen angegeben

  • Die Anforderungszeile enthält eine Vielzahl nützlicher Informationen
  • Erstens ist die vom Client verwendete Methode GET
  • Zweitens hat der Client die Ressource /apache_pb.gif angefordertund drittens hat der Client das Protokoll HTTP/1.0 verwendet
  • Es ist auch möglich, einen oder mehrere Teile der Anforderungszeile unabhängig voneinander zu protokollieren
  • Beispielsweise protokolliert der Formatierungsstring "%m %U%q %H" die Methode, den Pfad, die Abfragezeichenfolge und das Protokoll, was genau zur gleichen Ausgabe führt wie "%r"
200 (%>s)

Dies ist der Statuscode, den der Server an den Client zurücksendet

  • Diese Information ist sehr wertvoll, da sie anzeigt, ob die Anfrage zu einer erfolgreichen Antwort (Codes beginnen mit 2), einer Umleitung (Codes beginnen mit 3), einem vom Client verursachten Fehler (Codes beginnen mit 4) oder einem Fehler im Server (Codes beginnen mit 5) geführt hat

Die vollständige Liste der möglichen Statuscodes finden Sie in der HTTP-Spezifikation (RFC2616 Abschnitt 10)

2326 (%b)

Der letzte Teil gibt die Größe des an den Client zurückgegebenen Objekts an, ohne die Antwort-Header

  • Wenn kein Inhalt an den Client zurückgegeben wurde, lautet dieser Wert "-" um "0" für keinen Inhalt zu protokollieren, verwenden Sie stattdessen "%B"

Combined Log Format

Ein weiteres häufig verwendetes Format ist das Combined Log Format

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 entspricht genau dem Common Log Format, mit dem Zusatz von zwei weiteren Feldern

  • Jedes der zusätzlichen Felder verwendet die Prozent-Direktive %{header}i, wobei header ein beliebiger HTTP-Request-Header sein kann
  • Das Zugriffsprotokoll in diesem Format sieht wie folgt 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 "Referer" (sic) HTTP-Anforderungsheader

  • Dieser gibt die Website an, von der der Client angibt, weitergeleitet worden zu sein. (Dies sollte die Seite sein, die auf /apache_pb.gif verlinkt oder diese einbindet)
"Mozilla/4.08 [en] (Win98; I ;Nav)"("%{User-agent}i\")

Der User-Agent-HTTP-Request-Header

  • Dies sind die identifizierenden Informationen, die der Client-Browser über sich selbst meldet

Mehrere Zugriffsprotokolle

Mehrere Zugriffsprotokolle können einfach durch Angabe mehrerer CustomLog-Anweisungen in der Konfigurationsdatei erstellt werden

  • Die folgenden Anweisungen erstellen beispielsweise drei Zugriffsprotokolle
  • Das erste enthält die grundlegenden CLF-Informationen, während das zweite und dritte Referer- und Browserinformationen enthalten
  • Die letzten beiden CustomLog-Zeilen zeigen, wie die Auswirkungen der ReferLog- und AgentLog-Anweisungen nachgeahmt werden können
LogFormat "%h %l %u %t \"%r\" %>s %b" common
CustomLog-Protokolle/access_log common
CustomLog-Protokolle/referer_log "%{Referer}i -> %U"
CustomLog-Protokolle/agent_log "%{User-agent}i"

Dieses Beispiel zeigt auch, dass es nicht notwendig ist, mit der LogFormat-Direktive einen Spitznamen zu definieren

  • Stattdessen kann das Protokollformat direkt in der CustomLog-Direktive angegeben werden

Bedingte Protokolle

Manchmal ist es sinnvoll, bestimmte Einträge aus den Zugriffsprotokollen auszuschließen, die auf den Merkmalen der Client-Anfrage basieren

  • Dies lässt sich mithilfe von Umgebungsvariablen leicht bewerkstelligen
  • Zunächst muss eine Umgebungsvariable festgelegt werden, die angibt, dass die Anfrage bestimmte Bedingungen erfüllt
  • Dies wird in der Regel mit SetEnvIf erreicht
  • Anschließend wird die env= Klausel der CustomLog-Direktive verwendet, um Anfragen einzuschließen oder auszuschließen, bei denen die Umgebungsvariable festgelegt ist
Einige Beispiele
# Mark requests from the loop-back interface
SetEnvIf Remote_Addr "127\.0\.0\.1" dontlog
# Mark requests for the robots.txt file
SetEnvIf Request_URI "^/robots\.txt$" dontlog
# Log what remains
CustomLog logs/access_log common env=!dontlog

Als weiteres Beispiel können Sie Anfragen von englischsprachigen Personen in einer Logdatei und Anfragen von nicht englischsprachigen Personen in einer anderen Logdatei protokollieren 

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

In einem Caching-Szenario möchte man die Effizienz des Caches kennen

Eine sehr einfache Methode, dies herauszufinden, wäre: 

SetEnv CACHE_MISS 1
LogFormat "%h %l %u %t ‚%r ‘ %>s %b %{CACHE_MISS}e" common-cache
CustomLog logs/access_log common-cache

mod_cache wird vor mod_env ausgeführt und liefert bei Erfolg den Inhalt ohne diese

  • In diesem Fall wird ein Cache-Treffer protokolliert –während ein Cache-Fehler 1 protokolliert

Zusätzlich zur env=-Syntax unterstützt LogFormat Protokollierungswerte, die vom HTTP-Antwortcode abhängig sind: 

LogFormat "%400,501{User-agent}i" browserlog
LogFormat "%!200,304,302{Referer}i" refererlog

Im ersten Beispiel wird der User-Agent protokolliert, wenn der HTTP-Statuscode 400 oder 501 lautet

  • In anderen Fällen wird stattdessen ein "-" protokolliert
  • Ebenso wird im zweiten Beispiel der Referer protokolliert, wenn der HTTP-Statuscode nicht 200, 304 oder 302 lautet. (Beachten Sie das "!" vor den Statuscodes

Obwohl wir gerade gezeigt haben, dass die bedingte Protokollierung sehr leistungsstark und flexibel ist, ist sie nicht die einzige Möglichkeit, den Inhalt der Protokolle zu steuern

  • Protokolldateien sind nützlicher, wenn sie eine vollständige Aufzeichnung der Serveraktivität enthalten
  • Oft ist es einfacher, die Protokolldateien einfach nachzubearbeiten, um Anfragen zu entfernen, die Sie nicht berücksichtigen möchten

Protokollrotation

Selbst auf einem mäßig ausgelasteten Server ist die Menge der in den Protokolldateien gespeicherten Informationen sehr groß

  • Die Zugriffsprotokolldatei wächst in der Regel um 1 MB oder mehr pro 10.000 Anfragen
  • Daher ist es notwendig, die Protokolldateien regelmäßig zu rotieren, indem die vorhandenen Protokolle verschoben oder gelöscht werden
  • Dies kann nicht durchgeführt werden, während der Server läuft, da Apache httpd weiterhin in die alte Protokolldatei schreibt, solange die Datei geöffnet ist
  • Stattdessen muss der Server neu gestartet werden, nachdem die Protokolldateien verschoben oder gelöscht wurden, damit neue Protokolldateien geöffnet werden

Durch einen sanften Neustart kann der Server angewiesen werden, neue Protokolldateien zu öffnen, ohne dass bestehende oder ausstehende Verbindungen von Clients verloren gehen

  • Um dies zu erreichen, muss der Server jedoch weiterhin in die alten Protokolldateien schreiben, während er alte Anfragen bearbeitet
  • Daher muss nach dem Neustart eine gewisse Zeit gewartet werden, bevor die Protokolldateien verarbeitet werden
  • Ein typisches Szenario, bei dem die Protokolle einfach rotiert und die alten Protokolle komprimiert werden, um Speicherplatz zu sparen, sieht wie folgt aus:
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, die Protokollrotation durchzuführen, ist die Verwendung von verketteten Protokollen, wie im nächsten Abschnitt beschrieben

Verkettete Protokolle

Apache httpd kann Fehler- und Zugriffsprotokolldateien über eine Pipe an einen anderen Prozess schreiben, anstatt sie direkt in eine Datei zu schreiben

  • Diese Funktion erhöht die Flexibilität der Protokollierung erheblich, ohne dass Code zum Hauptserver hinzugefügt werden muss
  • Um Protokolle in eine Pipe zu schreiben, ersetzen Sie einfach den Dateinamen durch das Pipe-Zeichen "|", gefolgt vom Namen der ausführbaren Datei, die Protokolleinträge über ihre Standardeingabe akzeptieren soll
  • Der Server startet den Piped-Log-Prozess, wenn der Server startet, und startet ihn neu, wenn er abstürzt, während der Server läuft. (Diese letzte Funktion ist der Grund, warum wir diese Technik als "zuverlässige Piped-Protokollierung" bezeichnen können.)

Piped-Log-Prozesse werden vom übergeordneten Apache-httpd-Prozess erzeugt und erben die Benutzerkennung dieses Prozesses

  • Das bedeutet, dass Piped-Log-Programme normalerweise als root ausgeführt werden
  • Es ist daher sehr wichtig, die Programme einfach und sicher zu halten

Eine wichtige Funktion von verketteten Protokollen besteht darin, eine Protokollrotation zu ermöglichen, ohne den Server neu starten zu müssen

  • Der Apache HTTP-Server enthält zu diesem Zweck ein einfaches Programm namens rotatelogs
  • Um beispielsweise die Protokolle alle 24 Stunden zu rotieren, können Sie Folgendes verwenden:
CustomLog "|/usr/local/apache/bin/rotatelogs /var/log/access_log 86400" common

Beachten Sie, dass der gesamte Befehl, der für die Pipe aufgerufen wird, in Anführungszeichen gesetzt wird

  • Obwohl diese Beispiele für das Zugriffsprotokoll gelten, kann dieselbe Technik für das Fehlerprotokoll verwendet werden

Wie bei der bedingten Protokollierung sind über die Pipe verbundene Protokolle ein sehr leistungsstarkes Tool, sollten jedoch nicht verwendet werden, wenn eine einfachere Lösung wie die Offline-Nachbearbeitung verfügbar ist

Standardmäßig wird der Piped-Log-Prozess ohne Aufruf einer Shell gestartet

  • Verwenden Sie "|$" anstelle von "|", um eine Shell zu verwenden (normalerweise mit /bin/sh -c):
# "rotatelogs" über eine Shell aufrufen
CustomLog "|$/usr/local/apache/bin/rotatelogs /var/log/access_log 86400" common

Dies war das Standardverhalten für Apache 2.2

  • Je nach den Besonderheiten der Shell kann dies zu einem zusätzlichen Shell-Prozess für die Lebensdauer des Protokollierungs-Pipe-Programms und zu Problemen bei der Signalverarbeitung während des Neustarts führen
  • Aus Gründen der Kompatibilität mit Apache 2.2 wird die Notation "||" ebenfalls unterstützt und ist gleichbedeutend mit der Verwendung von "|"

Windows-Hinweis

Beachten Sie, dass es unter Windows zu Problemen kommen kann, wenn viele Piped-Logger-Prozesse ausgeführt werden, insbesondere wenn HTTPD als Dienst ausgeführt wird

  • Dies wird durch einen zu geringen Desktop-Heap-Speicherplatz verursacht
  • Der Desktop-Heap-Speicherplatz, der jedem Dienst zugewiesen wird, wird durch das dritte Argument des SharedSection-Parameters im Registrierungswert HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SessionManager\SubSystems\Windows angegeben.
Ändern Sie diesen Wert mit Vorsicht

Es gelten die üblichen Vorsichtsmaßnahmen für Änderungen an der Windows-Registrierung, aber Sie könnten auch den Desktop-Heap-Pool erschöpfen, wenn die Zahl zu hoch eingestellt wird.

Virtuelle Hosts

Beim Betrieb eines Servers mit vielen virtuellen Hosts gibt es mehrere Möglichkeiten, mit Protokolldateien umzugehen

  • Zunächst ist es möglich, Protokolle genau wie bei einem Server mit einem Host zu verwenden
  • Durch einfaches Platzieren der Protokollierungsanweisungen außerhalb der <VirtualHost>-Abschnitte im Hauptserverkontext ist es möglich, alle Anfragen im selben Zugriffs- und Fehlerprotokoll zu protokollieren
  • Diese Technik ermöglicht keine einfache Erfassung von Statistiken zu einzelnen virtuellen Hosts

Wenn CustomLog- oder ErrorLog-Anweisungen innerhalb eines <VirtualHost>-Abschnitts platziert werden, werden alle Anfragen oder Fehler für diesen virtuellen Host nur in der angegebenen Datei protokolliert

  • Bei jedem virtuellen Host, der keine Protokollierungsanweisungen hat, werden die Anfragen weiterhin an die Hauptserverprotokolle gesendet
  • Diese Technik ist für eine kleine Anzahl virtueller Hosts sehr nützlich, aber wenn die Anzahl der Hosts sehr groß ist, kann sie kompliziert zu verwalten sein
  • Darüber hinaus kann sie häufig Probleme mit unzureichenden Dateideskriptoren verursachen

Für das Zugriffsprotokoll gibt es einen sehr guten Kompromiss

  • Durch Hinzufügen von Informationen über den virtuellen Host zur Protokollformatzeichenfolge ist es möglich, alle Hosts im selben Protokoll zu protokollieren und das Protokoll später in einzelne Dateien aufzuteilen

Betrachten Sie beispielsweise die folgenden Anweisungen 

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

Das %v wird verwendet, um den Namen des virtuellen Hosts zu protokollieren, der die Anfrage bearbeitet

  • Anschließend kann ein Programm wie "split-logfile" verwendet werden, um das Zugriffsprotokoll nachzubearbeiten und es in eine Datei pro virtuellem Host aufzuteilen

Weitere Protokolldateien

Verwandte Module Verwandte Anweisungen

Protokollierung der tatsächlich gesendeten und empfangenen Bytes

mod_logio fügt zwei zusätzliche LogFormat-Felder hinzu (%I und %O), die die tatsächliche Anzahl der im Netzwerk empfangenen und gesendeten Bytes protokollieren

Forensische Protokollierung

mod_log_forensic ermöglicht die forensische Protokollierung von Client-Anfragen

  • Die Protokollierung erfolgt vor und nach der Verarbeitung einer Anfrage, sodass das forensische Protokoll zwei Protokollzeilen für jede Anfrage enthält
  • Der forensische Logger ist sehr strikt und lässt keine Anpassungen zu
  • Er kann ein unschätzbares Debugging- und Sicherheitswerkzeug sein

PID-Datei

Beim Start speichert Apache httpd die Prozess-ID des übergeordneten httpd-Prozesses in der Datei logs/httpd.pid

  • Dieser Dateiname kann mit der PidFile-Anweisung geändert werden
  • Die Prozess-ID wird vom Administrator zum Neustarten und Beenden des Daemons verwendet, indem Signale an den übergeordneten Prozess gesendet werden
  • Unter Windows verwenden Sie stattdessen die Befehlszeilenoption -k
  • Weitere Informationen finden Sie auf der Seite Stoppen und Neustarten

Skriptprotokoll

Um die Fehlersuche zu erleichtern, ermöglicht die ScriptLog-Direktive die Aufzeichnung der Eingabe und Ausgabe von CGI-Skripten

  • Dies sollte nur zu Testzwecken verwendet werden – nicht für Live-Server
  • Weitere Informationen finden Sie in der mod_cgi-Dokumentation
Abgerufen von „https://wiki.foxtom.de/index.php?title=Apache/HTTP/Logging/tmp&oldid=131852“