Viele Anwendungen und Dienste verwenden kein einheitliches Format für die Logausgabe, im Gegenteil: Nach wie vor schreiben Applikationen und Dienste einfach unstrukturierte Daten Zeile für Zeile in eine Textdatei. Um die wichtigen Informationen aus dem Grundrauschen der Logeinträge herausfiltern zu können, setzen Administratoren Collectoren ein, die die Logs der unterschiedlichen Dienste und Systeme zentral sammeln, filtern und aufarbeiten.

Zu den wohl bekanntesten kommerziellen Vertretern dieser Gattung zählt Splunk, das seit März 2024 zu Cisco gehört. Allerdings ist Splunk nicht gerade billig und die Lizenzkosten hängen vom Volumen der verarbeiteten Logs ab. Es gibt jedoch eine Reihe quelloffener Optionen wie Elasticsearch [1], OpenSearch [2] oder VictoriaLogs [3]. In diesem Workshop führen wir Sie durch Setup und Logfilter-Konfiguration von Open- und Elasticsearch in einer Umgebung, die den parallelen Betrieb beider Werkzeuge erlaubt.

Am Anfang einer Log-Pipeline steht immer ein Dienst, der die Informationen vor Ort von Diensten, Applikationen und dem OS abholt und an den zentralen Collector beziehungsweise den Logfilter zur Aufbereitung schickt. Beim Elasticsearch-Stack ist das "Filebeat", das die Logs an "Logstash" übermittelt, das sie aufgearbeitet an Elasticsearch weiterleitet. Allerdings sollen in unserem Setup die verschiedenen Dienste parallel laufen, sodass Sie einen direkten Vergleich der Tools mit Ihren Daten aufsetzen können. Daher lassen wir die Filebeat-Instanzen auf unseren Testservern ihre Daten nicht direkt an einen Logfilter senden, sondern an Apache Kafka [4].

Apache Kafka ist ein Message-Bus, der prinzipiell als WhatsApp für Applikationen fungiert. Die Filebeat-Instanzen auf den Hosts senden ihre Logs an "Chat-Gruppen" (Topics) wie "Journals" oder in unserem Beispiel "Pihole". Die Logfilter klinken sich dann in diese Kafka-Topics ein und können alle Daten abgreifen. Der Zwischenschritt über Kafka erlaubt, dass mehrere Logprozessoren gleichzeitig Zugriff zu den Logs in Echtzeit erhalten.

Für unseren Workshop starten wir auf einem unserer Server den Apache-Kafka-Dienst als Single-Node ohne Verschlüsselung oder Authentisierung in einem Container via Podman. In einer produktiven Umgebung sollten Sie mindestens drei Konten verwenden und die Security-Features aktivieren. Listing 1 zeigt die Kommandos der Inbetriebnahme.

Für ein GUI, das Ihnen zeigt, welche Topics Kafka zur Verfügung stellt und wie viel Verkehr dort herrscht, starten Sie in einem weiteren Podman Container das Tool "Kafdrop" [5]. Drüber erhalten Sie zu Debug-Zwecken auch Zugriff auf die rohen Datensätze, die Filebeat bei Kafka abliefert.

Als Log-Shipper kommt in diesem Workshop ausschließlich Filebeat aus dem ELK-Stack zum Einsatz. Unsere Umgebung sammelt mit dem Tool journald-Logs von vier Linux-Servern und Systemlogs von einer Windows-11-Workstation ein. Zudem liefert ein Linux-System klassische File-Logs vom DNS-Filter "Pihole". Die dort gesammelten DNS-Abfragen nutzen wir, um die Visualisierungstools der Frontends und Filter-Pipelines auszuprobieren. Die jeweiligen Dashboards sollen die Geo-Informationen der per DNS angefragten IP-Adressen ermitteln und auf einer Karte darstellen. Dieses Dashboard hat wenig praktischen Nutzen, damit simuliert unser Setup jedoch eine sehr sinnvolle Geo-IP-Anzeige. Verwalter von Clouddiensten verwenden ähnliche Auswertungen, um festzustellen, woher die Nutzer ihres Webdiensts stammen oder gelangen dergestalt zu Security-Einsichten hinsichtlich der Herkunft von Hackerattacken auf Webdienste und Firewalls.

