Klare Sicht in Ihren Tech-Stack mit Logging Best Practices

Logs sind Ihr wichtigster „Newsticker“, wenn es um Insights zur Entwicklung und zu allen operativen Aspekten Ihrer Anwendungen und Services geht – ihr effektiver Einsatz vorausgesetzt. Denn einfach nur massenweise Log-Daten in einer Datenbank oder Datei anzuhäufen ist damit keinesfalls gemeint. 

Vielmehr braucht es eine klare Struktur. Denn erst so lassen sich die Vorgänge in komplexen Systemen präzise nachvollziehen und Potenziale für Performance-Steigerungen ebenso punktgenau identifizieren wie Fehlerursachen. Die Konfiguration von Logs für den Gesamt-Stack gestaltet sich jedoch recht schnell als komplexes Unterfangen, bei dem Unachtsamkeiten zudem blinde Flecken nach sich ziehen können. Was genau soll erfasst werden? Welche Details sind wichtig? Führen zu viele Daten auch zu exorbitanten Kosten?  

All diese Fragen beantworten wir im Folgenden anhand von Best Practices, mit denen Sie optimale Visibility für Ihren Stack erhalten, Troubleshooting-Prozesse beschleunigen und Klarheit über die UX gewinnen.

Umfang der Log-Erfassung

In einem Log werden Event-Daten zu Software-Anwendungen, Betriebssystemen und Infrastruktur-Komponenten als Text in einem Standard-Ausgabeformat oder einer Datei gespeichert. Neben Timestamps enthalten sind dabei etwa Fehlermeldungen, Stack-Traces und andere Datenpunkte, die Aufschluss über Event-Zeitpunkte und -Ursachen geben.

Damit ist ein enormes Potenzial verbunden – sofern Sie in Ihren Logs auch das Richtige erfassen. Im Speziellen betrifft dies Metadaten. Von ihnen sollten so viele wie erforderlich enthalten sein, um Events und Fehlerursachen genau ausmachen zu können.

Entscheidend ist, dass die Log-Daten direkt gewinnbringend für Ihre Team nutzbar sind, also etwa Insights zu Auslastung, benutzerbezogenen Events oder Anwendungsfehlern und -ausnahmen liefern. Ebenso wichtig sind hierbei Details, die bei der Rekonstruktion von Problemketten helfen und so zu effektiven Entscheidungen beitragen.

Planung entsprechend häufiger Szenarien 

Logs erleichtern nicht nur die Behebung von Problemen, sondern sind auch äußerst nützlich für allgemeine Stack-Analysen zu Performance-Profilen oder statistischen Datenpunkten. 

Deshalb gilt es, bei ihrer Konfiguration häufige Szenarien als Grundlage für die Wahl der zu erfassenden Daten heranzuziehen. So ermöglichen etwa detaillierte Anwendungs-Logs Insights zu Performance und potenziellen Problemen wie Speicherlecks. Damit erhalten Sie aufschlussreiche Details zur UX, die andere Daten zu benutzerseitigen Interaktionen nicht liefern können.

All diese Informationen sind potenziell wichtig für Ihre Entscheidungsfindung. Welche davon Sie im Einzelnen erfassen sollten, richtet sich nach dem jeweiligen Szenario.

Erfassung entscheidungsrelevanter Meldungen  

Der Nutzen von Log-Meldungen hängt ganz davon ab, ob sie zielführend in Entscheidungen überführt werden können. Von externen Anbietern entwickelte Infrastruktur erfasst in der Regel Informationen mit einem hohen Detailgrad. Bei Software-Anwendungen verhält es sich dagegen etwas anders. Hier gilt es zu prüfen, ob Sie auch wirklich genau die Details festhalten, die zur Diagnose von Fehlern oder anderen Events sowie zur Bestimmung adäquater Maßnahmen nötig sind.   

Bei Anwendungsfehlern müssen Log-Meldungen stichhaltig vermitteln, was genau in der Code-Zeile vor sich geht. 

So sollte beispielsweise die Meldung zu einem Transaktionsfehler in etwa wie folgt lauten: 

Transaktion fehlgeschlagen: Benutzer konnte nicht erstellt werden ${path/to/file:line-number}

Aus dieser Meldung ist nicht nur die Fehlerursache leicht erkennbar, sondern auch die zu prüfende Code-Zeile. 

Eine kurze Beschreibung, die den Text oder die Nummer zum Fehlercode im Log ergänzt, verhilft Ihren Teams dabei zu einer schnelleren Behebung des Problems.
 

Einfache, kompakte Struktur 

Sicher sollte eine Meldung ausreichende Informationen enthalten. Eine Überladung an Details gilt es aber zu vermeiden.

Denn Hinweise ohne echten Mehrwert treiben Speicheranforderungen schnell in die Höhe und verlangsamen Suchabläufe. Der Fehlerbehebung stehen sie also eher im Wege. Log-Meldungen sollten wichtige Informationen in kompakter Form liefern, die dazu erfassten Daten daher auf das Wesentliche beschränkt sein.

