novaCapta ist Teil der
DE
/
EN
News der novaCapta

Graylog: Zentralisiertes Logging – Simpler Logging-Stack mit Graylog

Logging ist ein komplexes und doch essenzielles Thema. Gute Logs vereinfachen einem Supporter die Arbeit und ermöglichen es, Probleme schneller einzugrenzen. Logs dienen auch der Überwachung von Applikationen und Servern.

Einer unserer Kunden führt zentral zeitgesteuerte Tasks (etwa 15 verschiedene) über den Windows Task-Scheduler und einen eigens entwickelten Task Manager aus, welcher die Tasks überwacht. Da der Task Manager nicht sonderlich intuitiv in der Bedienung ist, kam die Anforderung auf, Ausgaben aus den Tasks zentral zu sammeln und auszuwerten – das perfekte Einsatzgebiet von Graylog.

Wieso Graylog?

Der wohl bekannteste Stack für Logging ist der “ELK-Stack”. Elastichsearch, Logstash und Kibana. Graylog verwendet für das Speichern der Logs auch Elasticsearch und kombiniert Logstash und Kibana in ein einzelnes, eigenes Produkt. Graylog ist Open-Source.

Im Gegensatz zu einem ELK-Stack ist Graylog sehr einfach und schnell aufgesetzt. Es bietet ein ansprechendes GUI und User Management. Über LDAP lässt sich sogar ein ActiveDirectory anbinden. Zudem besitzt Graylog eine Vielzahl an integrierter Inputs (Quellen und Formate von Logs) und bietet eine REST-API. Für die initiale Einrichtung ist fast keine Konfiguration notwendig.

Architektur

