php_error.log -> für alle automatisch

[joximu]

Sehe ich auch so: access (combined) und error log sollen zum User.

Die traffic zahlen sollten unabhängig davon berechnet werden.

All das kann sicher mit einem zentralen Logsystem gemacht werden (weniger offene Logfile-Verbindungen).

aber PHP-Log ist was unabhängiges davon...

/J

[Cube]

Quote:Wobei ich die traffic-logs die beim User liegen für keine Berechnungen mehr verwenden würde. Die müssten dann zusätzlich noch in einem Bereich wo die User nicht dran kommt erstellt werden. Wollen ja nicht das die User genau das Minipuliert ,-)

Die Manipulation kann man ja über entsprechende Rechte oder Proftpd-Direktiven verhindern. Man könnte den Traffic auch aus dem combined-Log berechnen und den traffic-Log ganz abschaffen. Ich weiß nicht was effizienter ist: ein Log weniger schreiben und ein komplizierteres Log auswerten oder eines mehr schreiben und dafür eine einfachere Auswertung haben.

[joximu]

man könnte pro vhost genau je ein piped log aufmachen - mit allen notwendigen Angaben. Und daraus dann 3 Logs generieren (access/common + error für Kunde, traffic für ispcp).

Theoretisch könnte man für alle vhosts total ein piped log machen - wo auch der vhost drin steht - und dass dann wieder aufsplitten lassen (siehe http://httpd.apache.org/docs/2.2/programs/other.html "split-logfile" )

Aber es gibt sicher noch einige Möglichkeiten...

/J

[marcaust]

Möglichkeiten gibt es mit Sicherheit viele. Einfache und komplizierte.

Selbst wenn die Server / Rechner immer Leistungstärker werden, liebe ich das schlichte und einfache ;-)

@Cube: rein vom Bauchgefühl her würde ich sagen das eseffizienter ist ein Log mehr zu schreiben und eine einfachere Auswertung zu haben.

[joximu]

Es gibt halt echt ein Problem mit zuvielen Logs - zurzeit haben wir bei ca 180 vhosts ein Problem mit der Anzahl offenen Dateien durch Apache.
Man kann es etwas entschärfen, indem nur 3 statt 4 Logfiles geschrieben werden (traffic, error, combined) und lezteres ebenfalls als access zur Verfügung stellen.

Der Schritt, den Traffic aus dem combined zu berechnen ist nicht sehr aufwändig - das wäre wohl die nächste Optimierung:

Code:

grep $Datum $LogFile | awk 'BEGIN {tot=0} {tot+=$10} END {print tot/1024/1024 " MB"}'

gibt den Totaltraffic gemäss combined Logfile für einen bestimmten Tag in MB an.

/J

[marcaust]

Nunja, ich denke da stoße ich noch an meine Grenzen. Allerdings lerne ich gerne dazu ;-)

Ich weiß zwar nicht wie es bei dir aussieht, bei den error.log Dateien die ich kenne sind immer viele Einträge der Art:
[Mon Jun 20 10:29:19 2005] [error] [client 127.0.0.1] File does not exist: /var/www/favicon.ico
....

Da viele Seiten gar keine favicon.ico haben und somit bei jedem Seitenaufruf die error.log ebenfalls angesprochen wird, wär es evtl. eine Idee dafür eine default favicon.ico zu nehmen und sich somit den Eintrag in der error.log zu sparen.

Scheinbar scheint das hier:
# Don't bother looking for favicon.ico
Redirect 404 /favicon.ico

# Don't bother sending the custom error page for favicon.ico
<Location /favicon.ico>
ErrorDocument 404 "No favicon
</Location>
zu Funktionieren.

Hab ich hier gefunden: Getting rid of favicon.ico

[joximu]

Klar, du kannst auch alle Anfragen an robots.txt und alles andere, was sonst noch so 404 erzeugt so eliminieren.

Aber was soll das? Das sind dann verfälschte Error-logs. Die Seitenbetreiber sollen doch wissen, dass viele Browser und Suchmascheinen etwas anfragen, was sie auf ijrer seite nicht anbieten.

Man kann auch error.log nach /dev/null umleiten - das wird nie voll - kein logrotate mehr notwendig!!!

/J

[marcaust]

joximu Wrote:Aber was soll das? Das sind dann verfälschte Error-logs. Die Seitenbetreiber sollen doch wissen, dass viele Browser und Suchmascheinen etwas anfragen, was sie auf ijrer seite nicht anbieten.

Nicht anbieten wollen da dieses Icon (zumindest bei den mir bekannten Seitenbetreibern) als Schwachsinn, Mist betittelt und als völlig unnötig betrachtet wird. Gleichzeitig wird sich darüber aufgeregt das diese Fehlermeldung die error.log derart aufbläht und die anderen (für die Seitenbetreiber wichtigeren) Fehlermeldungen leicht übersehen werden. Dagegen unternommen, also eine favicon.ico ins Verzeichnis kopieren, wird von den Seitenbetreibern trotzdem nichts. So gesehen belastet diese Fehlermeldung nur unnötig den Server während die anderen (robots.txt, nicht gefundene *.html, *.php Dateien und Grafiken die für das Design einer Seite benötigt werden) erwünscht sind.

Einfach so abschalten würd ich das auch nicht.
Den Kunden fragen ob er diese Fehlermeldung unbedingt haben will oder nicht kann allerdings auch nicht schaden. Schließlich wird seine error.log ohne diese Meldung übersichtlicher wenn er keine eigene favicon.ico zur Verfügung stellen will und deine Server werden mit jeder abgeschalteten Meldung etwas entlastet.

[Diablo_Vmax1200]

Hi,
Ich denke, dass es doch OK wäre das Omega Logo als favicon per Default abzulegen. Wenn jemand ein eigenes hat, dann wird er seines einfach drüber kopieren.

Grüsse Michael

[fulltilt]

joximu Wrote:Es gibt halt echt ein Problem mit zuvielen Logs - zurzeit haben wir bei ca 180 vhosts ein Problem mit der Anzahl offenen Dateien durch Apache.
Man kann es etwas entschärfen, indem nur 3 statt 4 Logfiles geschrieben werden (traffic, error, combined) und lezteres ebenfalls als access zur Verfügung stellen.

Ich denke da sollte weiter dran gearbeitet werden, das mit favicon errors ist kaum relevant.