Logs sind Ihr wichtigster „Newsticker“, wenn es um Infos zur Entwicklung und zu allen operativen Aspekten Ihrer Anwendungen und Services geht. Dazu müssen Logs allerdings effektiv eingesetzt werden – die pure Anhäufung von Logdaten in einer Datenbank oder Datei ist damit nicht gemeint.
Vielmehr ist eine klare Logstruktur nötig. 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.
Das Leid mit dem Log-Management
Die Konfiguration von Logs für den Gesamt-Stack gestaltet sich 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?
Ein hohes Logvolumen kann ebenfalls für Kopfschmerzen sorgen, aber das Ganze lässt sich durchaus entwirren. Dabei kann ein gutes Log-Monitoring-Tool helfen.
Best Practices für Ihr Log-Management
Mit den folgenden Best Practices erhalten Sie optimale Visibility für Ihren Stack und können Troubleshooting-Prozesse beschleunigen sowie Klarheit über die UX gewinnen.
Umfang der Log-Erfassung
In einem Log werden Eventdaten zu Software-Anwendungen, Betriebssystemen und Infrastrukturkomponenten als Text in einem Standardausgabeformat oder einer Datei gespeichert. Neben Timestamps enthalten sind dabei etwa Fehlermeldungen, Stack-Traces und andere Datenpunkte, die Aufschluss über Eventzeitpunkte und -ursachen geben. Weitere Infos zum Logging auf Trace-Ebene finden Sie in unserem Blog-Post Troubleshooting leicht gemacht mit Logs in Context.
Logs bieten ein enormes Potenzial – sofern Sie 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. Überladen Sie Ihre Logs allerdings nicht. So erleichtern Sie sich die Logging-Skalierung und halten die Kosten fürs Log-Monitoring gering.
Entscheidend ist, dass die Logdaten direkt gewinnbringend für Ihre Team nutzbar sind, also etwa Infos zu Auslastung, benutzerbezogenen Events oder Anwendungsfehlern und -ausnahmen liefern. Ebenso wichtig sind hierbei Details, die bei der Rekonstruktion von Problemketten helfen und so zu fundierten Entscheidungen beitragen.
Logging anhand häufiger Szenarien
Logs erleichtern nicht nur die Behebung von Problemen, sondern sind auch äußerst nützlich für allgemeine Stack-Analysen z. B. zu Performance-Profilen oder statistischen Datenpunkten.
Deshalb sollten Sie bei der Logkonfiguration häufige Szenarien als Grundlage für die Wahl der zu erfassenden Daten heranziehen. So ermöglichen etwa detaillierte Anwendungslogs Einblicke in Performance und potenzielle Probleme 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. Im folgenden Video sehen Sie Beispiele für die Entscheidungsfindung mithilfe von Logs in Context.
Erfassung entscheidungsrelevanter Meldungen
Der Nutzen von Logmeldungen hängt ganz davon ab, ob sie zielführend in Entscheidungen umgesetzt 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.
Welche Logmeldungen sind von Nutzen?
Bei Anwendungsfehlern müssen Logmeldungen stichhaltig vermitteln, was genau in der Codezeile vor sich geht.
So sollte beispielsweise die Meldung zu einem Transaktionsfehler in etwa wie folgt lauten:
Transaktion fehlgeschlagen: Benutzer:in 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 Codezeile.
Sparen Sie Ihrem Team wertvolle Arbeitszeit
Eine kurze Beschreibung, die den Text oder die Nummer zum Fehlercode im Log ergänzt, verhilft Ihren Teams zu einer schnelleren Behebung des Problems.
Einfache, kompakte Logstruktur
Sicher sollte eine Meldung ausreichende Informationen enthalten. Eine Überladung an Details ist aber wenig hilfreich.
Denn Hinweise ohne echten Mehrwert treiben Speicheranforderungen schnell in die Höhe und verlangsamen Suchabläufe. Der Fehlerbehebung stehen sie also eher im Wege. Logmeldungen sollten wichtige Informationen in kompakter Form liefern, die dazu erfassten Daten müssen daher auf das Wesentliche beschränkt sein.
Beim Logformat ist darauf zu achten, dass Informationen zur Fehlerursache nicht jedes noch so kleine Umgebungsdetail enthalten. Bei API-Ausfällen etwa empfiehlt es sich, sämtliche Fehlermeldungen der betroffenen API einzubeziehen. Details zum zugehörigen Anwendungsspeicher dagegen können getrost vernachlässigt werden.
Achten Sie in jedem Fall immer darauf, dass Ihre Logmeldungen keine vertraulichen Informationen enthalten. Gelangen beispielsweise personenbezogene Informationen in Ihre Logs, sind der Schutz Ihrer Kundendaten und die Einhaltung gesetzlicher Vorgaben nicht mehr gewährleistet.
Die Zeit zählt mit
Auch darf der Timestamp in keiner Logmeldung fehlen. Der Tracking-Turnus hängt dabei von der Frequenz der jeweiligen Aufgabe ab. Wichtig ist aber stets, dass der Timestamp 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 Metriken und Events korrelieren.
Leicht verständliches Format
Das Wichtigste in einer Logmeldung ist der Informationsgehalt. Zugleich muss sie aber auch leicht lesbar sein, damit entscheidungsrelevante Infos direkt ersichtlich sind. Meldungen mit breitem Interpretationsspielraum und ohne Hintergrunddetails sind daher zu vermeiden, denn damit werden sich die meisten Teammitglieder schwertun.
Weitere wichtige Kriterien sind zudem einfaches Parsing und eine einheitliche Struktur, damit die Logs problemlos erfasst und aggregiert werden können. Mit dem New Relic Toolset für das Log-Management etwa lassen sich mühelos benutzerdefinierte Regeln zum Parsing erstellen. Diese setzen allerdings noch immer voraus, dass die Logs in einer lesbaren Struktur vorliegen.
Beispiele zur Logformatierung
### Beispiel für ein NGINX-Zugriffslog, das sich nur schlecht parsen lässt:
127.180.71.3 - - [10/May/2022:08:05:32 +0000] "GET /downloads/product_1 HTTP/1.1" 304 0 "-" "Debian APT-HTTP/1.3 (0.8.16~exp12ubuntu10.21)"
### Dieselben Loginformationen in einem zum Parsing geeigneten Format:
{
"remote_addr":"93.180.71.3",
"time":"1586514731",
"method":"GET",
"path":"/downloads/product_1",
"version":"HTTP/1.1",
}
Die beiden Logs enthalten exakt dieselben Informationen, beim ersten sind diese allerdings nicht gegliedert und entsprechend schlecht lesbar. Im zweiten haben Sie dagegen alle Details direkt im Blick, ohne erst das ganze Log durchgehen zu müssen. Zudem lassen sich Anwendungslogs mit einer solchen standardisierten Formatierung mühelos parsen und zur Nutzung auf verschiedenen Plattformen erfassen.
In puncto 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.
Nächste Schritte
Erfahren Sie mehr über das New Relic Toolset für das Log-Management. Weitere Einzelheiten zum Thema finden Sie außerdem in der zugehörigen Dokumentation.
Sie möchten direkt loslegen und Ihre Systeme gestützt auf umfassenden Kontext zur Anwendungs-Performance ausleuchten? Falls Sie New Relic und unsere Logging-Tools noch nicht nutzen, können Sie sich hier kostenlos registrieren. Das kostenlose Einstiegskonto umfasst 100 GB zur Datenerfassung, eine Komplettlizenz und unbegrenzte Basic-Lizenzen.
Die in diesem Blog geäußerten Ansichten sind die des Autors und spiegeln nicht unbedingt die Ansichten von New Relic wider. Alle vom Autor angebotenen Lösungen sind umgebungsspezifisch und nicht Teil der kommerziellen Lösungen oder des Supports von New Relic. Bitte besuchen Sie uns exklusiv im Explorers Hub (discuss.newrelic.com) für Fragen und Unterstützung zu diesem Blogbeitrag. Dieser Blog kann Links zu Inhalten auf Websites Dritter enthalten. Durch die Bereitstellung solcher Links übernimmt, garantiert, genehmigt oder billigt New Relic die auf diesen Websites verfügbaren Informationen, Ansichten oder Produkte nicht.