Apache access.log Dateien ausschliessen??

[hawkmaster]

Hallo zusammen,

in meiner Apache (2.2.4) access.log stehen unter anderem immer wieder die Zeilen;
127.0.0.1 - - [17/Jul/2007:16:27:47 +0200] "GET /testweb/check_uk.js HTTP/1.1" 304 -
127.0.0.1 - - [17/Jul/2007:16:27:47 +0200] "GET /testweb/win.css HTTP/1.1" 304 -

Damit die Datei nicht so gross wird, hätte ich gerne diese Einträge unterdrückt.
Ich habe mir zwar die Doku zum Log Format durchgaschaut aber ich blick es nicht so recht.
Gibt es eine Möglichkeit, dass entweder die Codes "304" nicht geloggt werden oder als Alternative die Dateien "win.css" und "check_uk.js" ?

bin für jeden Tipp dankbar.
Gruss
hawk

[Sven Rautenberg]

Moin!

Damit die Datei nicht so gross wird, hätte ich gerne diese Einträge unterdrückt.

Wenn du gar nicht loggen willst, schalt's doch aus.

Ich habe mir zwar die Doku zum Log Format durchgaschaut aber ich blick es nicht so recht.
Gibt es eine Möglichkeit, dass entweder die Codes "304" nicht geloggt werden oder als Alternative die Dateien "win.css" und "check_uk.js" ?

Du kannst deinem Browser auch sagen, dass er nicht immer beim Server nach aktuellen Versionen dieser Dateien nachfragen soll - das ist aber beim Entwickeln von Seiten richtig blöd, weil du dann auch durch Reload nicht die neuesten Dateiversionen kriegst, sondern immer den Cache löschen mußt. Aber immerhin ersparst du dir dann viele dieser 304-Zeilen.

- Sven Rautenberg

[hawkmaster]

Hallo Sven,
danke dir für deine Hilfe,

Du kannst deinem Browser auch sagen, dass er nicht immer beim Server nach aktuellen Versionen dieser Dateien nachfragen soll

Mir geht es eigentlich nicht um das Entwickeln sondern für den späteren Produktionseinsatz.

Wie ging das nochmals das der Browser nicht immer nach den aktuellen Versionen nachfrägt?
War das nicht etwas mit dem http Header?
Und muss ich das dann in alle meine PHP Dateien des Projekts einbinden?

Zum Logging nochmals:
Kennst du dich damit auch aus.
Was ich bis jetzt gefunden habe:
Man kann wohl in der httpd.conf Umgebungsvariablen setzen und diese dann vom Logging ausschliesen.

SetEnv Remote_Addr 127.0.0.1 nolog
CustomLog /var/log/apache2/access.log.domain common env=!nolog

Wie müsste die Syntax aber wohl für Dateien sein?
SetEnv Files "*.js" "*.css" nolog   ????

Gruss und danke
hawk

[Sven Rautenberg]

Moin!

Mir geht es eigentlich nicht um das Entwickeln sondern für den späteren Produktionseinsatz.

Produktive Webserver produzieren große Logfiles - das ist Gesetz! Dagegen hilft auch nicht, wenn man Statuscode-304-Zeilen aus dem Logging ausschließt. Das macht die Dateien nicht entscheidend kleiner, sie werden immer noch sehr groß werden.

Wenn du ein Problem mit großen Logfiles hast, dann installiere Systeme, die mit großen Logfiles umgehen können.

Bedenke: Auch ein 304 hat ja eine Relevanz. Es ist ein Hit, also ein vom Server zu beantwortender Request, was bei Lastanalysen wichtig ist. Und außerdem bilden Logfiles ja in gewisser Weise die Währung der Werbewirtschaft (auch wenn die sich mittlerweile ihre eigenen Zähler gebaut haben).

Wie ging das nochmals das der Browser nicht immer nach den aktuellen Versionen nachfrägt?

Diese Option ist irrelevant für produktive Webserver. Du wirst ja wohl kaum hinkriegen, dass alle User ihre Browsereinstellungen abändern, nur damit du dein Logfile klein behälst.

War das nicht etwas mit dem http Header?

Nein, absolut nicht. In Opera z.B. "Tools -> Preferences -> Advanced -> History: Check if cached page is updated on the server. Documents 'always' - Images 'every hour'". So ist das bei mir eingestellt. Und so hat es vermutlich jeder Webdeveloper mindestens eingestellt, weil er beim Reload sofort die aktuellste Version sehen will.

Normal wäre - und das ist, was du ja erreichen willst - dass der Browser beim normalen Surfen erst nach einer gewissen Zeit überhaupt checkt, ob seine Cacheversion noch aktuell ist.

Und muss ich das dann in alle meine PHP Dateien des Projekts einbinden?

Nein.

Zum Logging nochmals:
Kennst du dich damit auch aus.
Was ich bis jetzt gefunden habe:
Man kann wohl in der httpd.conf Umgebungsvariablen setzen und diese dann vom Logging ausschliesen.

SetEnv Remote_Addr 127.0.0.1 nolog
CustomLog /var/log/apache2/access.log.domain common env=!nolog

Wie müsste die Syntax aber wohl für Dateien sein?
SetEnv Files "*.js" "*.css" nolog   ????

Wie gesagt: Ich halte es für idiotisch, Logfiles beim Entstehen zu filtern. Und erst Recht ist es idiotisch, basierend auf Dateinamen zu filtern. Damit verhinderts du ja auch, Status 200 zu loggen.

Sorge für eine effektive Verarbeitung der Logfiles hinterher. Wo gibts da Probleme?

- Sven Rautenberg

[hawkmaster]

