Was ist Log-Management?
Log-Management beschreibt alle Prozesse im Zusammenhang mit der Verarbeitung von Log-Daten – angefangen bei der Generierung und Aggregierung über die Speicherung und Analyse bis hin zur Archivierung und Löschung der Logs. Aufzeichnen sollte ein effektives System für Log-Management dabei stets lückenlos alle Abläufe in einer Anwendung, einem Netzwerk oder auf einem Server. Die so entstehenden Log-Daten sind äußerst nützlich im Kontext von Fehleranalyse und -behebung. Denn im Umfeld vieler moderner Anwendungen finden sich tagtäglich Millionen oder gar Milliarden an Events unterschiedlichster Services. Schon allein die schiere Menge geht mit einiger Komplexität einher, die bei Incidents ein Ableiten belastbarer und umsetzbarer Insights nicht gerade einfach macht. Und so ist Log-Management nunmehr eine entscheidende Säule von DevOps-, Observability- und IT-Frameworks generell.
Was ist ein Log?
Bei einem Log handelt es sich um einen computergenerierten Datensatz zu einem bestimmten Ablauf oder Event mit Timestamp. Log-Daten lassen sich mit der Mehrheit aller modernen Software-Systeme generieren – Möglichkeiten, die nicht ungenutzt bleiben sollten. Gängig sind dabei unter anderem etwa Funktionsaufrufe, Fehler, HTTP-Abfragen und Datenbanktransaktionen. Play-by-Play: Logs bilden Abläufe detailliert im Zeitverlauf ab.
Warum sind Logs so wichtig?
Logs erfassen jeden einzelnen Aspekt in Ihrer Anwendung, in Ihrem Netzwerk und auf Ihrem Server und bilden so die Grundlage für Anwendungs-Monitoring, Fehler-Tracking und -Reporting und unabdingbaren Faktor für Observability. Ohne Log-Daten wären sie schlicht nicht realisierbar.
Im Rahmen von Observability- und Monitoring-Frameworks kommen vier verschiedene Arten von Telemetriedaten zum Einsatz, die unter der Abkürzung MELT recht prägnant erfasst werden.
- Metrics basieren auf aggregierten Log-Daten und liefern Information zur Performance einer Anwendung. Technologien wie New Relic generieren bestimmte Metrics automatisch und auch Custom-Varianten sind möglich.
- Events beschreiben einzelne Ablaufpunkte innerhalb einer Anwendung. Sie bestehen aus mehreren Log-Zeilen. Events erfordern mehr Speicherplatz als Logs, weshalb sie typischerweise rascher archiviert oder gelöscht werden.
- Logs sind noch weitaus spezifischer als Events und bilden jedes einzelne Ablaufdetail in einer Anwendung ab.
- Traces wiederum nutzen Spans, um Events miteinander in Verbindung zu bringen und machen es so möglich, die Ursache eines Problems zu identifizieren und zu beheben.
Allen vier gemein: Logs. Ohne Logs kein MELT und keine Observability für Ihre Anwendungen. Statt Ihre Daten also proaktiv prüfen zu können, sind es Ihre Endbenutzer:innen, die Sie auf Probleme aufmerksam machen müssen. Sie stehen also immer sofort unter Zugzwang. Haben Sie schließlich von einem Problem Kenntnis erlangt, lässt es sich ohne Logs nur schwer beheben, da ja keine Fehler in der Anwendung dokumentiert sind, die Ihnen eine zielführende Analyse ermöglichen würden. Das in allen Belangen wenig wünschenswerte Endergebnis: Unzufriedenheit bei Ihrer User Base, unnötige Stress-Situationen für Ihre Entwickler:innen und womöglich sogar noch erhebliche Monetarisierungstäler bei Ihrem Produkt.
Glücklicherweise sind Logs außerdem auch ziemliche Leichtgewichte, sind bei Übertragung und Speicherung weitaus weniger platzhungrig als viele andere Datentypen wie z. B. Events.
Warum ist Log-Management wichtig?
Eine Anwendung für die Ausgabe von Log-Daten zu konfigurieren ist einerseits fundamental, aber noch längst nicht ausreichend. Hervorragend demonstrieren lässt sich der Grund mit einem klassischen philosophischen Gedankenexperiment: „Wenn ein Baum fällt und niemand hört es, ist dabei dann überhaupt ein Geräusch entstanden?“ Ganz ähnlich verhält es sich mit Log-Daten: Werden sie generiert, aber nicht korrekt erfasst und gespeichert, sind sie auch nicht nutzbar. Um aus Logs konkreten Mehrwert ziehen zu können, dürfen sie nicht an ihrem Ursprungsort verbleiben. Vielmehr müssen die Logs an einen idealerweise zentralen Speicherort übermittelt werden, um sie dort im Kontext von Daten aus anderen Services analysieren zu können.
Die zentralisierte Datenerfassung ist aber nur ein Faktor im Log-Management, denn es geht hier um das gesamte Log-Lifecycle von der Entstehung der Daten bis zu ihrer Archivierung oder Löschung.
Viele moderne Anwendungen setzen auf Microservices, verteilte Systeme und cloudbasierte Services, bei denen jede Systemkomponente ihre eigenen Log-Daten ausgibt. Nehmen wir etwa an, dass Sie Ihre HTTP-Abfragen mit der längsten Reaktionszeit identifizieren möchten. Wird Ihre Anwendung über ein verteiltes System ausgeführt, können HTTP-Anfragen von diversen Services ausgehen. Ein Abgleich ist dabei nur möglich, wenn die Log-Daten zentral gespeichert sind. Möglich wird dies mit effektivem Log-Management.
Ein starkes Framework in diesem Zusammenhang macht Folgendes möglich:
- Weniger Context Switching: Sind Ihre Log-Daten zentral zur Analyse erfasst, reduziert dies auch das Hin- und Herwechseln zwischen Tools und Zusammenhängen. Bei separat voneinander verwalteten Log-Daten hingegen ist zur Behebung von Problemen nicht selten die Prüfung mehrerer Speicherorte und Tools vonnöten.
- Nahtlose Problembehebung: Eine Lösung für Log-Management ist vor allem dann zielführend, wenn Sie mit ihr Log-Daten rasch abrufen, analysieren und im Kontext visualisieren können. Denn nur so sind Sie in der Lage, Probleme zu identifizieren und zu eliminieren, bevor sie sich auf Ihre Benutzer:innen auswirken können.
- Präzise Datensuchen ohne Vorlaufzeit: Auch adaptive Such-Features sollte Ihr Log-Management bieten, damit Sie rasch zu den benötigten Daten vorstoßen.
- Zentrale Datenvisualisierung: Mit zentral gespeicherten Log-Daten können Sie anhand Ihrer MELT-Telemetrie eigene Visualisierungen und Dashboards entwickeln und über diese Ihre Anwendungs-Performance kompakt überblicken.
Wie genau lassen sich diese Möglichkeiten konsequent nutzen? Im Folgenden gehen wir darauf ein.
Feature-Fundament für Ihr Log-Management
Am effektivsten wird Ihr Log-Management auf Grundlage dieses Feature Sets.
- Flexible, umfassende Instrumentierung: Um Ihre Log-Daten zentral zu erfassen, muss Ihre Anwendung instrumentiert sein. Herzstück einer Instrumentierung ist die Installation von Agents, die den Datenfluss durch Ihre Anwendung tracken. Ein Beispiel anhand einer Anwendung mit mehreren Cloud-Services und APIs für Java, Rails und .NET und primär React und JavaScript am Frontend. Jeder dieser Services muss instrumentiert werden. Für eine umfassende Abdeckung sollte Ihr Log-Management-Tool über Agents für möglichst viele Programmiersprachen und Services verfügen. Für einzelne Anwendungsbereiche, etwa solche mit sensiblen Daten, kann es durchaus sinnvoll sein, von einer Instrumentierung abzusehen. Doch entstehen dabei naturgemäß auch Lücken in Ihren Log-Daten, weshalb eine möglichst konsistente Strategie sehr sinnvoll ist.
- Kompatibilität mit Log-Forwarding: Kann ein Service nicht instrumentiert werden, müssen Sie auf Log-Forwarding zurückgreifen. Auch diese Möglichkeit sollte Ihr Log-Management-Tool unbedingt unterstützen.
- Umfassende Abfrage-Features: Tritt ein Fehler auf, müssen Sie direkt und ohne Verzögerung auf Ihre Logs zugreifen können. Schnelle und effiziente Datenabfragen durch Ihre Lösung für Log-Management sind hierfür essenziell. In New Relic erfolgt dies über NRQL (New Relic Query Language), dies für eine Vielzahl flexibler Abfragen.
- Sichere Datenspeicherung: Ihre sensiblen Daten wollen Sie konsequent geschützt wissen, speziell für Anwendungen mit hohen Compliance-Anforderungen wie etwa im Gesundheitskontext rund um HIPAA.
Welche Schritte umfasst Log-Management?
Im Kern fußt Log-Management auf diesen sequenziellen Schritten:
- Generierung: Um Log-Daten später analysieren zu können, müssen sie Ihre Services zunächst einmal produzieren. Externe Services enthalten häufig Feature Sets zur Ausgabe von Log-Daten. Auch durch Instrumentierung kann dieser Prozess angestoßen werden.
- Erfassung: Im zweiten Schritt müssen die Log-Daten nun erfasst werden. Dies erfolgt zumeist durch eine Kombination aus Instrumentierung und Log-Forwarding, bei der alle Logs zentral abgelegt werden.
- Aggregation: Im Rahmen der Aggregation werden die erfassten Log-Daten aus verschiedenen Quellen in einem zur Analyse verwertbaren, konsistenten Format standardisiert, z. B. JSON. Häufig werden die Logs mit weiteren Metadaten angereichert, die zusätzlichen Kontext liefern, wie zum Beispiel den Service oder die IP-Adresse, über die der Log ausgegeben wurde.
- Speicherung: Nach erfolgreicher Erfassung müssen die Log-Daten in einer Datenbank gespeichert werden. Bei New Relic ist dies die NRDB (New Relic Database). Für effiziente Abfragen und Analysen sollten die Daten idealerweise indiziert werden.
- Archivierung: Nahtloser, konstanter Zugriff wird bei einigen Log-Daten nach einer gewissen Zeit wahrscheinlich nicht mehr erforderlich sein. Rechtliche Vorschriften oder unternehmensinterne Richtlinien schreiben aber womöglich ihre generelle Verfügbarkeit vor, sodass eine Löschung nicht möglich ist. Durch Archivierung dieser älteren Datenbestände können Sie dem nachkommen und gleichzeitig Ihre Speicherkapazität optimieren und aktuelle Log-Daten leichter abfragen.
- Löschung: Ab einem gewissen Zeitpunkt kann auch eine Löschung sinnvoll sein.
Ein Framework für Log-Management soll Logs letztlich zur Fehlerbehebung, für Analysen und Datenvisualisierung, Reporting und Alerting verfügbar machen. Unabdingbar dabei ist eine Technologie, die dies effektiv gestaltet. Häufig werden entsprechende Lösungen zusammen mit Application Performance Monitoring und Observability-Lösungen eingesetzt.
Jetzt mit Log-Management starten. Testen Sie New Relic.
Der ideale nächste Schritt, um mehr über Log-Management zu erfahren: die Übung am Objekt! Mit einem kostenlosen New Relic Konto ist genau das möglich. Das Einstiegskonto ist komplett kostenlos – dies mit 100 GB zur Datenerfassung, einer Komplettlizenz und unbegrenzten Basic-Lizenzen. Weitere Informationen erhalten Sie außerdem in unserer Dokumentation für Log-Management.
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.