Mittlerweile stehen viele hochwertige Open-Source-Anwendungen für eure Onlineauftritte oder Onlinezusammenarbeit zur Verfügung. Auch wenn sich Entwickler*innen große Mühe geben eine tolle Software zu schreiben, so schleichen sich doch immer wieder Fehler ein. Ebenso können sich im Zusammenspiel zwischen Anwendung und eigenem Server Probleme auftun, die einer Lösung bedürfen. Vor der Lösung steht jedoch die Fehlersuche: Oft lässt sich nicht per Augenschein erkennen, woran es hakt. Im Folgenden geben wir ein paar Tipps, wie ihr euch dem Problem nähert.
Die Log-Datei ist dein Freund!
Glücklicherweise werdet ihr bei der Fehlersuche von der Software aktiv unterstützt. Die meisten Anwendungen und auch die Server selbst legen verschiedene Protokoll-Dateien an. In diesen wird aufgezeichnet, welche Aktionen stattgefunden haben bzw. bei welchen Aktionen unvorhergesehene Ereignisse auftraten. Aus unserer Erfahrung lohnt es sich bei Problemen im ersten Schritt die Log-Dateien der betroffenen Anwendung anzusehen. Die meisten Fehler lassen sich hierüber bereits eingrenzen.
Log-Dateien werden fast immer als Dateien mit der Endung .log angelegt. Es handelt sich dabei aber in der Regel um Textdateien, die sich mit jedem beliebigen Editor öffnen lassen (Notepad, Wordpad, usw.).
In den Logs der Anwendungen wird in der Regel protokolliert, wenn einzelne Funktionen oder Programmbibliotheken eine Aufgabe nicht ausführen konnten. Das könnte z.B. daran liegen, dass Zugriffsrechte nicht korrekt gesetzt waren, benötigte Dateien nicht gefunden wurden, ein Datenbankserver nicht oder nicht schnell genug geantwortet hat, oder Funktionen schlichtweg Fehler hatten (Beispiel: Versuch durch 0 zu teilen). Dennoch können sich die Inhalte der Log-Dateien bisweilen sehr unterscheiden – die Entwickler*innen können sich dafür entscheiden, nicht nur fatale Fehler zu vermerken, sondern auch bereits Warnmeldungen oder auch erfolgreich durchgeführte Aktivitäten. Letzteres kann zwar von Interesse für die Entwickler*innen sein, allerdings im Dauerbetrieb auch mit Datenschutzerfordernissen kollidieren. Daher lassen sich Anwendungen häufig darauf konfigurieren, ob sie sich im Betriebsmodus für „Entwicklung“ (development, debug modus) oder für „Produktion“ befinden.
Anhand von vier Anwendungen möchten wir euch beispielhaft aufzeigen, wo Log-Dateien zu finden sind:
Antragsgrün: Die Software zur demokratischen Texterstellung führt eine Log-Datei unter /runtime/logs/app.log. Die Einträge sind dabei sehr ausführlich gehalten.
ePartool: Das DBJR-Konsultationswerkzeug führt eine Log-Datei unter /runtime/logs/application.log. Die neuesten Einträge finden sich ganz unten.
Nextcloud: Die populäre Open-Source-Plattform für Dateiaustausch und Zusammenarbeit führt zwei unterschiedliche Log-Dateien. Während die Datei /data/updater.log nur über Installationsvorgänge Buch führt, ist die Datei /data/nextcloud.log für den täglichen Betrieb gedacht. Nextcloud beinhaltet zudem eine Zugriffsmöglichkeit auf diese Log-Datei über das Admin-Backend. Hier kann man auch einstellen, welche Art von Fehlern oder Problemhinweisen protokolliert werden sollen.
WordPress: In der Standardinstallation führt das CMS keine Log-Datei. Durch zwei Einträge in der Datei wp-config.php kann das Loggen aber aktiviert werden:
define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
Weitere Informationen finden sich unter https://codex.wordpress.org/Debugging_in_WordPress.
Wenn man Log-Dateien über das administrative Backend betrachten und auswerten möchte, muss zudem ein Plugin installiert werden, z.B. der »Error Log Monitor« [https://de.wordpress.org/plugins/error-log-monitor/]
Weitere Log-Dateien
Gelegentlich helfen die Log-Dateien der Anwendungen aber nicht weiter. Das kann daran liegen, dass die Anwendung auf Probleme stößt, die außerhalb ihrer eigenen Analysemöglichkeit liegen. Im Extremfall wäre das bei einem Hardware-Defekt der Fall: Ob alle Kabel richtig stecken oder ob der Servercomputer selbst richtig rechnet, kann eine Anwendung kaum erkennen. Auf Log-Dateien der Betriebssystem-Ebene hat man jedoch in der Regel als Mieter*in eines Webhostings keinen Zugriff. Professionelle Provider stellen durch Überwachungsprogramme sicher, dass diese Art von Fehlern von ihnen selbst zeitnah entdeckt werden.
Zwischen dem Betriebssystem und Anwendungen wie den vier oben genannten liegt allerdings noch die installierte Web-Server-Software. Ein Web-Server ist meist als Sammelbegriff mehrerer Programme zu verstehen und beinhaltet neben dem eigentlichen Web-Server-Programmen wie Apache oder Nginx auch die PHP-Programmiersprache oder eine Datenbank). Diese alle führen ebenfalls Log-Dateien.
Welche Log-Datei hilft wann:
Web-Server: Hier werden der Zeitpunkt und die Herkunft der Zugriffe (IP-Adressen), Größe der abgerufenen Dateien und Statusmeldungen zu den einzelnen Verbindung geloggt. So lässt sich schnell herausfinden, ob es zeitgleich übermäßig viele Zugriffe gab (und daher der Server sehr langsam wurde) oder ob bestimmte Dateien nicht gefunden wurden (die bekannte Statusmeldung 404). Probleme im internen Programmablauf, die nicht die Zugriffe betreffen, werden meistens in einer separaten Log-Datei protokolliert.
PHP: Programmierfehler sind häufig kleine Tippfehler, wie eine vergessene Klammer zum Abschluss einer Funktion oder ein Buchstabendreher. Wenn der PHP-Interpreter nicht versteht, was er zu tun hat, können diese Fehler entweder geloggt oder direkt angezeigt werden. Letzteres hilft zwar, Fehler schnell zu finden, verrät aber Externen auch viel über mögliche Angriffspunkte. Bei PHP-Skripten kann man auch ohne viel Programmiererfahrung das Anzeigen von Fehlern aktivieren, indem man in die ersten Zeilen (nach dem Startkennzeichen <?php) folgende Befehle ergänzt:
error_reporting(E_ALL);
ini_set('display_errors', '1');
Voraussetzung dafür, dass nun konkrete Fehlermeldungen angezeigt werden, ist, dass der Server grundsätzlich dazu konfiguriert ist. Bei den meisten Providern lässt sich das im Administrationsmenü aktivieren und wieder deaktivieren. Bei direktem Server-Zugang und Schreibrechten auf die php.ini-Einstellungsdatei lässt sich dies durch display_errors = on aktivieren.
Datenbank: Da es verschiedene weit verbreitete Datenbanken gibt, fällt die Erkenntnismöglichkeit hier sehr unterschiedlich aus. General lässt sich über die Log-Datei herausfinden, ob der Service korrekt gestartet wurde, ob es gescheiterte Zugriffsversuche gab (z.B. wenn die Zugangspasswörter in der zugreifenden Anwendung falsch abgespeichert waren). Möglicherweise kann man über die Statusmitteilungen auch herausfinden, ob Datenbank-Anfragen ineffizient gestellt wurden und daher sehr lange zur Beantwortung brauchten oder gar komplett scheiterten. Dies könnte z.B. der Fall sein, wenn Suchindizes nach größeren Datenveränderungen nicht neu angelegt wurden oder durch zu viele parallel Schreibvorgänge versucht wurden. Auch der Ursprung von fehlerhafte Zeichenausgabe (Umlaute oder falsche Symbole) könnte hier liegen: Die Kette der Zeichenkodierung muss von der Datenbankablage über die Verbindung und Verarbeitung bei der Anwendung bis hin zum Browser bei den Nutzer*innen durchgehend richtig sein.
Der Einfluss von Fehler-Logs auf die Rechenzeit
Das Erstellen von Log-Dateien benötigt immer etwas Rechenzeit. Diese fällt umso größer aus, wenn man sich auf einem höheren Software-Level befindet (System → Server-Software → Anwendung). Daher lohnt es sich bei viel frequentierten Internet-Angeboten, im stabilen Betrieb das Logging durch die Anwendungen soweit wie möglich zu reduzieren.