Beim Log-Format ist darauf zu achten, dass Informationen zur Fehlerursache nicht jedes noch so kleine Umgebungsdetail enthalten. So gilt es bei API-Ausfällen etwa, sämtliche Fehlermeldungen der betroffenen API einzubeziehen. Details zum zugehörigen Anwendungsspeicher dagegen können getrost vernachlässigt werden.

Die Zeit zählt mit

Auch darf der Timestamp in keiner Log-Meldung fehlen. Der Tracking-Turnus hängt dabei von der Frequenz der jeweiligen Aufgabe ab. Wichtig ist aber stets, dass er in sämtlichen Logs erfasst wird. Bei einigen Aufgaben kann es nötig sein, die Zeit auf die Millisekunde genau auszuweisen, bei anderen dagegen womöglich nur auf die Minute, die Stunde oder auf den Tag. 

Am besten legen Sie in diesem Zusammenhang Standards für Ihren Gesamt-Stack oder Ihren Funktionsbereich zugrunde, nach denen Sie Ihre Logs mit anderen Telemetrie-Datentypen wie Metrics und Events korrelieren. 

Leicht verständliches Format

Zentral ist freilich der Informationsgehalt von Log-Meldungen. Doch zugleich müssen sie einfach lesbar sein, damit entscheidungsrelevante Insights direkt ersichtlich sind. Meldungen mit breitem Interpretationsspielraum und ohne Hintergrunddetails sind daher zu vermeiden, werden sie so doch nur von wenigen Teammitglieder verstanden. Wichtige Kriterien sind zudem einfaches Parsing und eine konsistente Struktur, damit die Logs problemlos erfasst und aggregiert werden können. Mit dem Toolset für Log-Management von New Relic etwa lassen sich mühelos Custom-Regeln zum Parsing definieren. Doch diese setzen noch immer voraus, dass die Logs in einer lesbaren Struktur vorliegen. 

Beispiele zur Log-Formatierung

Logs sind Ihr wichtigster „Newsticker“, wenn es um Insights zur Entwicklung und zu allen operativen Aspekten Ihrer Anwendungen und Services geht – ihr effektiver Einsatz vorausgesetzt. Denn einfach nur massenweise Log-Daten in einer Datenbank oder Datei anzuhäufen ist damit keinesfalls gemeint. 

Vielmehr braucht es eine klare Struktur. Denn erst so lassen sich die Vorgänge in komplexen Systemen präzise nachvollziehen und Potenziale für Performance-Steigerungen ebenso punktgenau identifizieren wie Fehlerursachen. Die Konfiguration von Logs für den Gesamt-Stack gestaltet sich jedoch recht schnell als komplexes Unterfangen, bei dem Unachtsamkeiten zudem blinde Flecken nach sich ziehen können. Was genau soll erfasst werden? Welche Details sind wichtig? Führen zu viele Daten auch zu exorbitanten Kosten?  

All diese Fragen beantworten wir im Folgenden anhand von Best Practices, mit denen Sie optimale Visibility für Ihren Stack erhalten, Troubleshooting-Prozesse beschleunigen und Klarheit über die UX gewinnen.

Umfang der Log-Erfassung

In einem Log werden Event-Daten zu Software-Anwendungen, Betriebssystemen und Infrastruktur-Komponenten als Text in einem Standard-Ausgabeformat oder einer Datei gespeichert. Neben Timestamps enthalten sind dabei etwa Fehlermeldungen, Stack-Traces und andere Datenpunkte, die Aufschluss über Event-Zeitpunkte und -Ursachen geben.

Damit ist ein enormes Potenzial verbunden – sofern Sie in Ihren Logs auch das Richtige erfassen. Im Speziellen betrifft dies Metadaten. Von ihnen sollten so viele wie erforderlich enthalten sein, um Events und Fehlerursachen genau ausmachen zu können.

Entscheidend ist, dass die Log-Daten direkt gewinnbringend für Ihre Team nutzbar sind, also etwa Insights zu Auslastung, benutzerbezogenen Events oder Anwendungsfehlern und -ausnahmen liefern. Ebenso wichtig sind hierbei Details, die bei der Rekonstruktion von Problemketten helfen und so zu effektiven Entscheidungen beitragen.

Planung entsprechend häufiger Szenarien 

Logs erleichtern nicht nur die Behebung von Problemen, sondern sind auch äußerst nützlich für allgemeine Stack-Analysen zu Performance-Profilen oder statistischen Datenpunkten. 

Deshalb gilt es, bei ihrer Konfiguration häufige Szenarien als Grundlage für die Wahl der zu erfassenden Daten heranzuziehen. So ermöglichen etwa detaillierte Anwendungs-Logs Insights zu Performance und potenziellen Problemen wie Speicherlecks. Damit erhalten Sie aufschlussreiche Details zur UX, die andere Daten zu benutzerseitigen Interaktionen nicht liefern können.

