Logging-Plattformen im Vergleich
Logging-Produkte müssen längst nicht mehr nur ihr Hostsystem überwachen – verteilte Systeme erfordern ein dezentrales Log-Management. Der Trend bei den Anbietern geht zu SaaS und Observability-Plattformen.
Moderne IT-Infrastrukturen sind durch eine Vielzahl von Anwendungen und Systemen mit wechselseitigen Abhängigkeiten gekennzeichnet. Wenn an einer Stelle etwas nicht funktioniert, kann die Ursache in einem Fehler an einer ganz anderen Stelle liegen.
Mit dem Einzug von Microservices, Containerclustern und Cloud-Applikationen kommen immer mehr Logquellen hinzu, die ein direktes Speichern am Host gar nicht mehr erlauben und oft die Fehlersuche durch viele unterschiedliche Komponenten und Rollen komplex machen. Das richtige Pod-Log zu finden, wenn der Webshop im Managed Kubernetes nicht mehr erreichbar ist, ist herausfordernd.
Neben dem Trend zu verteilten Systemen und unterschiedlichen Netzwerken stellen auch Single-Sign-on- und Zero-Trust-Security das Log-Management vor neue Herausforderungen. Es bietet sich daher an, Logs der Hostsysteme zu sammeln, an zentraler Stelle gebündelt zu speichern und verfügbar zu halten. Dort lässt sich auch hostübergreifend planen, wie lange man Logs vorhalten möchte (Log Retention).
Anforderungen ans Log-Management
Das Sammeln von Logs sollte auf unterschiedlichen Wegen möglich sein. Agentendienste laufen etwa auf den Hostsystemen oder in Containern im Kubernetes-Cluster. Alternativ für Integration und Automatisieren sind eine REST-API und/oder CLI wünschenswert. Der Datenverkehr zwischen Client und Server muss verschlüsselt sein: In Logdaten liegen sensitive Daten, die nicht in falsche Hände gelangen sollten.
Log-Management-Software muss mit vielen völlig unterschiedlichen Formaten zurechtkommen: Zeitstempeln im Syslog-Format, Structured-Logging mit JSON oder ganz eigenen Formaten mit XML oder YAML. Das erfordert Dienste wie Log-Ingestors, die Logdaten einlesen, und Log-Prozessoren, die sie aufbereiten. Dabei lassen sich zusätzliche Informationen hinzufügen oder sensitive Details entfernen. Dies ist im Hinblick auf die Datenschutz-Grundverordnung (DSGVO) beim Speichern personenbezogener Daten eine wichtige Anforderung.
Neben dem Verarbeiten und Speichern muss ein Log-Management-Werkzeug in der Lage sein, die Daten in einer Weboberfläche oder REST-API zu visualisieren. Das Absichern mit TLS und Role-based Access Control (RBAC) ist im Enterprise-Umfeld ein Muss; genau wie die Möglichkeit, anhand von Suchabfragen entsprechende Dashboards zu erstellen und im Team zu teilen.
Log-Management-Produkte bieten die Möglichkeit, Alarme zu definieren, die entsprechendes Incident-Management nach sich ziehen. Viele Log-Management-Produkte haben sich zur Observability-Plattform gewandelt und bieten neben Logs auch Metriken und Traces an, also das Sammeln und Korrelieren der Daten. Die zusätzlichen Observability-Daten sind bei der Root-Cause-Analyse und beim Debugging hilfreich. Administratorinnen und Adminstratoren sollten bei der Auswahl des Log-Management-Produkts auch darauf achten, dass die Plattform Observability-Funktionen mitbringt oder sich leicht erweitern lässt.
Ein Tipp an dieser Stelle: Log-Management allein kann schon überwältigend sein, um so mehr, wenn Observability hinzukommt. Es hilft also, zunächst mit den Logs zu beginnen. Nach dem Eingewöhnen lässt sich mit Metriken und Traces in die Welt von Observability einsteigen.
Mit wachsenden Datenmengen wächst auch die Verantwortung: sowohl für das Speichern und Vorhalten der Daten als auch für die Sicherheit. Gezielte Konfiguration der Logging-Levels und eigene Log-Streams helfen, nur die wesentlichen Teile zu sammeln und mit anderen Quellen zu korrelieren.
Eine Plattform für Log-Management sollte auch in den nächsten Jahren bestehen: Gibt es eine Lernplattform, ein Communityforum, wie ist es um Erweiterungen, APIs und Apps bestellt? Wichtig ist auch, ob man im Rahmen eines Enterprise-Abbonements Support und Beratung bei Problemen bekommt.
Tools und Plattformen
Einige der im Folgenden vorgestellten Produkte bieten sowohl eine freie Open-Source-Edition als auch eine Enterprise-Edition mit Lizenzkosten. SaaS-Produkte bieten unterschiedliche Abonnements, die Kunden etwa eine bestimmte Größe an Logs frei verarbeiten lassen.
Ein Kriterium war, wie schnell man den Einstieg hinbekommt und Logdaten aus einem Linux-System sammeln und visualisieren kann. Als Testumgebung dient eine VM mit Ubuntu in der Hetzner-Cloud, in der alle Systeme installiert wurden, die nicht ausschließlich eine SaaS-Option anbieten. Im Falle von SaaS wurden in der VM die jeweiligen Agenten der Systeme installiert. Die Testdaten lieferte das Syslog der VM selbst.
Dieses Szenario sollte unter anderem über folgende Punkte Aufschluss geben: Wie schnell kommen die Logdaten aus dem Syslog in die Log-Management-Plattform und wie funktionieren Suche und Dashboards? Ist der Einstieg in Kubernetes-Logging in der Dokumentation abgedeckt und wie gut ist die Qualität für spätere Tasks? Muss man den hauseigenen Agenten zum Log-Sammeln verwenden, kann man Open-Source-Produkte einbinden oder spezifizierte APIs verwenden? Bonuspunkte gibt es für Install-Wizards, Default-Dashboards, APIs und Marktplätze.
Die vorgestellten Tools haben alle eine Installation von Server und/oder Agent hinter sich und mussten ein Test-Syslog in einer frischen Ubuntu-20-VM einlesen. Um zu prüfen, ob die VM tatsächlich aktuelle Daten liest, wurde mithilfe des logger-Befehls ein Text im Syslog generiert, der immer den Begriff Error enthält (siehe Listing). In einigen Testfällen wurde ein Nginx-Webserver installiert, um zusätzliche Logdaten in Webserver-Access-Logs zur Verfügung zu haben.
Elastic Stack
Elastic Stack besteht aus mehreren Komponenten. Elasticsearch speichert Logs, kann Indizes für schnelleren Zugriff definieren und stellt eine REST-API für Schreib- und Lesezugriffe zur Verfügung. Kibana agiert als Visualisierungs-Frontend mit Suche und Dashboards. Als Agent für das Log-Sammeln dient Elastic Beats. Kürzlich führten die Entwickler den Elastic Agent ein, um Beats langfristig zu ersetzen und die Installation und das Datensammeln zu vereinfachen. Optional lässt sich Logstash als Logverarbeiter einsetzen. Zusätzlich sind weitere Features für Security, Monitoring und Hochverfügbarkeit direkt im Produkt integriert; deren Aktivierung erfordert teilweise eine Enterprise-Lizenz.
Elastic Stack lässt sich sowohl on Premises direkt auf dem Server als auch mit dem offiziellen Operator in Kubernetes installieren – jeweils als freie oder als Enterprise-Version. Hier muss man sich mit den einzelnen Komponenten, deren Installation und Konfiguration auseinandersetzen: Elasticsearch, Kibana, Beats und optional Logstash und Agent. Für die ersten Gehversuche hilft eine Paketinstallation, für die Produktion empfiehlt sich das Automatisieren mithilfe von Ansible oder dem Kubernetes-Operator. Diese installiert eine Elastic Cloud im eigenen Cluster in der freien Variante ohne Lizenz. Für eine Beispielinstallation von Elasticsearch mit Kibana und Agent unter Ubuntu 20.04 LTS via Systemintegration siehe ix.de/zs1j.
In den vergangenen Jahren hörte man häufig von Elasticsearch-Hacks mangels TLS oder Autorisierung. Doch Elastic hat kräftig in Sicherheit investiert: TLS als Default, Servicetoken anstelle von Plaintext-Passwörtern und Verifikation mittels Code beim ersten Einrichten von Kibana. Dieser Prozess fügt sich nahtlos in die Installationsroutine ein und stellt sicher, dass kein unerlaubter Zugriff stattfindet. Der erste Log-in erfolgt mit dem Elastic-Superuser und man wird direkt an die Hand genommen, um die ersten Logdaten zu sammeln (Abbildung 1). Sucht man nach System, kann man Logs und Metriken mithilfe des Elastic Agent sammeln. Das Agenten-Set-up bietet noch die Installation eines Fleet-Servers für das Policy-Verwalten an. Schön sind die vielen Dashboards für die Systemintegration mit dem Agenten, die Elastic auch in der freien Version standardmäßig mitliefert. Es besteht die Möglichkeit, anstelle von Elastic Agent das für Cloud-native Umgebungen optimierte Fluent Bit in Kubernetes einzusetzen und die Logdaten an Elastic zu senden.
Kibana ist nützlich, um Daten aus Elasticsearch anzuzeigen und mittels Dashboards, Widgets und Reports ins richtige Licht zu rücken. Die Oberfläche integriert klassische Suche und Dashboards und bindet Enterprise Search, Observability, Security und Management ein. Administratoren profitieren von Beispiel-Dashboards, Dokumentation und zahlreichen Community-Posts, wie sich die Umgebung von Anfang an richtig einbinden lässt.
OpenSearch
Elastic hat in Version 7.11 die Lizenz geändert und erlaubt dem Anwender eine Lizenzierung entweder der SSPL oder einer eigenen Elastic-Lizenz. Beide verbieten es unter anderem, ein eigenes Produkt auf Basis von Elastic-Projekten als Cloud-Produkt anzubieten. Die Community forkte daraufhin die letzten Versionen unter der Apache-2.0-Lizenz und es entstand OpenSearch. Einige der in Elastic kostenpflichtigen Features sind dort in ähnlicher Weise in der freien Version enthalten: Security, Monitoring sowie Anomaly Detection. Manche Elastic-Plug-ins sind mittlerweile nicht mehr zu OpenSearch kompatibel. Elastic sieht den Fork als Konkurrenz und die Ökosysteme schotten sich gegeneinander ab. Ein Blick in das OpenSearch-Forum schafft oft Klarheit über den Zustand bestimmter Plug-ins.