Langjährige Leser und solche, die gern mal in ander­er Leute Quell­code herum­forschen, hat­ten es möglicher­weise bere­its mit­bekom­men: Für diese Web­site sowie einige mein­er Pro­jek­te kam jahre­lang das Sta­tis­tik­w­erkzeug Mato­mo — schon unter seinem alten Namen — zum Ein­satz. Hier­für band ich statt der Ver­wen­dung als Log­analy­se­pro­gramm ein Zählscript auf eini­gen Seit­en ein, das die Besucher­dat­en direkt live in eine wach­sende Daten­bank schrieb, sofern die Besuch­er JavaScript aktiviert und/oder das Opt-Out-Cook­ie nicht geset­zt hat­ten.

Nun ist eine solche Soft­ware zwar im Prinzip sehr prak­tisch für Men­schen ein­er unfeinen Pro­fes­sion, näm­lich Wer­ber und ähn­liche Hei­nis, aber der Big-Data-Aspekt dieses Pro­gramms, das wesentlich mehr Sta­tis­tiken raus­blies als ich brauchen kon­nte (let­z­tendlich inter­essieren mich am meis­ten die Herkun­fts­seit­en und die unge­fähren Aufrufzahlen), vertrug sich nur mit­telmäßig mit meinem ander­weit­i­gen Pochen auf Daten­schutz. Mehr noch: Mato­mo ist ein her­aus­ra­gen­des Beispiel für fast alles, was ich an heutiger Weben­twick­lung in PHP nicht lei­den kann; so blink­te etwa seit dem let­zten größeren Ver­sion­sup­date ein rot­er Fehler­balken kurz auf, dessen Ursprung mir unklar geblieben ist. Mehr als ein­mal musste ich auch die Soft­ware (immer­hin nicht die Daten­bank) neu instal­lieren, weil irgen­dein Script bei der Aktu­al­isierung zwis­chen zwei Betaver­sio­nen — ja, ich bin mir des Prob­lems bewusst — irgendwelche Fehler gemacht hat­te, die im Bug­track­er des Mato­mo­pro­jek­ts zwar fast immer schon bekan­nt, aber sel­ten ein­fach zu lösen waren.

Da ich seit einiger Zeit ver­suche, die Nutzung von PHP-Scripts (zusam­men mit in Python geschriebe­nen Scripts, die Gründe sind ähn­lich) auf meinen Servern und Web­spaces zu reduzieren und langfristig ganz einzustellen, habe ich auch über die Nutzung von Mato­mo nochmals, wie man es wohl heutzu­tage nen­nt, ergeb­nisof­fen nachgedacht. Dieses Nach­denken hat­te Erfolg, denn auf Uberspace.de, auf deren Servern ich nach mehreren Wech­seln in kurz­er Zeit seit neun Jahren einiger­maßen zufrieden den Kram hier mache, gibt es bere­its anonymisierte und aus­führliche Log­dateien. Warum werte ich nicht ein­fach die aus?

Genau das mache ich jet­zt. Bei den Recherchen hierzu war mir aufge­fall­en, dass die Welt der Web­server­log­analyse sich in den let­zten zwanzig Jahren doch recht stark verän­dert hat; so ist zum Beispiel die Entwick­lung des Webal­iz­ers anscheinend been­det und der Betrieb von AWStats, das immer­hin noch gepflegt wird, bedarf bei Uber­space anscheinend — der Tweet ist jedoch von 2014 — einiger Umstände, die ich wed­er mir noch anderen unbe­d­ingt bere­it­en möchte.

Bei Dirk Deimeke, der aber jet­zt doch lieber etwas anderes ver­wen­det, und in so Foren fand ich den Hin­weis auf GoAc­cess, das in C geschrieben ist und aus den vorhan­de­nen Log­dateien nicht nur eine ver­gle­ich­sweise hüb­sche HTML-Aus­gabe gener­ieren, son­dern mit­tels eines einge­baut­en Daten­banksys­tems auch mit nur sieben Tage lang vorge­hal­te­nen Log­dateien eine länger­fristige His­to­rie anle­gen kann.

Auf Uber­space 7 ist die ver­al­tete Ver­sion 1.3 bere­its instal­liert, da aber Ver­sion 1.4 ein neues Daten­bank­for­mat hat, das mit der alten Ver­sion nicht mehr kom­pat­i­bel ist, habe ich beschlossen, meine eigene Instal­la­tion zu betreiben. Mith­il­fe eines Cron­jobs — mögliche Para­me­ter sind hier erk­lärt — erzeuge ich momen­tan, absichtlich auf die Echtzei­t­analyse verzich­t­end, alle zehn Minuten eine neue HTML-Datei mit den für mich inter­es­san­ten Dat­en, die die vorherige HTML-Datei erset­zt, und spare auf diese Weise nicht nur Arbeitsspe­ich­er (weniger Daten­bank, weniger PHP), son­dern habe auch ein etwas ruhigeres Gewis­sen, was den Umgang mit meinen Besuch­ern bet­rifft. Dass mich kün­ftige Updates nicht mehr ohne Vor­war­nung unschön stolpern lassen dürften, run­det die Sache für mich ab.

Ich kann das wärm­stens weit­erempfehlen.