Die Menge an Daten, die in modernen Systemen generiert werden, ist in den letzten Jahren exponentiell gewachsen. Ein erheblicher Teil dieses Wachstums lässt sich auf Protokolldateien zurückführen. Folgende Komponenten generieren Protokolle:

  • Server
  • Netzwerkgeräte
  • Betriebssysteme
  • Software-Anwendungen
  • Cloud-Services
  • … und mehr

Unternehmen sammeln und speichern Protokolle, um Zwischenfälle zu beheben, die Ursache von Leistungsproblemen zu ermitteln, Sicherheitsverletzungen zu untersuchen oder Compliance-Anforderungen einzuhalten.

Allerdings können Protokolle viel Speicherplatz beanspruchen. Die Größe einzelner Protokolldateien kann rasant ansteigen und den verfügbaren Speicherplatz strapazieren. Ohne entsprechende Kontrollen kommt es daher zur Beeinträchtigung der Systemleistung.

Aus diesem Grund gibt es die Log-Rotation: ein kontrolliertes Verfahren zur Entfernung oder Archivierung älterer Protokolle, um Platz für neue zu schaffen.

In diesem Artikel erläutern wir die Grundlagen der Log-Rotation – warum sie wichtig ist und was Sie mit älteren Protokolldateien tun können. Zudem werfen wir einen kurzen Blick auf Falcon LogScale, ein modernes, cloudbasiertes Log-Management-System.

Was ist Log-Rotation?

Bei der Log-Rotation geht es darum, die Größe von Protokolldateien zu begrenzen. Wenn eine Protokolldatei einen bestimmten Schwellenwert erreicht (z. B. eine maximale Dateigröße, ein bestimmtes Alter oder eine bestimmte Anzahl von Datensätzen), benennt die zugehörige Anwendung sie um, erstellt eine neue Datei mit dem ursprünglichen Namen und schreibt Ereignisse fortan in die neue Datei. Häufig komprimiert, archiviert oder löscht die Anwendung die alte Protokolldatei. Log-Rotation ist ein automatisierter und sekundenschneller Prozess, den einige Anwendungen in einem dedizierten Thread ausführen.

Bei der Umbenennung wird häufig der Zeitstempel der Rotation an die ältere Protokolldatei angehängt. Wenn die Protokolldatei beispielsweise mylogfile.log heißt, wird die rotierte Protokolldatei zu mylogfile_xxxxxxxx.log umbenannt (xxxxxxxx steht hier für das Datum oder den Zeitstempel). Die neu erstellte Datei trägt dann wieder den Namen mylogfile.log. Am Ende sehen die Einträge im Protokolldateiordner zum Beispiel so aus:

mylogfile.log mylogfile_20220429.log mylogfile_20220430.log … …

In einigen Fällen werden anstelle von Zeitstempeln auch Suffixe an ältere Protokolldateien angehängt. Wenn beispielsweise der Dateiname des SQL Server-Fehlerprotokolls ERRORLOG lautet, heißen die älteren Dateien ERRORLOG.1, ERRORLOG.2, ERRORLOG.3 usw. Dabei gilt: Je höher die Zahl, desto älter die Datei.

Die Einstellung für die Log-Rotation können Sie in der Regel in der Anwendung oder im Betriebssystem mithilfe bestimmter Kriterien festlegen. Nachdem die Einstellungen gespeichert sind, wird eine Protokollrotation ausgelöst, sobald diese Kriterien erfüllt sind. In bestimmten Fällen können Sie die Log-Rotation auch deaktivieren. Dies sollte jedoch nur eine vorübergehende Maßnahme sein. Bei manchen Anwendungen ist es möglich, die Protokolldateinamen festzulegen, anzugeben, wo sie gespeichert werden sollen, und sogar die Protokollierung vollständig zu deaktivieren.

In einigen Fällen müssen ältere Protokolle lokal aufbewahrt werden, da die Anwendungsereignisse sich über mehrere rotierte Dateien erstrecken können. Ältere Dateien können Sie komprimieren, um Speicherplatz auf dem Server zu sparen. Oder Sie richten es so ein, dass diese nach einem bestimmten Zeitraum entfernt werden. Außerdem können Sie sie zur langfristigen Aufbewahrung auf Archivspeichergeräte, Backup-Server, cloudbasierte Objektspeichermedien wie S3 oder ein Log-Management-System verschieben.

Warum benötigen Sie Log-Rotation?

Wie bereits erwähnt, können Protokolldateien hilfreich sein, um die Ursache von Fehlern zu ermitteln, Sicherheitszwischenfälle zu untersuchen und Ihre IT-Umgebung zu bewerten. Wenn Ihr System jedoch keine Log-Rotation bietet, können Protokolle, die sehr viele Einträge mit Datenverkehr oder Authentifizierungsereignissen erfassen, schnell zu einem Problem werden.

Speicherplatz

Wenn die Protokolldateien nicht automatisch komprimiert oder gelöscht werden, wachsen sie, bis der Speicherplatz des Servers voll ist. Kritische Dienste funktionieren dann nicht mehr und es kann zu Lücken in den Protokollen kommen, da die Anwendung nur dann neue Ereignisse schreiben kann, wenn Speicherplatz zur Verfügung steht. Wenn es in dieser Zeit zu einem Zwischenfall kommt, wird dieser möglicherweise nicht aufgezeichnet.

Leistung

