LogWerk: KI-Crawler im Server-Logfile erkennen

Ich habe mir eine gefühlte Ewigkeit einen Wolf nach einem vernünftigen Tool für Server-Logfiles gesucht. Irgendwann landet man bei den üblichen Verdächtigen, und ganz oben standen GoAccess und Logdy – beide sehr mächtig, beide etablierte Pakete, beide für meinen Fall mit Kanonen auf Spatzen geschossen.

Denn ich wollte eigentlich nur eine access.log irgendwo reinziehen und in Sekunden sehen, welche Bots da wo ihr Unwesen treiben. Kein Monitoring-Stack, kein Dauerbetrieb, kein weiteres Ding, das permanent läuft. Also habe ich mir so ein Teil selbst gebaut – LogWerk.

Beziehungsweise bauen lassen – den Code hat das frisch erschienene Claude Sonnet 5 geschrieben. Ein Frontend ohne Backend und Build-Step ist genau die Sorte Aufgabe, an der ein Coding-Agent glänzt – überschaubarer Scope, keine exotischen Libraries im Stack, klares Ziel, sofort im Browser testbar.

TL;DR

LogWerk ist ein browser-basierter Server-Log-Analyzer, den ich gebaut habe, weil mir GoAccess und Logdy für den schnellen Blick ins Log zu viel Setup waren.

Läuft komplett im Browser, deine Log-Daten bleiben lokal – kein Backend, keine Datenbank.
Erkennt 60 Bots namentlich, inklusive KI-Crawler wie GPTBot, ClaudeBot und PerplexityBot.
Nginx/Apache-Presets, Custom-RegEx, Offline-Geo-IP, Session-Timelines, CSV-Export.
Version 1.2, MIT-lizenziert und ausbaufähig – Feedback und Issues im GitHub-Repo erwünscht.

Warum mir die üblichen Verdächtigen zu viel waren

GoAccess ist ein Klassiker, und das zu Recht. Echtzeit-Analyse, Terminal-UI, auf Wunsch ein self-contained HTML-Report. Genau da fing für mich das Problem an. Die Bedienung läuft primär übers Terminal, und für den laufenden Betrieb landet man schnell bei einem installierten Binary oder einem Container. Ich wollte für eine schnelle Log-Auswertung, aber weder das eine kompilieren noch das andere hochziehen.

Logdy ist eleganter, als ich zuerst dachte – ein einzelnes Binary, das man in den PATH legt und das eine lokale Web-UI auf einem Port startet. Nur ist es eher fürs Live-Tailing von App-Logs gebaut als für die Frage, was in dieser einen access.log von heute Morgen eigentlich steht. Auch hier läuft am Ende ein Prozess, den ich für einen Fünf-Minuten-Blick nicht starten wollte.

Beide lassen die Daten übrigens auf der Maschine. Dieser Punkt gehört also nicht LogWerk allein, und ich verkaufe hier keinen Vorteil, den es nicht hat.

Was LogWerk ist – und was nicht

LogWerk ist eine einzelne HTML-Seite. Drei ES6-Module, kein Backend, keine Datenbank, kein Build-Step. Du ziehst deine Logdatei in die Dropzone, das Parsing passiert komplett im Browser und in Häppchen, damit auch ein fettes File die Oberfläche nicht einfriert. Als Presets kommen Nginx/Apache Combined (Default), Apache Common und ein eigenes Custom-RegEx-Muster mit.

Was es nicht ist, ist ein Echtzeit-Monitor. Es ersetzt GoAccess nicht, wenn du ein Live-Dashboard mit WebSocket-Updates brauchst. Es ist für den Blick zurück gedacht, nicht für die Dauerüberwachung.

Der eigentliche Grund – wer crawlt hier überhaupt

Hier wird es für alle interessant, die sich mit GEO und SEO beschäftigen. LogWerk erkennt 60 benannte Bot-Signaturen und sortiert sie nach Anbieter und Zweck – Such-Indexer, SEO-Tools, Social-Media-Previews, Fediverse-Crawler, Security-Scanner. Alles, was durchs Raster fällt, aber nach Bot riecht, fängt ein generischer Fallback ab. Der Teil, der mich getrieben hat, sind primär die KI-Crawler.