Grafik zur Architektur von Graylog Minimal SetupArchitektur von Graylog, Minimal Setup (Quelle: http://docs.graylog.org/en/latest/pages/architecture.html)
Architektur von Graylog, Minimal Setup (Quelle: http://docs.graylog.org/en/latest/pages/architecture.html)

Graylog verwendet für die interne Speicherung Meta-Informationen und Konfigurationen das Datenbanksystem MongoDB. Die Logs werden in Elasticsearch abgelegt. Somit skaliert Graylog auch super und es ist gut möglich, große Mengen an Logs zu verarbeiten.

Setup und Einrichtung

Wir verwenden eine Azure VM, auf der wir mit Docker die drei Dienste Graylog, MongoDB und Elasticsearch starten. Graylog ist manchmal etwas kompliziert, wenn es um die API und den Zugriff auf das User Interface geht. Es empfiehlt sich, einen Reverse Proxy einzusetzen und das UI nur über den Reverse Proxy auszuliefern. Das macht es auch einfacher, ein SSL-Zertifikat einzusetzen, um den Zugriff nur mittels HTTPS zu erlauben.

Meine Erfahrung mit Graylog nach sollte Elasticsearch mindestens 2 GB RAM und Graylog selber ca. 1 bis 2 GB RAM zur Verfügung haben, um auch bei minimaler Last ansprechende Reaktionszeiten zu haben. Gute Disk I/O-Werte sind essenziell für Elasticsearch.

Screenshot des Startbildschirms von Graylog mit der Suche die das Filtern von Log-Nachrichten mittels einer Query-Language ermöglichtDer Startbildschirm von Graylog: Die Suche, die das Filtern von Log-Nachrichten mittels einer Query-Language ermöglicht. Im Bild werden z.B. alle Einträge, die im Feld “source” den Wert exam
Der Startbildschirm von Graylog: Die Suche, die das Filtern von Log-Nachrichten mittels einer Query-Language ermöglicht. Im Bild werden z.B. alle Einträge, die im Feld “source” den Wert exam

Graylog verwendet das Prinzip von Inputs, Pipelines, Extractors und Streams. Für den Betrieb (und die initiale Installation) ist nur ein Input notwendig. Alle anderen Optionen können auch nachträglich hinzugefügt werden.

Inputs sind Quellen von Logs, wie z.B. Syslog. Ein Input kann für unterschiedliche Transportmittel definiert werden. Graylog unterstützt TCP und UDP, aber auch AMQP falls der Bedarf da ist.

Eine Pipeline ist ein optionales Konstrukt, um Nachrichten mit Logik zu verarbeiten. Mit Pipelines ist es möglich, die Verarbeitung einer einzelnen Log-Nachricht filigran zu steuern und zu beeinflussen.

Extractors sind meistens simple Reguläre Ausdrücke, um Informationen aus einer Log-Nachricht in ein eigenes Feld zu extrahieren. Zum Beispiel kann aus einer Log-Nachricht von IIS oder Apache die HTTP-Methode oder der HTTP-Status extrahiert werden.

Streams sind Sammlungen von Log-Nachrichten. Streams basieren auf Rules (Regeln). Diese Rules, die z.B. Reguläre Ausdrücke oder einfachere bool’sche Ausdrücke sein können, werden auf jede Nachricht angewendet und die Nachricht wird entsprechend in einen Stream eingeteilt. Das macht es möglich, Logs aus unterschiedlichsten Quellen zu sammeln und mittels Streams wieder in logische Einheiten aufzuteilen (z.B. ein Stream für Webserver, ein Stream für Applikations-Logs).

Screenshot der zwei konfigurierte Inputs in einer Graylog-Instanz zeigtZwei konfigurierte Inputs in einer Graylog-Instanz: GELF UDP und Syslog UDP. Inputs lassen sich einfach starten und stoppen und können auf “Nodes” oder global gestartet werden, wenn Graylog
Zwei konfigurierte Inputs in einer Graylog-Instanz: GELF UDP und Syslog UDP. Inputs lassen sich einfach starten und stoppen und können auf “Nodes” oder global gestartet werden, wenn Graylog

Wie sieht das aus in der Praxis?

Graylog hat ein eigenes Format namens GELF (Graylog Extended Log Format) entwickelt, das inzwischen ein ziemlich breit akzeptiertes Format ist und in praktisch allen Loggern (wie log4net oder log4j) bereits eingebaut ist. GELF basiert auf JSON und ist ein erweiterbares Format. Das erlaubt es, auch zusätzliche Informationen wie einen StackFrame oder andere Informationen zu übertragen. Zusätzlich ist GELF zumindest theoretisch fast nicht in der Größe begrenzt, da es chunking (das Aufteilen von Daten in mehrere Pakete auf IP-Ebene) unterstützt. Jede Log-Nachricht bekommt eine eindeutige UUID und bleibt über einen Permalink aufrufbar.

Screenshot Beispiel einer Log-Nachricht im UIBeispiel einer Log-Nachricht im UI. Die einzelnen Punkte sind unten im Text erläutert.
Beispiel einer Log-Nachricht im UI. Die einzelnen Punkte sind unten im Text erläutert.

Der obige Screenshot zeigt die Detailansicht einer einzelnen Log-Nachricht. Dabei sind die wichtigsten Infos mit Pfeilen markiert:

  1. Die eindeutige UUID einer Log-Nachricht. Die Nachricht bleibt über diese UUID aufrufbar.
  2. Zeigt an, über welchen Input die Nachricht empfangen wurde
  3. Ein Klick und der Permalink ist im Clipboard
  4. Zeigt die umliegenden Sekunden einer Nachricht – ideal um z.B. die letzten 5 Sekunden vor einem Fehler anzeigen zu können.
  5. Zeigt an, in welchen Streams diese Nachricht abgelegt wurde.

Tipps & Hints

Wenn eine Applikation, ob Graylog oder ELK, eingesetzt werden soll, müssen gerade auch in Bezug auf Sicherheit und Compliance einige Punkte beachtet werden:

  • Log-Nachrichten könnten sensible Informationen enthalten, die vielleicht ein System nicht verlassen sollen.
  • Die meisten Protokolle (insbesondere alles über UDP) bieten keine Möglichkeit, Daten zu verschlüsseln. Das ist nicht nur über das Internet heikel, sondern kann auch im internen Netz unerwünscht sein.
  • Auch wenn TCP eine verschlüsselte Übertragung ermöglicht, den Overhead in Bezug auf Verbindungsorientierung und die Problematik, die entsteht, wenn der Empfänger offline ist, ist nicht unbeträchtlich.

Fazit

Graylog ist eine gute Lösung, um einfach und bequem Log-Nachrichten aus unterschiedliche Quellen zu sammeln und zu aggregieren. Es bietet ein angenehmes User Interface und lässt sich sogar in ein Active Directory einbinden, um Benutzer zu authentifizieren. Graylog versteht unterschiedlichste Formate und kann somit mit den gängigsten Logging-Tools einer Plattform (wie log4net für .Net) direkt eingesetzt werden. Allerdings sind Sicherheit und Compliance nicht auf die leichte Schulter zu nehmen. Graylog bietet zudem eine der ausführlicheren und detaillierteren Dokumentationen im Vergleich.

Wer Graylog einmal selber ausprobieren möchte, findet in der Dokumentation ​ein fixfertiges Template für Docker.

Referenzen

Hintergrundbild: https://www.graylog.org/post/announcing-graylog-v2-0-ga
Graylog-Dokumentation: http://docs.graylog.org/en/latest/index.html