Hi Sven
ich gebe dir in allen Punkten recht.
Ich halte es auch nicht für sinnvoll bestimmte Dateien vom Log auszuschließen.
Mein Problem ist:
Ich habe eine kleine Intranet (nur firmen interne User) PHP Anwendung.
Hier habe ich jetzt mal eine Änderung versucht bei der der Client Browser per Javascript alle 10 Sekunden pollt und auf dem webserver bzw. MySQL Server nach aktuellen Einträgen in einer Tabelle sucht.

Dabei ist mir halt aufgefallen, dass die Access.log doch recht groß wird.
Eigentlich habe ich damit kein Problem, nur weiss ich nicht wie man das dann am besten den Admins beibringt nach den Logfiles zu schauen bzw. auch wegen der Dimensionierung der HDs.

Gruss und nochmals Danke
Hawk

[FraFu]

Hallo!

Eigentlich habe ich damit kein Problem, nur weiss ich nicht wie man das dann am besten den Admins beibringt nach den Logfiles zu schauen bzw. auch wegen der Dimensionierung der HDs.

Ein g'scheites OS hat ein eigenes Logfile Handling das dir diese Arbeit abnehmen sollte. Unter Linux ist da zb logrotate zuständig. Da brauch ich händisch gar nicht eingreifen.

mfg
  frafu

[Alexander (HH)]

Ein g'scheites OS hat ein eigenes Logfile Handling das dir diese Arbeit abnehmen sollte. Unter Linux ist da zb logrotate zuständig. Da brauch ich händisch gar nicht eingreifen.

Apache bringt übrigens auch einen Rotierer mit: http://httpd.apache.org/docs/2.0/programs/rotatelogs.html, http://httpd.apache.org/docs/1.3/programs/rotatelogs.html, http://httpd.apache.org/docs/2.2/programs/rotatelogs.html

Außerdem kann man die Logs auch in eine Datenbank schreiben, entweder online (indem man rotatelogs durch ein eigenes Programm ersetzt, das die Log-Ausgabe des Apache zerlegt und in die Datenbank schreibt) oder offline (indem man die bestehenden Logfiles zerlegt und in die Datenbank schreibt), wenn man's richtig anstellt, geht beides mit dem selben Programm. In der Datenbank kann man dann nach Herzenslust filtern und reporten, und wenn es sein muß, kann man auch schnell unnützen Müll löschen: DELETE FROM APACHE_LOGS WHERE STATUS=304 AND (REQUEST_URL LIKE '%/style.css%' OR REQUEST_URL LIKE '%/script.js%')

Alexander

[Sven Rautenberg]

Moin!

ich gebe dir in allen Punkten recht.

Das ist nett. :)

Ich habe eine kleine Intranet (nur firmen interne User) PHP Anwendung.
Hier habe ich jetzt mal eine Änderung versucht bei der der Client Browser per Javascript alle 10 Sekunden pollt und auf dem webserver bzw. MySQL Server nach aktuellen Einträgen in einer Tabelle sucht.

HTTP ist halt kein Push-Protokoll, wie es für viele Anwendungen sinnvoll wäre. Das wird sich auch so schnell leider nicht ändern, obwohl der Bedarf offenbar so langsam auch bei den Browserentwicklern durchdringt. Siehe z.B. unser Interview mit Mozilla (Stichwort "Engpaß HTTP").

Dabei ist mir halt aufgefallen, dass die Access.log doch recht groß wird.
Eigentlich habe ich damit kein Problem, nur weiss ich nicht wie man das dann am besten den Admins beibringt nach den Logfiles zu schauen bzw. auch wegen der Dimensionierung der HDs.

Die Sache ist doch recht simpel: Wenn Logging nicht benötigt wird, weil dadurch sowieso nur Datenmüll erzeugt wird, kann man's auch komplett abschalten, und nur im Bedarfsfall wieder aktivieren zur Fehlersuche o.ä.

Wenn das Logging hingegen gebraucht wird, um irgendwelche Statistiken zu befüllen, dann muß man die Logfiles ja sowieso verarbeiten und irgendwo lassen. Also wird sich um das Problem sowieso gekümmert werden. Logfiles zu archivieren ist gezippt (also mit gzip oder bzip2) sehr effektiv, weil sehr viele identische Informationen in den Dateien stehen. Sollte also ein Logfile eines ganzen Monats zu groß für die Festplatte sein, teilt man einfach den Zeitraum in kleinere Einheiten. Tagesweises Rotieren und Archivieren von Logfiles ist ja nun keine Seltenheit. Große Provider machen das sogar noch häufiger.

Dein Problem lautet also eigentlich nicht, wie du Logging selektiv verhinderst, sondern wie du Logfiles nach ihrer Entstehung sinnvoll weiterverarbeitest.

- Sven Rautenberg

[Tim Tepaße]

Hallo Sven,

HTTP ist halt kein Push-Protokoll, wie es für viele Anwendungen sinnvoll wäre. Das wird sich auch so schnell leider nicht ändern, obwohl der Bedarf offenbar so langsam auch bei den Browserentwicklern durchdringt. Siehe z.B. unser Interview mit Mozilla (Stichwort "Engpaß HTTP").

Das hatte mich neulich schon irritiert: Seid Ihr sicher, dass genau „HTTP erweitern“ die Aussage von den Mozillianern war?

Denn eigentlich bringt sich Mozilla bei der HTML 5 Geschichte stark ein. Und dort wirkt man von mir aus gesehen nicht der Meinung, die Request/Response-Semantik von HTML so erweitern zu müssen, dass diese verloren geht und durch ein Monsterprotokoll entsteht. Stattdessen wird mehr auf (fast) beliebige TCP-Verbindungen gesetzt und dafür eine API definiert. Beide Gedankengänge beissen sich dann doch etwas.

Tim