GPTBot und ChatGPT-User von OpenAI, ClaudeBot von Anthropic, PerplexityBot, Amazonbot, der Meta-ExternalAgent – die tauchen in deinem Access-Log auf, lange bevor irgendein Dashboard dir davon erzählt. Die Google Search Console zeigt dir das nicht. Wer wissen will, ob und wie oft die KI-Crawler die eigenen Inhalte abgreifen, muss ins rohe Log. Filter auf „Bots Only“, Dropdown auf den konkreten Bot, fertig.

Dass ein KI-Crawler deine Seite liest, heißt aber noch lange nicht, dass daraus etwas zurückkommt und das Log macht diese Ernüchterung schnell sichtbar. Trotzdem ist es die ehrlichste Datenquelle, die du hast – näher als die server-eigenen Logs geht nicht.

Dazu kommen ein paar Dinge, die den Alltag angenehm machen. Offline-Geo-IP-Badges zeigen dir pro Request das Herkunftsland, ohne dass eine Anfrage rausgeht. Eine Session-Rekonstruktion gruppiert Requests per Fingerprint aus IP und User-Agent in chronologische Timelines, mit einer halben Stunde Inaktivität als Trennlinie. Filtern und suchen kannst du nach IP, Pfad, Status, Referer oder User-Agent, und das gefilterte Set exportierst du als CSV. Weil das letzte Log in der IndexedDB landet, ist es nach einem Reload einfach wieder da. Die Oberfläche spricht sechs Sprachen, umschaltbar zur Laufzeit.

Wie repräsentativ diese Bot-Liste ist, sehe ich an meinen eigenen Logs. Die allermeisten Signaturen, die LogWerk kennt, tauchen auch in diesem Blog auf – KI-Crawler, SEO-Spider, Fediverse-Bots, quer durch. Warum ein überschaubarer Blog aus der DACH-Ecke von diesem ganzen Zoo abgegrast wird, woher die alle kommen und was sie davon haben, weiß ich bis heute nicht. Sie sind eben so da und schauen gelegentlich mal rein. Wobei der OAI-SearchBot hier mit Abstand am fleißigsten ist.

Wie du es startest – die eine Hürde

Ganz ohne Reibung geht es nicht, und das sage ich lieber vorher. Moderne Browser blocken das Laden lokaler JS-Module über das file://-Protokoll, eine CORS-Sicherheitsregel. Es gibt zwei Wege drumherum.

Der saubere Weg ist ein lokaler Static-Server. python3 -m http.server 8000 im Projektordner, dann localhost:8000 im Browser – npx serve oder php -S tun es genauso.

Der schnelle Weg ist Safari-spezifisch. Entwickler-Features aktivieren, unter „Entwickeln“ die lokalen Dateibeschränkungen deaktivieren, index.html doppelklicken. Wer stattdessen Chrome ohne Server aufmacht, rennt allersings gegen die Wand.

Zugegeben: Das ist die eine Stelle, an der „einfach im Browser öffnen“ nicht ganz korrekt ist.

Ehrlich unfertig

Version 1.2, noch nicht fertig abgehangen, und eigentlich müsste die Versionsnummer ehrlicherweise aktuell noch eine 0 anstatt einer 1 davor haben. Aber da ich sonst jeden Hersteller-Claim sportlich seziere, mache ich das beim eigenen Tool auch. Im README steht „offline-first“, und das braucht eine Einordnung. Deine Log-Daten verlassen den Browser nicht, das stimmt und ist der Kern. Tailwind, Chart.js und die Fonts kommen aber per CDN, für den ersten Load brauchst du also Internet. „Lokal“ ja, „komplett ohne Netz“ nein.

An der einen oder anderen Stelle wird außerdem noch eine Ungereimtheit auftauchen. Ist mir bewusst, ist v1.2, und ausbaufähig ist das Ding sowieso. Es rennt für meinen Geschmack schnell, aber das ist ein Erfahrungswert, keine gebenchte Zahl.

Nimm es, tritt dagegen

Das Teil ist MIT-lizenziert und liegt offen im Repo. Wenn du eine access.log schnell auswerten willst, ohne dafür Infrastruktur anzufassen, nimm es. Und wenn dir etwas auffällt – es wird dir etwas auffallen – dann öffne ein Issue auf Github, statt es für dich zu behalten. Genau dafür ist es öffentlich.

Hot Take

Das schlankeste Tool gewinnt keinen Funktionsvergleich gegen GoAccess. Aber es ist das, das ich tatsächlich öffne, wenn ich in zwei Minuten wissen will, wer da crawlt – und benutzt schlägt mächtig.