Inoffizielles deutsches Xbase-Forum

Moin Kollegen,

wie wertet Ihr eigentlich eure Logfiles aus?

Bei uns wurde hierfür mal awstats eingerichtet, was ja schon mal eine Übersicht gibt - allerdings fehlt mir da auch einiges.

Ich hätte gern ein Tool, was mir für jedes Item (Bild, HTML etc.) angibt wie oft es in Zeitraum X aufgerufen wurde.

Gibt es da bereits eine fertige Lösung?

Oder hat jemand ein paar Code Schnipsel zum Auswerten der Logfiles?

Hallo Philipp

willst du Zugriffe auf Daten auf einem XB2net Web Server auswerten musst du dir deinen eigenen Funktionen schreiben.
Entweder solche die dir alle Aufrufe (Klicks) loggen oder besser gleich solche welche die Statistik entsprechend nachführen.

Nun, in den Beispielen und damit auch in vielen davon abgeleiteten Xb2.Net-Programmen wird die xbTLog()-Klasse benutzt, um Zugriffe zu loggen, und dazu heißt es in den Docs von Boris:

xbTLog
Class for logging client requests using Extended Log File Format (W3C Working Draft WD-logfile-960323).
This log format is compatible with Microsoft Internet Information Server (IIS) and is supported by
many third party web log analyzers.

Es sollte also da draußen jede Menge Tools geben, die die Logfiles verstehen.
Ergänzung: Man kann ja über die iVar :Fields der xbTLog-Klasse festlegen, welche Informationen geloggt werden. Das ist ein konkatinierter String, also kann man auch Semikolons dazwischensetzen, und schwupps hat man eine CSV-Datei. Die kann man sogar mit Excel auswerten.

Hallo Tom

das ist genau so wie du schreibst. XB2net schreibt sein Log mit der xbTLog() Klasse.

NUR bei der Anforderung (GET Request) einer HTML JPG oder sonstigen Datei aus dem www_root Verzeichnis wird Standardmässig NICHT geloggt.

Bei einer WEB-App möchte man ja meist auch noch mehr als nur den Funktionsaufruf loggen da bleibt dann sowieso nur die eigene Log-Funktion....

Das ist falsch, Carlo.

Hallo Tom

dir werden also alle Files wie .css .js die du verwendest geloggt? Bei mir nicht.

Die werden ja auch nicht zum Client transportiert, lieber Carlo. Aber alles, was sammler0002 wissen will, schreibt die xbTLog-Klasse mit.

Hallo Tom

Ich habe nachgeschaut: Es sind wirklich nur Spezialfälle die nicht geloggt werden.

Du hast recht.

Sorry für die Verwirrung.

Tom hat geschrieben: ↑Fr, 26. Jun 2020 17:18 Die werden ja auch nicht zum Client transportiert, lieber Carlo.

Ähem: wenn man es genau nimmt, werden die .css-Dateien und die .js-Dateien zum Client transportiert. Beides wird nämlich erst am Client interpretiert (gerendert bzw. ausgeführt).

Viele Grüße,
Martin

Es gibt "go access" in verschiedenen Distributionen und als Installationsaket für Windows: https://itefix.net/cowaxess

@Martin: Eingebettete Komponenten werden m.E. nicht in diesem Sinne als Files heruntergeladen und vom Client gecacht, wie das z.B. mit Fotos passiert.

Tom,
da zeigt mir das Testen mit einzelnen Browsern aber was anderes.
Wenn ich Änderungen an einer .css-Datei mache (oder einer .js-Datei), dann kann es sein, dass ein einfacher refresh im Browser nicht reicht (abhängig vom Browser). Meist schwenke ich dann auf einen anderen Browser um, um sicherzugehen (wenn der Fehler, der behoben wurde, nach der Änderung nicht weg ist).

Viele Grüße,
Martin

Ob eine Datei vom Server geladen wird oder aus dem Browser Cache genommen wird kannst du im Browser mit F12 -> Netzwerkanalyse einfach überprüfen.
Das Verhalten selbst kannst du mit dem Header Eintrag "CacheControl" vollumfänglich selbst bestimmen.

siehe: https://developer.mozilla.org/en-US/doc ... he-Control

In den Beispielen von XB2net wird z.B. "max-age=86400" verwendet, bedeutet dass immer die Datei aus den Cache verwendet wird sofern Sie nicht länger als 86400 Sekunden im Cache steht.

Für wichtige Inhaltsdateien ist die Einstellungen "no-cache, no-store, must-revalidate" sinnvoll. Diese Erzwingt immer ein neues laden.

Natürlich hilft auch ein Löschen den Browser-Cache um die Dateien neu vom Server laden zu lassen.

Martin,

genau deswegen machen wir das hier so, das die JS-Dateien eine Versionsnummer im Dateienamen mit bekommen. Dann ist das ein anderer Dateiname als bei der gecachten Version, und der Browser lädt die auf jeden Fall nach.

Ist zwar etwas mehr Aufwand in der Pflege der Dateien und des Codes, aber so sind wir sicher das die Kunden immer die aktuellsten Daten laden.

Jan

Vielen Dank für die Antworten und Hinweise. Damit kann ich doch schon mal etwas anfangen

Schönen Start in die Woche wünsche ich Euch!

Hallo, Martin.

da zeigt mir das Testen mit einzelnen Browsern aber was anderes.

Ich meine das auch eher, wie soll ich sagen, metaphysisch. Ein eingebundenes JPG ist Bestandteil des zu rendernden Dokuments, CSS-Klassen - ob nun eingebettet oder extern - und JavaScript-Komponenten befinden sich auf einer anderen Ebene, gehören eher zur Dokumentenbeschreibung. Das dürfte m.E. auch qualitativ einen Unterschied machen. Und, klar, für den Browsercache ist es dasselbe.