Während Kafka als Pod in einer VM läuft – in erster Linie, weil dies den Zugang zu den Kafka-Ports 9092 und 9093 vereinfacht –, installieren wir die Log-Stacks auf einem Single-Node-Kubernetes-Cluster (vergleiche das Harvester-Setup aus Ausgabe 12/25 [6]) mit Rancher RK2. Dieser arbeitet auf einem Server mit einer 16-vCore-AMD-CPU, 64 GByte RAM und zwei NVMEs (256 GByte und 1 TByte).

Alle Kubernetes-Rollouts laufen via Ansible. Den kompletten Code können wir an dieser Stelle aus Platzgründen nicht abdrucken. Wir stellen den Workshop Code jedoch für Sie auf GitHub [7, 8] bereit. Die Automatisierung ist in einzelne Schritte unterteilt. Es gibt "create" oder "deploy"-Playbooks, die die Log-Stacks ausrollen. Die eigentliche Konfiguration liefern wir mit einem eigenen "configure"- oder "upload"-Plabook. Somit können Sie die hier gezeigte Konfiguration auch ohne Ansible für Ihre Testsetups anpassen und verwenden.

Die ersten beiden Tools des Workshops sind eng miteinander verwandt. Elastic-search kam im Jahr 2010 als Open-Source-Projekt auf den Markt. Es basiert auf der Java-Bibliothek Apache Lucene, die Volltextsuche und Analysen erlaubt, speichert Daten im JSON-Format in seiner Datenbank und lässt sich ausfallsicher auf mehrere Knoten verteilen. Elasticsearch erlangte schnell Popularität und so gründeten die Entwickler im Jahr 2012 ein eigenes Unternehmen namens Elastic (ab 2015 in Elasticsearch umfirmiert). Die Firma bot kostenpflichtigen Support für die Open-Source-Variante der Software.

Auf Basis dieser freien Software erstellte Amazon den kostenpflichtigen Clouddienst "Amazon Elasticsearch", ohne dabei jedoch das Unternehmen Elasticsearch technisch oder finanziell einzubinden. Das führte zum Streit im Jahr 2021 und Elasticsearch änderte sein Lizenzmodell auf eine geschlossene Lizenz. Die Amazon-Entwickler reagierten prompt mit einem Fork der letzten quelloffenen Elasticsearch-Version 7 und starteten damit das weiterhin quelloffene Projekt OpenSearch.

Viele Entwickler aus der Community schwenkten daraufhin von Elasticsearch zu OpenSearch um. Der Lizenzwechsel schadete Elasticsearch letzten Endes, denn im Januar 2025 kehrte der Hersteller vollständig zur AGPL-v3-Lizenz zurück. Dennoch gibt es bei Elasticsearch nach wie vor zwei separate Software-Stacks, den freien gemäß AGPLv3 und einen kommerziellen nach der eigenen Elastic-Lizenz mit proprietären Zusatzfunktionen, die nur zahlenden Kunden zur Verfügung stehen.

In den vergangenen Jahren haben sich beide Projekte, obwohl sie auf den gleichen Kernkomponenten basieren, ein wenig auseinandergelebt. Elastic offeriert ein paar mächtige, aber eben kostenpflichtige ML-Funktionen, während OpenSearch seit dem Bruch mehr Community-Unterstützung erhält. Das Projekt wird hauptsächlich von Amazon vorangetrieben und zielt damit in erster Linie auf Cloudinstanzen und -anwendungen.

