Server-Logdateien im Cloud Object Storage

Logdateien mit S3cmd und Logrotate problemlos verarbeiten

Logdateien, die von Servern und Software-Anwendungen geschrieben werden, beinhalten viele nützlichen Informationen, die beim Debuggen von Software, beim Untersuchen von Sicherheitsvorfällen und beim Generieren aufschlussreicher Metriken und Statistiken nützlich sein können. Jeder Dienst auf einem Server erzeugt irgendeinen Log-Output, der üblicherweise als Logdateien in einer eigenen Partition auf dem Server gespeichert wird (z.B. unter /var/log/ bei Linux-basierten Betriebssystemen) und/oder sie werden mit einem Log-Aggregations-Tool, wie z.B. Elasticsearch oder Graylog, zentralisiert. Die Datenmenge ist allerdings oft schwer vorhersehbar und so ist jeder Admin vermutlich bereits in der Situation gewesen, dass die Log-Partition unerwartet schnell ihre Kapazitätsgrenzen erreichte und damit im schlimmsten Fall sogar nach kurzer Zeit das System lahmgelegt wurde. Auch die Langzeitspeicherung in einem zentralen Logdienst, wie z.B. rsyslog, ist auf Dauer nicht kosteneffizient. Eine günstige Lösung für diese langfristigen Speicheranforderungen ist das Archivieren von Logdateien in einem Object Storage.

In diesem Artikel möchte ich auf die Möglichkeit eingehen, eine Langzeitarchivierung von Logdateien in einem Object Store zu ermöglichen. Dabei kommen Tools und Technologien wie Logrotate, S3cmd und ProfitBricks S3 Object Storage zum Einsatz. Darüber hinaus wird auch kurz auf erweiterte Einsatzmöglichkeiten hingewiesen, z.B. wie dieses Setup auch wunderbar als Basis einer Datenquelle für einen ELK Stack (ElasticSearch, logstash und Kibana) dienen kann.

Vorteile

Logdateien sollten für spätere Analysen, zur Einhaltung der gesetzlichen Aufbewahrungspflichten oder zu Sicherungszwecken für unbegrenzte Zeit archiviert werden. Da Logdateien sehr statische Dateien sind, die auch nachträglich nicht geändert werden, können diese im Vergleich zu Block Storage sehr kostengünstig und effizient in einem Object Storage gespeichert werden. Dies geschieht unter Ausnutzung der Vorteile eines Object Storages wie z.B. Verschlüsselung, hohe Ausfallsicherheit und niedrige Kosten. Hier kann schon fast von einem “Fire and Forget”-Prinzip gesprochen werden: einmal abgespeichert, brauchen Sie sich keine weiteren Gedanken um die Sicherheit, Langlebigkeit oder Verfügbarkeit Ihrer Logdateien machen.

Auslagern von Dateien mit S3cmd

