Log-Analyse bei Legacy-Systemen: Wie man aus Serverprotokollen lernt
Ihr Legacy-System läuft seit Jahren stabil. Die Dokumentation ist dünn, der letzte Entwickler hat die Firma längst verlassen. Was im Betrieb wirklich passiert, weiß niemand mehr genau. Dabei führt Ihr Server Tagebuch: in seinen Logs. Die Log-Analyse bei Legacy-Systemen ist darum oft die verlässlichste Quelle für echtes Systemwissen. Manchmal ist sie die einzige.
Ein Log ist eine Protokolldatei. Der Server schreibt dort jede Anfrage und jeden Fehler mit, samt Zeitstempel. Sie können sich das wie einen Kontoauszug vorstellen. Jede Bewegung steht drin, auch die unangenehmen. Dieser Artikel zeigt, wie Sie solche Server-Logs auswerten, ohne teure Werkzeuge zu kaufen. Und wie aus einer einmaligen Auswertung eine dauerhafte Wartungsroutine wird.
Warum Logs bei Legacy-Systemen so wertvoll sind
Bei aktueller Software liefern Tests, Metriken und Dokumentation ein Bild vom Systemverhalten. Bei gewachsenen Systemen fehlt davon vieles. Die Logs füllen diese Lücke. Sie zeigen, welche Funktionen tatsächlich genutzt werden und welche Fehler sich wiederholen. Außerdem dokumentieren sie, wer von außen an Ihrem System rüttelt.
Ein typisches Beispiel: Ein Betreiber will ein altes Exportmodul abschalten. Niemand nutzt es, glaubt man im Haus. Das Access-Log zeigt etwas anderes. Ein wichtiger Kunde ruft die Schnittstelle jede Nacht automatisch auf. Die Abschaltung hätte eine Geschäftsbeziehung beschädigt. Aufgefallen ist das nur durch einen Blick ins Log.
Solche Erkenntnisse stecken in fast jedem Protokoll. Man muss sie nur heben. Dafür braucht es keine Spezialsoftware, sondern ein wenig Systematik und Regelmäßigkeit.
Die Nutzungsdaten helfen auch bei Entscheidungen. Welche Bereiche der Anwendung ruft überhaupt noch jemand auf? Welche Kunden hängen an welcher Schnittstelle? Wer eine Modernisierung plant, priorisiert mit diesen Zahlen deutlich sicherer. Aus Vermutungen werden belegbare Fakten.
Was passiert, wenn niemand hinschaut
Unbeobachtete Logs kosten Geld, nur eben verzögert. Vier Folgen sehen wir immer wieder.
Fehler bleiben monatelang unbemerkt. Nutzer melden einen Defekt selten. Sie weichen aus, versuchen es später erneut oder geben auf. Im Error-Log stünde der Fehler ab dem ersten Tag, mit Uhrzeit und Ursache.
Angriffe fallen nicht auf. Automatisierte Scanner klopfen jeden Tag bekannte Schwachstellen ab. Wie Sie solche Lücken im Blick behalten, beschreibt unser Artikel zum CVE-Monitoring bei Legacy-Software. Ohne Blick ins Log merken Sie von diesen Versuchen nichts.
Die Festplatte läuft voll. Logdateien ohne Begrenzung wachsen über Jahre still vor sich hin. Irgendwann steht die Anwendung, gern nachts am Wochenende. Ausgerechnet die Protokolle, die helfen sollen, verursachen dann den Ausfall.
Nach einem Vorfall fehlen Beweise. Die DSGVO (Datenschutz-Grundverordnung) verlangt bei Datenpannen eine Meldung binnen 72 Stunden. Wer keine Protokolle hat, kann weder Umfang noch Ursache belegen. Das macht aus einem technischen Vorfall ein rechtliches Problem.
Die wichtigsten Log-Quellen und was sie verraten
Access-Log und Error-Log des Webservers
Apache und Nginx schreiben zwei zentrale Dateien. Das Access-Log hält jede einzelne HTTP-Anfrage fest: Absender-IP, Uhrzeit, aufgerufene Adresse, Statuscode. Statuscodes sind dreistellige Antwortcodes des Servers. 200 heißt Erfolg, 404 heißt nicht gefunden, 500 heißt Serverfehler. Das Error-Log sammelt dagegen Probleme des Servers selbst, etwa Konfigurationsfehler oder abgestürzte Prozesse. Wie beide Webserver in alten PHP-Umgebungen zusammenspielen, erklärt unser Beitrag zu Apache und Nginx bei Legacy-PHP.
Das PHP-Error-Log
PHP protokolliert eigene Fehler getrennt vom Webserver. Ein Fatal Error bedeutet: Das Skript bricht ab, der Nutzer sieht eine weiße Seite. Warnungen und Deprecated-Hinweise sind harmloser, aber wertvoll. Deprecated heißt: Diese Funktion verschwindet in einer künftigen PHP-Version. Solche Meldungen zeigen früh, wo ein späteres PHP-Upgrade haken wird. Das PHP-Error-Log ist damit auch ein Planungsinstrument, nicht bloß eine Fehlerliste.
Systemlogs, Cronjobs und Datenbank
Ein Cronjob ist eine zeitgesteuerte Aufgabe, etwa das nächtliche Backup. Scheitert er, erfährt das oft niemand. Die Meldung landet nur im Systemlog oder in einem Postfach, das keiner mehr liest. Prüfen Sie deshalb auch syslog beziehungsweise journalctl. Einen Blick wert ist zudem das Slow-Query-Log der Datenbank. Dort stehen die Abfragen, die Ihre Anwendung langsam machen.
So werten Sie Server-Logs systematisch aus
Schritt 1: Logs finden und prüfen, ob sie geschrieben werden
Übliche Orte sind /var/log/apache2, /var/log/nginx und der Pfad aus der PHP-Einstellung error_log. Kontrollieren Sie zuerst das Datum der Dateien. Bei manchen Altsystemen wurde das Logging irgendwann abgeschaltet, oft wegen Platzmangel. Ein Server, der nichts protokolliert, wirkt nur gesund. Notieren Sie außerdem, welche Anwendung in welche Datei schreibt. Diese Übersicht fehlt bei alten Servern fast immer und ist schnell erstellt.
Schritt 2: Muster suchen statt Einzelfälle lesen
Niemand liest zehntausende Zeilen von Hand. Zählen Sie stattdessen. Zwei Beispiele mit Bordmitteln:
grep " 500 " access.log | wc -l
awk '{print $1}' access.log | sort | uniq -c | sort -rn | head
Der erste Befehl zählt Serverfehler. Der zweite listet die IP-Adressen mit den meisten Anfragen. Häufen sich Fehler direkt nach einem Update, ist die Ursache fast gefunden. Tausende Login-Versuche von einer einzigen IP sind ein Brute-Force-Angriff, also automatisiertes Passwortraten. Viele 404-Treffer auf Pfade wie /wp-admin stammen von Scannern, die Standardlücken suchen. Auch die Geschwindigkeit lässt sich ablesen. Apache und Nginx können die Antwortzeit jeder Anfrage mitschreiben. Damit finden Sie die Seiten, auf die Ihre Nutzer am längsten warten. Wie Sie von so einem Muster zur eigentlichen Ursache kommen, zeigt unsere Anleitung zur Störungsanalyse bei Legacy-Software.
Schritt 3: Rotation und Aufbewahrung regeln
Log-Rotation bedeutet: Alte Protokolle werden regelmäßig komprimiert und nach einer Frist gelöscht. Das Werkzeug logrotate erledigt das automatisch. Ohne Rotation frisst das Log die Festplatte. Mit zu knapper Rotation fehlt nach einem Vorfall die Historie. Bewährt haben sich, je nach Zweck, 14 bis 90 Tage. Bedenken Sie dabei die DSGVO: IP-Adressen gelten als personenbezogene Daten. Die Aufbewahrung braucht also einen dokumentierten Zweck und ein Ablaufdatum.
Schritt 4: Aus der Analyse eine Routine machen
Eine einmalige Log-Analyse ist eine Momentaufnahme. Ihr Wert entsteht durch Wiederholung. Ein fester Log-Review pro Monat reicht bei vielen Systemen schon aus. Ergänzend lohnt ein automatischer Alarm, wenn Fehler sich plötzlich häufen. Warum dauerhafte Beobachtung gerade bei Altsystemen zählt, begründet unser Artikel zum Monitoring von Legacy-Software. Bei unseren Kunden gehört der Blick in die Logs deshalb fest zur monatlichen Software-Wartung.
Fazit: Ihre Logs wissen mehr als Ihre Dokumentation
Die Log-Analyse bei Legacy-Systemen kostet wenig und deckt viel auf: schleichende Fehler, laufende Angriffe, vergessene Schnittstellen. Gerade wenn Dokumentation fehlt, sind die Protokolle das Gedächtnis des Betriebs. Was sich dort über Jahre angesammelt hat, erzählt die ehrliche Geschichte Ihrer Anwendung.
Sie möchten wissen, was in Ihren Logs steht? Wir übernehmen die erste Auswertung, richten Rotation und Alarme ein und machen daraus eine feste Routine. Sprechen Sie uns an. Das Erstgespräch ist kostenlos.
