Fürs Protokoll: Worauf es beim Logging ankommt

Inhaltsverzeichnis

Was man nicht im Kopf hat, hat man in den Beinen. Bezogen auf die Softwareentwicklung könnte die alte Weisheit umgemünzt werden in: Was man nicht im Log hat, hat man auf dem Überstundenzettel. Der Entwickler Eliran Turgeman greift das Thema aktuell in einem neuen Blogbeitrag auf und stößt damit in Entwickler-Communitys die Diskussion darüber an, wie gute Softwareprotokolle aussehen sollten.

Logging – so ist es von Leuten aus der Praxis zu hören – zählt nicht gerade zu den beliebtesten Arbeitsschritten vieler Entwickler. Für sie ist das Protokollieren in etwa so attraktiv wie das Abheften von Dokumenten und Rechnungen in einen Aktenordner – eine Formalie, die nicht unmittelbar einen Nutzen entfaltet. Schließlich läuft die App oder die Software ja auch so.

Wenn aber die App dann plötzlich hakt, kann sich ein gutes Logging bezahlt machen. Dann können die Logeinträge die Steinchen sein, über die jemand, der sich im Wald verlaufen hat, wieder nach draußen findet. Logs sind laut Experten aber auch nützlich, um die Wege der Nutzerinnen und Nutzer zu ergründen – also um etwa eine Software zu verbessern, weil der vom Entwickler gedachte Weg vielleicht gar nicht der ist, der in der Praxis genutzt wird.

Und das Logging lohne sich auch, wenn Entwickler-Teams wachsen und neue Kolleginnen und Kollegen eingeführt werden. Die Neuzugänge finden dann schneller hinein. Der vermeintlich nervige Zeitaufwand zahle sich spätestens aus, wenn dann beim Beheben von Fehlern wertvolle Zeit gespart werden kann, weil viele Informationen schon vorliegen.

Hier einige Tipps und Denkanstöße von Entwicklern:

Nicht zu viel, nicht zu wenig

Eliran Turgeman rät in seinem Blogpost dazu, zu hinterfragen, ob wirklich alle Informationen benötigt werden. Loggen nur um des Loggens willen mache die Protokolle schnell unleserlich und im Bedarfsfall nutzlos.

Der Nutzwert einer Information hängt allerdings auch davon ab, wer die Logs eigentlich liest, gibt Brice Figureau zu bedenken: Sind es nur die Entwickler? Richten sich Logs an Systemadministratoren? Oder begibt sich gar der Anwender selbst manchmal auf Fehlersuche? Jede dieser Gruppen benötigt ganz unterschiedliche Informationen oder versteht Angaben manchmal auch gar nicht.

Entwickler sollten sich auch fragen, wie viele Logeinträge im Alltag entstehen. Bei viel genutzten Apps oder Diensten können leicht riesige Datenmengen entstehen, die später auch kaum noch zu überblicken sind. Hier ist Minimalismus sicher noch eher anzuraten als bei einer kleinen Softwarelösung, die selten genutzt wird. Diese Punkte sollten Berücksichtigung finden, wenn es darum geht, den optimalen Mittelweg zwischen ausreichend vielen Informationen und einem drohenden Überfluss zu finden.

Standards schaffen und einhalten

Eliran Turgeman rät dazu, konsistent zu loggen. Für Alleinentwickler ist das relativ einfach, in Teams muss man sich organisieren, damit das klappt. Andre Rabold, Entwickler und CTO, rät in einem Blogbeitrag dazu, Standards zu setzen und idealerweise auch für alle zu dokumentieren. So finden auch Neuzugänge in einem Team schneller rein. Grundsätzlich rät er auch dazu, Logging zum Teil der täglichen Arbeit zu machen und diesen Punkt im Alltag immer mitzudenken, anstatt später erst für eine Protokollierung zu sorgen.

Brice Figureau empfiehlt, vorhandene Log-Librarys zur Protokollierung zu verwenden und nicht in eine eigene Dateiverwaltung für Logs einzusteigen. Protokolle sollten außerdem mit Blick auf internationale Teams oder Nutzer im Ausland idealerweise in Englisch verfasst werden.

So sollten Logeinträge aussehen

Keiner mag Fehlermeldungen, die aus dem einen Satz bestehen, dass ein Fehler aufgetreten ist. Da Logging vielfach unter der Motorhaube einer App stattfindet und nicht unbedingt die Augen der Nutzer erreicht, begnügen sich einige Entwickler mit sehr schlichten Protokolleinträgen. Was während der Entwicklung zum Nachvollziehen eines einzelnen Schritts genügen mag, wird zum Problem, wenn es Teil eines größeren Logs mit vielen anderen Einträgen ist. Logeinträge sollten also mehr Aussagekraft besitzen.

Ein Tipp, den fast alle Experten nennen, ist, Protokolleinträge zu klassifizieren. Logging Levels können etwa "Fehler" (für Abstürze/Abbrüche), "Warnung" (für ein unerwartetes Verhalten, das zum Problem werden könnte), "Info" (für Ereignisse) sowie "Debug" (detailliertere Angaben zum Ereignis) heißen.

Andre Rabold hält es für wichtig, Zeitstempel im UTC-Format (wegen der Zeitzonen) und die Quelle der Ereignisse (Klasse, Funktion, Dateinamen) zu benennen. Logs sollten maschinenlesbar sein und dennoch auch für Menschen gut einsehbar bleiben. Wer Inspiration sucht, kann sich zum Beispiel das Common Log Format zum Vorbild nehmen:

127.0.0.1 user-identifier test [18/Jan/2023:13:22:46 +0200] "GET /index.html HTTP/1.0" 200 2326

Sensible Informationen wie Passwörter oder persönliche Daten haben in Logfiles nichts zu suchen, warnt Brice Figureau.

(mki)