Auch ohne vollen Laufwerkspeicher kann es auf einem Server zu Leistungsproblemen kommen. Wenn dieser nicht über genügend Arbeitsspeicher verfügt, dauert das Öffnen, Lesen und Schreiben großer Dateien, die mitunter mehrere GB groß sind, erheblich länger. Manuelle Abläufe wie tail, head oder grep können viel Zeit in Anspruch nehmen, was bei der Untersuchung von kritischen Problemen von Nachteil sein kann.

Echtzeit-Warnungen

Log-Management-Lösungen haben oft Schwierigkeiten, große Protokolldateien zu verarbeiten. Die Protokollierungsagenten benötigen dann mehr Zeit, um die Daten über das Netz zu streamen, und die Log-Management-Lösung benötigt mehr Zeit, um die Daten zu analysieren und zu katalogisieren. All dies kann die Echtzeit-Warnung verzögern. Stellen wir uns ein Szenario vor, in dem Authentifizierungsprotokolle Hinweise auf einen Password-Spraying-Angriff enthalten. Wegen der großen Dateigröße dauert es jedoch dreißig Minuten, bis die SIEM-Lösung (Sicherheitsinformations- und Ereignismanagement) den Angriff identifiziert und eine Warnung auslöst. Eine solche Situation wäre natürlich keineswegs ideal.

Was sollte mit älteren Protokolldateien geschehen?

Sofern Sie Ihren Servern keinen unbegrenzten Speicherplatz zur Verfügung stellen können, müssen Sie eine Strategie für den Umgang mit älteren Protokolldateien haben. Einige Unternehmen verfolgen je nach Anwendungsfall, Wichtigkeit und rechtlichen Verpflichtungen unterschiedliche Ansätze für unterschiedliche Arten von Protokolldateien.

Löschen

Am einfachsten ist es, rotierte Protokolldateien zu löschen. Dies lässt sich leicht konfigurieren, schafft Platz auf dem Server und senkt die Speicherkosten. Da Protokolldateien jedoch häufig wichtige Ereignisse enthalten – und Sie nicht immer wissen, wann Sie sie benötigen – kann dies riskant sein. Zudem können wichtige Informationen verloren gehen, wenn sich ein Ereignis über mehrere Protokolldateien erstreckt. Daher ist das Löschen alter Protokolldateien je nach Branche und Compliance-Anforderungen nicht immer eine Option.

Komprimierung

Im Rahmen des Rotationsprozesses können Sie Protokolldateien komprimieren und ältere Dateien auf dem Server behalten. In der Regel wird dies bei Linux-Systemen so gehandhabt. Häufig haben komprimierte Protokolldateien dort die Erweiterung .gz.

Archivierung

Bei der Archivierung werden ältere Protokolle zur langfristigen Aufbewahrung in einem separaten Speichersystem gespeichert. Dies kann ein spezieller Backup-Server mit externem Speicher (z. B. SAN), kostengünstiger Cloud-Speicher (z. B. AWS S3) oder externer Bandspeicher sein.

Log-Management-System

Die meisten IT-Abläufe benötigen ein zentrales System zur Speicherung ihrer Protokolle. Das System ermöglicht Benutzern, Ereignisse aus Protokolldateien zu durchsuchen, zu analysieren, zu korrelieren und zu visualisieren. Dies ist weitaus einfacher als die manuelle Verarbeitung von Protokolldateien aus dem Dateisystem. Log-Management-Systeme können historische Trends anzeigen, Systemzustände vergleichen und Echtzeitwarnungen für kritische Ereignisse bereitstellen.

Die Log-Rotation sollte kein Ersatz für ein Log-Management-System sein. Stattdessen sollten sich beide Systeme ergänzen, sodass Protokolldateien rotiert, archiviert oder entfernt werden, sobald sie vom Log-Management-System verarbeitet und gespeichert wurden.

Ganz gleich, was Sie mit älteren Protokolldateien tun: Sie müssen sie mit Sicherheitsmaßnahmen schützen. Dadurch wird sichergestellt, dass alle in den Protokolldateien enthaltenen vertraulichen Informationen geschützt sind und die Dateien nicht manipuliert werden können.

Vollständige Protokollierung und Einblicke – kostenlos

Falcon LogScale Community Edition (ehemals Humio) ist eine kostenlose moderne Log-Management-Plattform für die Cloud. Durch die Erfassung von Streaming-Daten erhalten Sie einen sofortigen Überblick über verteilte Systeme und können Zwischenfälle verhindern bzw. beheben.

Falcon LogScale Community Edition ist sofort kostenlos verfügbar und bietet folgende Vorteile:

  • Erfassung von bis zu 16 GB pro Tag
  • Speicherung bis zu 7 Tage
  • Keine Kreditkarte erforderlich
  • Unbegrenzter Zugriff ohne Testzeitraum
  • Indexlose Protokollierung, Echtzeit-Warnungen und Live-Dashboards
  • Zugriff auf unseren Marktplatz und zugehörige Pakete, einschließlich Leitfäden zur Entwicklung neuer Pakete
  • Lernen und Kooperation in einer aktiven Gemeinschaft

Kostenlos testen

Arfan Sharif ist Product Marketing Lead für das Observability-Portfolio bei CrowdStrike. Er verfügt über mehr als 15 Jahre Erfahrung bei der Umsetzung von Lösungen für Log-Management, ITOps, Beobachtbarkeit, Sicherheit und Benutzerunterstützung für Unternehmen wie Splunk, Genesys und Quest Software. Arfan Sharif hat einen Abschluss in Informatik bei der Buckinghamshire New University und blickt auf eine Karriere in den Bereichen Produktmarketing und Sales Engineering zurück.