Das OpenSearch-Projekt hat bei seinem Fork die drei Bestandteile von Elasticsearch übernommen und umbenannt: Elasticsearch wird zu OpenSearch Core, Logstash zum Data Prepper und Kibana heißt hier einfach OpenSearch Dashboards. Die Komponenten ließen sich auf Kubernetes eigentlich recht einfach über den OpenSearch-Operator ausrollen, den Anwender einfach via Helm-Chart installieren. Aber wir verzichten auf den Operator aus einem bestimmten Grund: Dieser erwartet Umgebungen mit mehreren replizierenden Knoten, SSL/TLS-Verschlüsselung und Authentisierung. Frühere Versionen konnten noch einfache und ungesicherte Single-Node-Setups installieren, aber das funktioniert aktuell nicht mehr.

Aus diesem Grund rollen wir das Testsetup ohne Operator auf Kubernetes aus. Im ersten "create"-Playbook erzeugen wir die Open-Search-Konfiguration "opensearch.yml" als Kuberentes-Config-Map:

Sollten Sie für Ihre Tests auf Ansible oder Kubernetes verzichten, können Sie die gelisteten Config-Maps einfach in die passenden Dateien schreiben und auf Docker oder Podman laufen lassen.

Im Applikations-Pod rollen wir den Container "opensearchproject/opensearch: 3.3.2" aus. Bei genauem Hinsehen finden Sie in unserem Demo-Code auf GitHub auch einen "InitContainer", der die Zugriffsrechte auf das Persistent Volume (PV) des Rollouts anpasst, denn ohne den funktioniert das Rollout in unserer Umgebung nicht. Zum OpenSearch-Setup spielen wir das Dashboard in der Version 3.3.0 als Single-Node ohne Sicherheitskonfiguration ein, dafür jedoch mit Ingress-Route für den HTTP-Zugang.

So weit zum einfachen Teil, das eigentliche Aufbereiten der Daten ist etwas komplizierter. Wie eingangs erwähnt, liegen viele Logdaten unstrukturiert vor. Der Log-Shipper Filebeat ändert in der von uns verwendeten Konfiguration daran erst einmal nichts, die Daten gehen als "rohes" JSON zunächst an Kafka. Dabei enthält das JSON-Feld "message" alleine eine Fülle von Logdaten, die der Prozessor in weitere Felder zerlegen kann. Zum Beispiel liefert der dnsmasq-Server unseres Pi-hole Query-Informationen, die in etwa so aussehen wie in Listing 2.

Wir möchten nun herausfinden, wo sich die per DNS angefragten Systeme befinden. Dazu ermitteln wir über einen GeoIP-Filter den Ort der IP-Adressen und stellen dies in einer Landkarte dar. Um Datensätze zu manipulieren oder neue Variablen aus bestehenden herauszufiltern, benötigen wir eine so genannte Log-Pipeline. Diese kann einerseits direkt auf der OpenSearch-Instanz laufen oder auf dem Data Prepper zwischen Kafka und OpenSearch. Für die Konfiguration von solchen Pipelines hat sich bei Data-Prepper in der Zwischenzeit das YAML-Format durchgesetzt, was besser lesbar als das alte Java-Format einer Logstash-Konfiguration erscheint. Am Beginn der Pipeline definiert Data Prepper eine Quelle, zum Beispiel:

Der "Processor" kann statische Felder einfügen oder bestehende Felder filtern und zerlegen:

Das Feld "message" wird zu "log.message" und sofern darin JSON-Strukturen zu finden sind, generiert Data Prepper daraus weitere Felder. Das Feld muss vorher umbenannt werden, weil in der JSON-Struktur von "log.message" nochmal ein Feld mit den Namen "message" vorkommen kann. Im Anschluss kommt der "Grok"-Filter zum Einsatz um via RegEx weitere Felder zu extrahieren:

Der Filter sucht nach einem Eintrag der entweder mit "query[A]" oder "query [AAAA]" beginnt. Findet Grok einen passenden Eintrag generiert er aus den Folgeeinträgen die Felder "dns_queried_system" im String-Format ohne Leerzeichen und "dns_query_from" als IP-Adresse.