All diese Informationen sind potenziell wichtig für Ihre Entscheidungsfindung. Welche davon Sie im Einzelnen erfassen sollten, richtet sich nach dem jeweiligen Szenario.

Erfassung entscheidungsrelevanter Meldungen  

Der Nutzen von Log-Meldungen hängt ganz davon ab, ob sie zielführend in Entscheidungen überführt werden können. Von externen Anbietern entwickelte Infrastruktur erfasst in der Regel Informationen mit einem hohen Detailgrad. Bei Software-Anwendungen verhält es sich dagegen etwas anders. Hier gilt es zu prüfen, ob Sie auch wirklich genau die Details festhalten, die zur Diagnose von Fehlern oder anderen Events sowie zur Bestimmung adäquater Maßnahmen nötig sind.   

Bei Anwendungsfehlern müssen Log-Meldungen stichhaltig vermitteln, was genau in der Code-Zeile vor sich geht. 

So sollte beispielsweise die Meldung zu einem Transaktionsfehler in etwa wie folgt lauten: 

Transaktion fehlgeschlagen: Benutzer konnte nicht erstellt werden ${path/to/file:line-number}

Aus dieser Meldung ist nicht nur die Fehlerursache leicht erkennbar, sondern auch die zu prüfende Code-Zeile. 

Eine kurze Beschreibung, die den Text oder die Nummer zum Fehlercode im Log ergänzt, verhilft Ihren Teams dabei zu einer schnelleren Behebung des Problems.
 

Einfache, kompakte Struktur 

Sicher sollte eine Meldung ausreichende Informationen enthalten. Eine Überladung an Details gilt es aber zu vermeiden.

Denn Hinweise ohne echten Mehrwert treiben Speicheranforderungen schnell in die Höhe und verlangsamen Suchabläufe. Der Fehlerbehebung stehen sie also eher im Wege. Log-Meldungen sollten wichtige Informationen in kompakter Form liefern, die dazu erfassten Daten daher auf das Wesentliche beschränkt sein.

Beim Log-Format ist darauf zu achten, dass Informationen zur Fehlerursache nicht jedes noch so kleine Umgebungsdetail enthalten. So gilt es bei API-Ausfällen etwa, sämtliche Fehlermeldungen der betroffenen API einzubeziehen. Details zum zugehörigen Anwendungsspeicher dagegen können getrost vernachlässigt werden.

Die Zeit zählt mit

Auch darf der Timestamp in keiner Log-Meldung fehlen. Der Tracking-Turnus hängt dabei von der Frequenz der jeweiligen Aufgabe ab. Wichtig ist aber stets, dass er in sämtlichen Logs erfasst wird. Bei einigen Aufgaben kann es nötig sein, die Zeit auf die Millisekunde genau auszuweisen, bei anderen dagegen womöglich nur auf die Minute, die Stunde oder auf den Tag. 

Am besten legen Sie in diesem Zusammenhang Standards für Ihren Gesamt-Stack oder Ihren Funktionsbereich zugrunde, nach denen Sie Ihre Logs mit anderen Telemetrie-Datentypen wie Metrics und Events korrelieren. 

Leicht verständliches Format

Zentral ist freilich der Informationsgehalt von Log-Meldungen. Doch zugleich müssen sie einfach lesbar sein, damit entscheidungsrelevante Insights direkt ersichtlich sind. Meldungen mit breitem Interpretationsspielraum und ohne Hintergrunddetails sind daher zu vermeiden, werden sie so doch nur von wenigen Teammitglieder verstanden. Wichtige Kriterien sind zudem einfaches Parsing und eine konsistente Struktur, damit die Logs problemlos erfasst und aggregiert werden können. Mit dem Toolset für Log-Management von New Relic etwa lassen sich mühelos Custom-Regeln zum Parsing definieren. Doch diese setzen noch immer voraus, dass die Logs in einer lesbaren Struktur vorliegen. 

Beispiele zur Log-Formatierung

Die beiden Logs enthalten exakt dieselben Informationen; beim ersten jedoch nicht gegliedert und entsprechend schlecht lesbar. Im zweiten haben Sie dagegen alle Details direkt im Blick, ohne erst den ganzen Log durchgehen zu müssen. Zudem lassen sich Anwendungs-Logs mit einer standardisierten Formatierung wie dieser mühelos parsen und so zur Nutzung auf verschiedenen Plattformen erfassen.

In punkto Logging gibt es also einiges zu beachten. Wenn Sie sich aber an die hier ausgeführten Empfehlungen halten, können Sie Kostensenkungen realisieren, Fehlerursachen schneller ausmachen und nicht zuletzt auch wertvolle Zeit etwa im Bereitschaftsdienst einsparen.