Server-Logs lesen: 404-Fehler, Bots und langsame Anfragen
Was jede Zeile eines Server-Logs zeigt, wie 404-Fehler und langsame Anfragen erkannt werden und wie sich echter Traffic von Bot-Traffic unterscheiden lässt.
rabbitclip-TeamVeröffentlicht: 5 Min. Lesezeit
Kurz gesagt
Eine Zeile in einem Server-Log enthält die anfragende Adresse, das Datum, die angeforderte Seite, den zurückgegebenen Statuscode und die Browserinformation, alles in einer einzigen Zeile. Wer diese Zeilen regelmäßig liest, bekommt Antworten auf drei Fragen: welche Seiten einen 404-Fehler auslösen, wie groß der Anteil echter Besucher gegenüber Bots tatsächlich ist, und welche Anfragen langsamer beantwortet werden als üblich. Alle drei Signale sind sichtbar, lange bevor daraus eine echte Beschwerde wird.
Wenn die Seite eines Facility-Management-Unternehmens im Monat nur ein paar Hundert Besucher zählt, der Server aber täglich Zehntausende Anfragen registriert, stammt diese Differenz fast immer aus Bot-Traffic. Ohne einen Blick in die Logs lässt sich diese Lücke kaum erklären.
Wie liest man eine Log-Zeile?
Ein Server-Log ist die Aufzeichnung, die ein Server über jede eingehende Anfrage führt; das voreingestellte «combined»-Format von Nginx und Apache listet die anfragende IP-Adresse, das Datum, die angeforderte Adresse, die HTTP-Methode, den Statuscode, die übertragene Bytezahl, die verweisende Seite und die Browserkennung, jeweils in dieser Reihenfolge.
In einer typischen Zeile steht zuerst die IP-Adresse des Besuchers, danach Datum und Uhrzeit in eckigen Klammern, dann die angeforderte Adresse in Anführungszeichen beginnend mit GET oder POST, unmittelbar gefolgt vom dreistelligen Statuscode, 200 für Erfolg, 404 für nicht gefunden, 500 für einen Serverfehler, der übertragenen Datenmenge und schließlich der Browserkennung in Anführungszeichen am Ende. Wer diese Reihenfolge einmal verinnerlicht hat, kann danach jede beliebige Log-Datei lesen.
Was zeigen 404-Fehler wirklich?
Ein 404 bedeutet, dass die angeforderte Seite auf dem Server nicht gefunden wurde. Das kommt entweder von einem defekten Link, einer anderen Seite, die auf eine nicht mehr existierende Adresse verweist, von einer Migration, bei der alte Adressen nie umgeleitet wurden, oder von einem Bot, der eine zufällige Adresse ausprobiert.
Regelmäßiges Durchsehen der 404-Fehler in den Logs zeigt, welcher defekte Link tatsächlich echte Besucher betrifft; ein 404, der häufig auftritt und von einem echten Browser stammt, verdient vorrangige Aufmerksamkeit, ein einmaliger Bot-Versuch kann meist ignoriert werden.
Wie unterscheidet man echte Besucher von Bot-Traffic?
Der erste Blick gilt dem User-Agent-Feld; bekannte Suchmaschinen-Bots geben sich offen zu erkennen. Ein bösartiger Bot präsentiert aber meist einen User-Agent, der wie ein echter Browser aussieht, weshalb dieses eine Feld allein nicht ausreicht.
- Mehr als eine Anfrage pro Sekunde von derselben IP-Adresse, was nicht dem Verhalten eines Menschen entspricht
- Wiederholte Anfragen, die sich nur auf bestimmte Seiten konzentrieren, ein Login-Formular, ein Suchfeld
- Anfragen, die direkt zu tiefen Seiten führen, ohne jemals zuvor robots.txt abzurufen
- Ein realistischer User-Agent gepaart mit fehlenden Headern, die ein echter Browser normalerweise mitsendet, Sprache, Cookies
Langsame Anfragen in den Logs finden
Die Antwortzeit erscheint in den meisten Standard-Log-Formaten nicht, aber Nginx und Apache bieten beide eine eigene Variable dafür an; ist sie einmal ergänzt, zeigt jede Anfrage, wie viele Millisekunden ihre Beantwortung gedauert hat.
Sobald dieses Feld vorhanden ist, lässt sich nach Anfragen über einem bestimmten Schwellenwert, etwa einer Sekunde, filtern; so findet sich schnell, welche Seite, welche Abfrage oder welche Integration die Verlangsamung verursacht. Das ist ein Signal, das sich erkennen lässt, bevor eine Kundin sich über eine langsame Seite beschwert.
Wie lange sollten Logs aufbewahrt werden, und wer sollte hineinschauen?
Log-Dateien werden nicht ewig aufbewahrt; der Speicherplatz ist begrenzt, und die meisten Hosting-Anbieter wenden eine Standardrotation von einigen Wochen bis wenigen Monaten an. Da eine Sicherheitsanalyse nach einem Vorfall auch ältere Logs benötigen kann, lohnt es sich, diesen Zeitraum bewusst festzulegen, statt ihn dem Standardwert des Anbieters zu überlassen.
Ein regelmäßiger Blick in die Logs kann für eine Person eine wöchentliche Zehn-Minuten-Gewohnheit sein; das Ziel ist nicht, jede Zeile zu lesen, sondern die Verteilung der Statuscodes und die am häufigsten wiederkehrenden Fehler im Blick zu behalten.
Mit einem einzigen Befehl eine schnelle Übersicht erstellen
Auch ohne technisches Team lässt sich aus einer Log-Datei schnell eine Übersicht gewinnen. Ein einfacher Befehl, der Log-Zeilen nach Statuscode zählt und sortiert, zeigt in Sekunden, wie oft sich welcher Fehler wiederholt; die häufigsten 404- oder 500-Fehler stehen dabei ganz oben.
Dieselbe Idee, sortiert nach der Gesamtzahl der Anfragen pro IP-Adresse, verrät sofort eine ungewöhnlich starke Bot-Quelle. Beide Filter liefern ein Ergebnis, das deutlich schneller vorliegt als das zeilenweise Durchlesen der gesamten Datei.
Häufige Fehler
Logs bleiben meist eine Datei, die nur geöffnet wird, wenn bereits etwas schiefgelaufen ist; ohne regelmäßigen Blick geht die frühe Warnung verloren.
- Logs erst prüfen, nachdem die Seite bereits ausgefallen ist, und die früheren Warnsignale übersehen
- 404-Fehler nie durchsehen, wodurch defekte Links monatelang unbemerkt bleiben
- Analytics so lesen, als wäre jeder Besuch ein Mensch, ohne den Bot-Anteil am Traffic je zu berücksichtigen
- Nie ein Feld für die Antwortzeit ergänzen, sodass die Ursache einer Verlangsamung unbekannt bleibt
Server-Logs zeigen eine Website ehrlicher als jedes Analytics-Dashboard; jede Anfrage, echt oder Bot, ist dort verzeichnet. Eine wöchentliche Zehn-Minuten-Gewohnheit fängt viele Probleme ab, bevor sie zu einer Kundenbeschwerde werden. In einem Erstgespräch mit rabbitclip lassen sich die eigenen Server-Logs gemeinsam durchgehen.
Häufige Fragen
Braucht man ein spezielles Werkzeug, um Log-Dateien zu lesen?
Für eine kleine Website reicht es, eine reine Textdatei über die Kommandozeile zu filtern. Mit wachsendem Traffic erleichtert ein Log-Analyse-Tool die Arbeit.
Ist ein 404-Fehler immer ein Problem?
Nein. Ein Bot, der eine zufällige, nie existierte Adresse ausprobiert, ist normal; das eigentliche Problem ist ein defekter Link, auf den echte Besucher immer wieder stoßen.
Lässt sich Bot-Traffic vollständig blockieren?
Nicht vollständig, aber bekannte bösartige Verhaltensmuster lassen sich auf Server- oder CDN-Ebene weitgehend blockieren.
Ist der Server immer die Ursache für eine langsame Anfrage?
Nein. Langsamkeit kann von einer Datenbankabfrage, einer externen Integration oder einem großen Bild kommen; das Log zeigt nur, wo es langsam wird, die Ursache muss zusätzlich untersucht werden.
Lässt sich statt zeilenweisem Lesen eine schnelle Übersicht erstellen?
Ja. Ein einfacher Befehl, der nach Statuscode oder IP-Adresse zählt und sortiert, zeigt den häufigsten Fehler oder eine ungewöhnliche Bot-Quelle, ohne jede Zeile zu lesen.