Aus der Lognachricht "dnsmasq: query[A] www.microsoft.com from 192.168.1.1" erhalten wir also "dns_queried_system= "www.microsoft.com"" und "dns_query_ from=192.168.1.1". An dieser Stelle sei angemerkt, dass das Erstellen von RegEx-Filtern ein wirklich sinnvolles Einsatzgebiet für KI-Tools ist. Am Ende der Pipeline steht dann das Ziel, also in unserem Fall OpenSearch:

Die URL "opensearch.opensearch-cluster.svc.cluster.local" ergibt sich aus dem Kubernetes-intern generierten DNS-Namen. In den vollständigen Konfigurationsdateien (siehe GitHub) finden Sie drei Log-Pipelines, eine für die journald-Logs, eine zweite für die Pi-hole-Daten mit extrahierten DNS-Anfrageinformationen sowie IP-Adressen und eine für die Logs von Windows-Systemen. Damit können Sie jetzt im OpenSearch Dash-board passende Logansichten und falls nötig Alerts anlegen.

Gehen Sie im OpenSearch-Dashboard auf die Option "Discover" und wählen Sie dann einen Ihrer Indizes aus. Zunächst sehen Sie die kompletten Rohdaten der Logeinträge. In der linken Spalte listet das Dashboard die verfügbaren Felder des Index auf. Anstelle der rohen Ansicht können Sie hier nun Log-Views bauen, die nur bestimmte Felder aus der Liste anzeigen. Zudem haben Sie die Option, die Ergebnisse über Suchkommandos einzugrenzen. Um eine solche Ansicht wiederzuverwenden, speichern Sie diese mit einem Namen ab.

Sehr praktisch ist die Visualisierung für den journald-Index, die die Felder "host.name", "message" und "journald. process.executable" darstellt und die Ansicht auf das Schlüsselwort "error" in der Suchzeile eingrenzt. So sehen Sie sofort Systeme mit akuten Fehlern und den jeweiligen Dienst, der die Fehlermeldung ausgibt.

Um zu den geloggten IP-Adressen des Pi-hole-Index die GeoIP zu ermitteln, braucht es ein Plug-in und eine GeoIP-Datenbank. Neuere Versionen von OpenSearch oder Data Prepper bringen dies gleich mit. Praktischerweise verwalten die aktuellen Plug-in-Versionen auch gleich die Datenbank, im Gegensatz zu älteren Versionen, bei denen der Administrator selbst die Datenbank aus dem Internet laden und aktuell halten musste.

Die GeoIP kann entweder OpenSearch selbst oder Data Prepper ermitteln. Unser Demo-Skript [7] richtet die Pipeline direkt in OpenSearch ein, Listing 3 zeigt einen Ausschnitt. Das Ansible-Playbook wartet, bis der OpenSearch-Pod läuft und spricht dann über den Pod selbst das API von OpenSearch an, um die Pipeline einzurichten ("PUT geoip-pipeline"). In einem zweiten API-Aufruf später im Skript weist das Playbook die Pipeline dem Index-Pattern "pihole-*" zu, in der alle Loginformationen vom Data-Prepper ankommen:

Damit fügt OpenSearch automatisch allen Logeinträgen des Pi-hole-Indexes die GeoIP-Information hinzu, wenn der Eintrag über ein Feld "dns_queried_system_ip" verfügt.

Hier kommt bereits ein wesentlicher Unterschied zwischen OpenSearch-Dashboards und Elasticsearch Kibana zum Vorschein. Das OpenSearch-Dashboard ist kompakter und verfügt über deutlich weniger Verwaltungstools als Kibana. Während Kibana eine Managementansicht offeriert, die Pipelines anzeigt und auch erlaubt, diese interaktiv via UI zu ändern, fehlt diese Funktion im OpenSearch-Dashboard vollständig. Das Management von Pipelines muss hier über das API erfolgen.

Alternativ können Sie die Pipeline aber auch dem Data-Prepper-Setup hinzufügen. Bei einer Kubernetes-Installation von Data-Prepper benötigt der Pod hierfür ein zusätzliches, beschreibbares PV auf dem Verzeichnis "/usr/share/data-prepper/data/geoip", sonst kann das Tool die Datenbank und Änderungen daran nicht sichern.