Um die Logdateien im ProfitBricks Object Storage zu archivieren, wird das kostenlose Tool S3cmd (https://github.com/s3tools/s3cmd) verwendet. S3cmd ist ein Befehlszeilentool und Client zum Hochladen, Abrufen und Verwalten von Daten in S3-kompatiblen Object Storages. Alle hier aufgeführten Beispiele basieren auf einem CentOS 7 und Debian 9 Betriebssystem, betrieben in der ProfitBricks Cloud am Standort Frankfurt. Das Konzept funktioniert aber genauso gut auch auf anderen Betriebssystemen und kann mit ein wenig Linux-Know-How adaptiert werden.

S3cmd befindet sich im EPEL Repository und kann von da aus direkt installiert werden:

Unter Debian:

Die Konfiguration erfolgt mit der Befehlsoption --configure:

Key und Secret können direkt aus dem ProfitBricks DCD auf der Seite “Object Storage Key Manager” kopiert werden.

Anmerkung: Unter Debian 9 wird leider eine alte Version von S3cmd installiert, die nicht nach dem Endpoint bei der Konfiguration fragt. Hier muss der korrekte Endpoint nachträglich manuell in der Konfigurationsdatei eingetragen werden.

Ob S3cmd mit der generierten Konfiguration wirklich funktioniert, lässt sich sehr einfach mit dem Befehl ‘ s3cmd la’ testen. Dieser sollte alle bereits existierenden Buckets auflisten. Falls noch kein Bucket erstellt wurde, lässt sich dieser mit ‘ s3cmd mb s3://mein_neuer_bucket_name’ erstellen.

Mit dem Befehl ‘ s3cmd sync <pfad_zu_lokalem_verzeichnis_oder_datei> s3://<bucket_name>/<optionaler_verzeichnis_name>’ können nun lokale Daten in den Object Storage migriert werden. Es werden dabei nur Dateien hochgeladen, die im Object Storage noch nicht existieren oder bei denen die Größe oder die MD5-Prüfsumme nicht übereinstimmen. Ist ein Verzeichnis hinter dem Bucketnamen angegeben, wird dieses automatisch erstellt.

Logdateien Management mit Logrotate

Die Latenzzeiten eines Object Storage sind allgemein höher als die eines lokal angeschlossenen Block Storage. Deshalb empfiehlt es sich, die jeweils aktuellen Logdateien weiterhin im lokalen Dateisystem zu speichern. Mit Hilfe einer “Logrotation” werden aktuelle von alten Logdateien getrennt. “Logrotation” bezieht sich auf die Praxis, die aktuelle Logdatei einer Anwendung zu archivieren, eine neue Logdatei zu starten und ältere Logdateien zu löschen. Dabei können unterschiedliche Regeln pro Logdatei bzw. Logverzeichnis erstellt werden. Logrotate wird normalerweise einmal am Tag über cron ausgeführt:

Beim Starten von Logrotate wird die Konfigurationsdatei /etc/logrotate.conf eingelesen. Die Datei enthält die Standardparameter, die Logrotate beim Rotieren von Logdateien verwendet. Zu beachten ist die Zeile

Dieses Verzeichnis beinhaltet weitere applikationsspezifische Konfigurationsdateien.

Als Beispiel wollen wir hier die Logdateien eines Webservers einer Logrotation unterziehen. Hierfür wird eine neue Datei innerhalb dieses Verzeichnisses erstellt, bzw. eine vorhandene angepasst:

Die Defaultoptionen aus /etc/logrotate.conf werden übernommen, bzw. können hier gezielt überschrieben werden. Für unsere http Logdateien soll z.B. keine wöchentliche, sondern eine tägliche Rotation stattfinden.
In der obigen Konfiguration haben wir definiert, dass

  • sieben alte Logdateien behalten werden ( rotate 7), ältere werden automatisch gelöscht. Das ist hier unproblematisch und kann sogar noch weiter reduziert werden, da die Langzeitarchivierung eh auf dem Object Storage liegt.
  • täglich rotiert wird ( daily). Das überschreibt die Defaulteinstellung von weekly aus /etc/logrotate.conf. Anstatt einer täglichen Rotation könnte die Rotation auch auf Basis der Größe der Logdatei erfolgen. Hierfür wird der Parameter size, gefolgt von einem Wert wie z.B. ‘ size 1M’, verwendet. Das stellt sicher, dass die aktuelle Logdatei nie größer als 1MB wird.
  • die alte Logdatei beim Rotieren nicht sofort komprimiert wird ( delaycompress), sondern erst bei der nächsten Rotation. Dies stellt sicher, dass keine Logeinträge in der kurzen Zeit zwischen Rotieren und dem Reload des Services verloren gehen.
  • der Dateiname einen Zeitstempel ( dateext) als Suffix enthält, mit dem mit dateformat gewähltem Format.
  • am Schluss S3cmd alle komprimierten Dateien auf den Object Storage synchronisiert. Hierfür wird pro Host ein eigenes Verzeichnis verwendet.

Die Konfiguration kann mit folgendem Befehl getestet werden. Die Option --debug verhindert die tatsächliche Ausführung.

Werden hier keine Fehler zurückgegeben, kann der gleiche Befehl ohne die Option --debug ausgeführt werden. Nun sollten die alten Logdateien auch tatsächlich in den Object Storage hochgeladen werden. Dies kann mit dem Befehl ‘ s3cmd ls s3://<bucket_name>/<host_name>/’ überprüft werden:

Damit ist die grundlegende Langzeitarchivierung der Logdateien auf einem Object Storage abgeschlossen. Den passenden S3-kompatiblen Object Storage finden Sie bei ProfitBricks.

Ausblick

Zu einem modernen Log-Management-Konzept gehört mehr als nur die sichere Langzeitarchivierung der Logdateien. Logs beinhalten viele wertvolle Informationen, die nicht nur für das reine Debuggen im Fehlerfall nützlich sind. Eine umfassende Analyse der Daten ermöglicht es Unternehmen, die Beziehung zwischen Ereignisse im Betrieb, der Sicherheit und im Änderungsmanagement zu verstehen und ein umfassendes Verständnis ihrer Infrastruktur aufrechtzuerhalten.

Hierfür eignen sich Tools wie der ELK Stack:

  • ElasticSearch: eine verteilte, REST-basierte Such- und Analytik-Engine, des Kernkomponente eine zentrale Datenspeicherung ist
  • Logstash: ermöglicht das Sammeln von Logdateien aus unterschiedlichen Quellen, die Aufbereitung bzw. Umwandlung der Daten und die anschließende Weiterleitung an ElasticSearch.
  • Kibana: Visualisierungstool von Daten, mit umfassenden Reportingmöglichkeiten

In einem folgendem Blogartikel werde ich näher auf die Vorteile eines solchen Systems eingehen und die technischen Schritte zum Aufsetzen eines ELK Stack beschreiben.

Hinterlasse eine Antwort

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind markiert *