Unser Demo-Skript legt die Pipeline in OpenSearch an und definiert daher kein zusätzliches PV für den Data Prepper. Sollten Sie GeoIP via Data Prepper nutzen wollen, genügt ein simpler Eintrag im Abschnitt "processor" in der Data-Prepper-Config-Datei:

Mit aktiver GeoIP-Pipeline sehen Sie nun die Orte der via DNS angefragten IP-Adressen. Das funktioniert mit der regulären Geo-IP-Datenbank zwar nicht mit allen Orten, aber mit den meisten. Ob der Prozess an sich läuft, prüfen Sie ebenfalls in der "Discovery"-Ansicht: Wählen Sie den Index "pihole-*" und darin die Felder "dns_queried_system", "dns_queried_system_ip" und "dns_queried_system_geoip.location". Filtern Sie in der Suchzeile nach "dns_queried_system_ ip:*", was nur Einträge auflistet, die über das entsprechende Feld verfügen. Läuft das GeoIP-Plug-in, sehen Sie in der Spalte "dns_queried_system_geoip.location" jetzt Koordinaten.

Um diese in einer Karte anzuzeigen, legen Sie im Menü "Dashboards" ein ebensolches neu an, fügen eine Visualisierung vom Typ "Coordinate Map" hinzu und wählen den Pi-hole-index aus. Als Metrik geben Sie "count" an. Je mehr DNS-Anfragen zu einer URL im Log stehen, desto größer wird der Punkt auf der Karte.

Fügen Sie nun den Bucket "Geo Coordinates" hinzu, wählen Sie die Aggregation "Geohash" und das Feld mit den Daten "dns_queried_system_geoip.location". In unserem GitHub-Repo finden Sie ein fertiges OpenSearch-Dashboard mit Kartenansicht, das die KI Claude passend zum Code erstellt hat.

Für den direkten Vergleich mit Elastic-search haben wir ein zweites Projekt [8] erstellt. Das Deployment und die Konfiguration sind dabei fast identisch.

Es gibt jedoch Ausnahmen: Logstash beispielsweise nutzt nach wie vor das "conf"-Format und kein YAML, wie das bei Data Prepper der Fall ist. Inputs definieren Sie hier via:

Grok-Filter erzeugen Sie mit einzelnen Einträgen wie diesem:

Aber funktionell bleibt das Setup gleich. Mit KI-Hilfe lässt sich die bestehende OpenSearch-Konfiguration in wenigen Minuten zu Elasticsearch umbauen. Wie auch in der OpenSearch-Umgebung generiert unser Szenario den GeoIP-Filter direkt via API in OpenSearch. Auch hier können Sie diese Funktion auf Wunsch in Logstash statt in Elasticsearch abbilden. Anders als das OpenSearch-Dashboard bietet Kibana jedoch deutlich mehr Managementfunktionen und erlaubt Ihnen, Pipelines interaktiv im UI zu bearbeiten.

Mithilfe des Kafka-Busses und unserem Beispielcode können Sie simultan ein Open- und ein Elasticsearch-Setup mit den gleichen Loginformationen zum Testen aufsetzen. Dann liegt es an Ihnen, welches der Tools besser mit Ihren Daten zurechtkommt und welches Ihnen besser gefällt. Nach der Rückkehr von Elastic-search zur AGPL stehen Ihnen wieder beide Optionen offen.

Unsere eigene Einschätzung bleibt zwiegespalten: Die YAML-Struktur zur Konfiguration des Data Preppers ist übersichtlicher und vereinfacht es, komplexere Pipelines für den Data Prepper zu verwalten. Die conf-Files von Logstash waren noch nie wirklich übersichtlich. Auf der anderen Seite ist Kibana nach wie vor das bessere Front-end, weil es gegenüber OpenSearch-Dashboards die besseren Verwaltungsfunktionen mitbringt.